近日，Prime Video 团队对 Amazon 的架构案例研究在开发者社区中引起了震惊与哄笑。

这是因为它坦诚地评估了自己如何通过从微服务架构迁移到单体架构来节约资金，并避免使用 AWS Step Functions、Lambda 无服务器函数等昂贵的云服务。

产品的需求一部分作为监控工具，能够识别“客户查看的每个字符流”中的质量问题，因此需要具有高度可扩展性，因为存在“数千个并发流”，该团队最初创建了一个包含由 AWS Step Functions 编排的分布式组件的解决方案。

AWS Step Functions 是一种基于状态机和任务的无服务器编排服务，但后来的事实证明，Step Functions 造成的却是瓶颈。

该团队这样总结道：

“我们的服务每秒都会执行多次状态转换，因此很快就达到了帐户限制。除此之外，AWS Step Functions 对每次状态转换都向用户收费。”用于临时存储捕获的视频帧的“对 S3 存储桶的大量一级调用”还存在很多的成本问题。

该论文还继续阐述，如何消除对 S3 的需求。

“我们意识到分布式方法并没有在我们的特定用例中带来太多的好处，因此我们将所有组件打包到一个流程中，我们还实现了控制单个实例内组件的编排。该解决方案现在运行在 EC2（弹性计算云）和 ECS（弹性容器服务）上，并具有一个轻量级编排层来分发客户请求”。

该论文得出的结论：

“微服务和无服务器组件是可以大规模工作的工具，但是否在单体应用上使用，需要根据具体情况而定。后来将我们的服务转移到单体架构使基础设施成本降低了 90% 以上，它还增强了我们的扩展能力。” 

该团队还提到通过 EC2 节省计划并降低成本，这表明即使是内部 AWS 客户也会按照与其他人相似的模式进行计费。

“我有点惊讶这篇文章的存在，”HackerNews上用户如此评论说。在很多地方，AWS 经常宣扬微服务和无服务器架构的优势，将其视为“现代化”应用程序的最佳方式。

例如，在可靠性的要求下，AWS“架构良好的框架”建议说：

“使用面向服务的架构 (SOA) 或微服务架构可构建高度可扩展且可靠的工作负载。面向服务的架构（SOA）是通过服务接口使软件组件可重用的实践。微服务架构进一步使组件变得更小、更简单。”

在这份关于 .NET 应用程序现代化的“AWS 规范指南”文档中，AWS公司列举了微服务的优势，包括更快的创新、高可用性和可靠性、更高的敏捷性和按需可扩展性、现代 CI/CD（持续集成和部署）管道以及强大的模块边，尽管它也将“操作复杂性”列为了缺点。

不过，这篇新论文似乎印证了开发者的一些怀疑。一是 AWS 推荐的解决方案可能不是最具成本效益的，因为它们总是涉及使用多种成本高昂的服务。

另一个问题是，微服务相对于单体应用程序的优点经常被夸大。

Ruby on Rails 的创建者、弃云服务的倡导者 David Heinemeier Hansson在评论亚马逊的案例研究时表示：

“云服务确实总结了一段时间内席卷科技行业的微服务热潮：IN理论。而现在，所有这些理论的现实结果终于出来了，而且很明显，在实践中，微服务可能成为让系统复杂化的最大诱惑。无服务器只会让情况变得更糟。” Hansson 表示说，“在单个、连贯的团队和应用程序中用网络调用和服务分区来取代方法调用和模块分离在几乎所有情况下都是非常疯狂的。”

2020 年，企业架构顾问兼《构建微服务》和《从单体到微服务》等书的作者 Sam Newman 在一次开发者大会上表示说:

“微服务不应该成为默认选择”，他在 The Register 的文章评论中向软件架构师们提出了建议：

”在进行之前，你做过价值链分析吗？你有没有看过瓶颈到底出在哪里？你尝试过模块化了吗？微服务应该是最后的手段。”

Newman今天在 Twitter 上评论了AWS 论文，他说：“这篇文章实际上更多地讨论了功能与长时间运行的虚拟机的定价模型。它仍然是一个完全合乎逻辑的架构驱动因素，但从这个案例研究中学到的知识可能具有更狭窄的适用范围。” 他补充说，“人们之所以不公开谈论重新涉足微服务，是因为这可能会被一些人看成‘他们搞错了’。当情况发生变化时改变主意是完全理智的。”

这篇论文对于 AWS 来说，也并不一定是坏消息。一方面，它确实违反了云巨头所说的最佳实践；但另一方面，它以令人耳目一新的诚实方式审视了如何通过简化的架构来降低成本，以及改变更好架构的案例研究。

与许多促销案例研究不同，这一案例看起来对使用 AWS 或其它云服务的客户确实有用。

作者：万能的大雄