来自亚马逊 Prime Video 团队的一个案例研究在开发者社区中掀起了轩然大波。

在该案例中，Prime Video 团队将一个监控系统从微服务架构迁移到单体架构，并避免使用昂贵的服务（如 AWS Step Functions 和 Lambda 无服务器函数），并对此举所带来的降本效果进行了评估。

他们的需求是使用一个监控工具来识别“用户查看的视频流”的质量问题，因为有“成千上万个并发流”，所以这个工具必须是高度可伸缩的。团队最初构建了一个由 AWS Step Functions 编排而成的分布式组件解决方案，一个基于状态机和任务的无服务器编排服务。结果发现，Step Functions 居然是瓶颈所在。

案例文章中写道：“对于视频流的每一秒，我们的服务都需要执行多次状态转换，所以很快就达到了账户限制。除此之外，AWS Step Functions 是按照状态转换向用户收费的。”还有另外一个“成本问题”，即存在大量对 S3 的一级调用（用于临时存储捕获的视频帧）。

Prime Video 监控应用程序的初始架构，可见成本很高，伸缩性也很差

案例文章中写道：“我们意识到分布式架构在这个特定的场景中并没有为我们带来太大的好处，所以我们将所有组件都合并到一个进程中”，从而消除了对 S3 的依赖。“我们还实现了在单个实例中控制组件的编排。”现在，这个解决方案运行在 EC2（Elastic Compute Cloud）和 ECS（Elastic Container Service）上，其中有“一个轻量级的编排层来分发用户请求”。

案例文章总结道：“微服务和无服务器组件可以被用在大规模的场景中，但是否一定要舍弃单体而使用它们则需要根据具体情况具体分析。将服务迁移成单体让我们的基础设施成本降低了 90% 以上，还提升了我们的伸缩能力。”文中还提到了他们通过 EC2 节省计划来降低成本，这说明即使是内部 AWS 用户也会按照与外部用户类似的模式收取费用。

这篇文章最初是在三月份发布的，但是直到这个月才引起整个工程界和技术界的关注。

Hacker News 上的一条评论说：“这篇文章的存在让我感到很惊讶，甚至都有点看傻眼了”。

在我们看来，AWS 总是习惯于将微服务和无服务器架构宣扬成“现代化”应用程序的最佳实践。例如，“AWS Well-Architected”文档的“Reliability”一项下面给出了一些建议：

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

在关于.NET 应用程序现代化的“AWS Prescriptive Guidance”文档中，亚马逊列出了微服务的好处，包括更快的创新、高可用性和可靠性、更高的敏捷性和按需可伸缩性、现代 CI/CD（持续集成和部署）管道，以及强大的模块边界，尽管它也将“运维复杂性”列为缺点。

然而，这篇案例文章似乎证实了开发者的一些猜疑。其中的一个猜疑是，AWS 推荐的解决方案可能不是最具成本效益的，因为它们总是涉及到使用多种昂贵的服务。另一个猜疑是微服务相对于单体应用的优点似乎被夸大了。

Ruby on Rails 作者 David Heinemeier Hansson 一直在倡导减少对云服务的使用，他在评论亚马逊的这个案例研究时表示，它“对一度席卷科技行业的理论上的微服务热潮来了一次大总结。现在，这些理论的实际结果终于出来了。很明显，在实践中，微服务可能会给系统带来不必要的复杂性。而无服务器只会让情况变得更糟。一个团队，一个应用程序，却用网络调用和服务分区取代方法调用和模块分离，这在任何一种情况下几乎都是很疯狂的。”

“即使是亚马逊也无法理解无服务器或微服务。”

2020 年，“Building Microservices”和“Monolith to Microservices”等书的作者 Sam Newman 在一次开发者大会上表示，“微服务不应该是默认的选择”，并向软件架构师提出了一些在采用微服务架构之前需要考虑的事项：“你做过价值链分析吗？你了解过瓶颈出现在哪里吗？你尝试过模块化吗？微服务应该是最后才去考虑的。”

现在，Newman 在推特上对这篇案例文章做了评论：“这篇文章实际上更多的是关于函数与长时间运行的虚拟机的定价模型。这仍然是完全合乎逻辑的架构驱动，但从这个案例中学到的东西，其适用性范围可能相对要狭窄一些。”他接着写道：“人们之所以不公开谈论撤离微服务，是因为这可能会让一些人认为‘他们做错了’。视情况变化而改变你的想法才是对的做法。”

关于这篇文章的讨论随处可见，它激起了大量的思考，在 Hacker News、Twitter、Reddit 等平台上涌现了非常多的有意思的评论和分析。

就像一位网友在 Hacker News 上评论的那样：“这是一个很好的教训，一个很好的故事，而且很重要的是它来自亚马逊内部团队。”

对于该案例的初始架构设计存在的问题，一位 DataDog 高级软件工程师 Lambros Petrou 在推特上发表了分析：“Prime Video 案例文章中的设计是有问题的。滥用服务并不能解决架构问题，它只会把问题暴露出来”。前首席技术官 Steve Chambers 在某种程度上也同意这一观点，他说：“基本上，他们（现在）使用的是相同的架构，只是将组件塞到了容器中，这样他们就不会在不同的云服务之间通过网络进行昂贵的调用和数据传输……这很明显是一种优化！”

一名工程师在 Reddit 上针对这个案例争论道：“微服务是有额外开销的。本来简单的进程间通信，或者系统两个部件之间的内存调用，变成了 HTTPS、OAuth、JSON 编码 / 解码，而且每次都需要发生这些简短的对话。当你的系统被分解成 50 万个部件，每一次通信都需要做这些事情，并且你要为每一个事务付费时，成本和复杂性就会增加。拆解单体需要一次性替换整个应用程序，这意味着开发人员需要做一些测试。但 DevOps 意味着不会有更多的测试，所以在生产环境中会发生故障，我们唯一能做的是让功能块变小，这样才可能快速找到和修复问题。”

但总的来说，这篇案例文章对于 AWS 来说未必是坏消息。一方面，这似乎与这家云计算巨头所宣扬的最佳实践背道而驰，但另一方面，这也是一个令人耳目一新的关于如何通过简单的架构来降低成本的实践。与许多促销案例研究不同，这个案例看起来对 AWS 客户真的很有用。

这件事情被大家传得沸沸扬扬的，甚至还惊动了亚马逊 CTO Werner Vogels 博士。

他对此表示，构建可演进的软件系统是一种策略，我们必须以开放的心态重新审视自己的架构。

“软件架构不像桥梁和房屋的架构。桥梁建成后就很难改变，但软件不一样。软件一旦运行起来，我们就可以更深入地了解我们的工作负载，然后再选择一个可演进的架构，在不影响客户体验的情况下进行更改。我的经验法则是，随着每个数量级的增长，你都应该重新审视你的架构，并确定它是否仍能支持下一个数量级的增长。”

“Prime Video 就是个很好的例子。（架构设计）没有放之四海而皆准的方法。我们总是敦促我们的工程师找到最佳解决方案，并且我们没有强制要求特定的架构风格。”“我想重申，没有一种架构模式可以满足所有的情况……单体没有消亡（恰恰相反），可演进的架构也在不断变化的技术格局中扮演着越来越重要的角色。”

在 Werner Vogels 博士发表看法之后，去年已宣布退休的前亚马逊云科技可持续发展架构副总裁、前云架构战略副总裁 Adrian Cockcroft 也忍不住出来点评了一下。

“关于 Prime Video 的案例，虽然互联网上涌现了堆积如山的意见和观点，但大多没有说到点子上。”

Prime Video 团队只是遵循了一条“Serverless First（无服务器优先）”的原则：首先尝试使用 Step Functions 和 Lambda 进行快速构建。通过无服务器方法，在几天或几周内构建一个原型，这是重点。然后在需要应对高流量时，再进行重构。“Serverless First”和“Serverless Only”是有区别的，“我不提倡 Serverless Only”。

他认为这个案例之所以会引起这么大的反应，关键是“在微服务被过度营销的情况下，大家以为 Prime Video 团队返回到了单体架构”。

“我确实认为微服务被过度宣传了，把微服务作为解决所有问题的答案。而且这可能是因为厂商想通过简单的营销信息来销售 Kubernetes，即需要通过使用 Kubernetes 来实现云原生的微服务。大家对这种信息传递方式表示了强烈的反对。Kubernetes 的复杂性是有代价的，除非你的团队和规模非常大，否则你不需要它。（建议阅读 Sam Newman 的《构建微服务：设计细粒度系统》一书。）”

总之，Prime Video 团队最初的设计还是很棒的，帮助他们快速进入市场并带来收益。而现在，他们在退后一步进行下一阶段的分析。“该团队遵循了我认为的最佳实践”，“我认为 Prime 团队发布的这篇文章非常富有洞察力……”