亚马逊流媒体平台Prime Video于2023年3月22日发布的一篇技术博客，详细阐述了其音视频监控服务如何实现成本大幅缩减。文章指出，通过从原有的分布式微服务架构转变为单体应用程序，服务实现了更高的可扩展性、弹性和显著的成本降低，幅度高达90%。这篇文章随后在Reddit和Hacker News等技术社区引发了热烈讨论，尤其是在五一假期期间。这一转变与当前技术界普遍推崇的微服务架构理念形成了强烈反差，加之亚马逊这种业界巨头也选择回归单体架构，使得话题更具爆炸性。DHH在批评完Typescript之后，也紧接着发表文章，质疑亚马逊对Serverless和微服务的理解，进一步将这一讨论推向高潮，迅速登上技术圈热搜榜。
近期，我收到了朋友们转发的三篇文章，分别是《微服务是不是个蠢主意？》、《单体回归？亚马逊放弃用于视频监控的微服务》和《从微服务转为单体架构、成本降低90%，亚马逊内部案例引发轰动》。从这些标题可以看出，它们更多是为了吸引流量，而非深入剖析技术问题。特别是第二篇文章，将Prime Video的案例等同于整个亚马逊，这本身就存在偏颇。我注意到，许多评论者可能仅凭标题就发表看法，甚至没有仔细研读原文。因此，我认为有必要对这一事件进行深入解读。
要全面理解这一问题，关键在于认真阅读亚马逊Prime Video团队发布的原始技术博客。该文章内容并不复杂，技术细节也相对较少，但其核心要点清晰明了：
首先，该系统是一个监控系统，主要用于监控数千条点播视频流的数据。其核心功能是检测视频流的质量和效果，例如识别视频损坏或音频不同步等问题。为此，系统最初采用了一个微服务，负责将视频拆分成帧并临时存储在S3上，这在图中被称为“Media Conversion”服务。
其次，为了迅速构建系统，Prime Video团队采用了Serverless架构，具体使用了AWS Lambda和AWS Step Functions。一个前端Lambda作为用户请求的网关，Step Function则用作监控探测器。一旦发现问题，系统会通过SNS发送通知。Step Function从S3获取Media Conversion处理后的数据，然后将结果汇总给一个后端Lambda，最终存储于S3。这种架构看起来非常简洁高效，且完全隐藏了服务器基础设施的复杂性，充分利用了Serverless的优势。快速部署、便捷开发，无需关注底层运维，直接结合AWS的Lambda、Step Function、SNS和S3等服务，便能迅速搭建一个功能健全的监控系统，这样的开发模式无疑具有极大的吸引力。
然而，Prime Video团队在实践中遇到了一个显著的瓶颈：AWS Step Function的伸缩性问题。从原文中，我观察到两个关键问题。第一，系统需要极高并发的AWS Step Function实例，这很快就达到了账户的硬性限制。第二，AWS Step Function的计费模式是按状态转换次数收费，导致成本过高，难以承受。这两个关键点——账户对Step Function的限制以及高昂的费用——最终促使团队寻求解决方案。
面对这些挑战，Prime Video团队随即着手解决。他们的应对策略包括：
将“Media Conversion”功能与Step Function的逻辑整合到同一个应用程序中。这样一来，Media Conversion与Step Function的内部组件之间可以通过内存直接通信，不再需要S3作为中间存储介质。所有处理结果最终汇总到一个线程，并写入S3。
将这个整合后的单体应用程序进行分布式部署，并继续利用原有的AWS Lambda作为入口调度器。
采用EC2进行水平扩展，其扩展能力几乎不受限制，用户可以根据需求灵活调整CPU和内存配置。鉴于视频转码和监控分析这些功能本身的复杂性并不高，将它们整合在一起反而更加高效。相比于之前的Serverless架构，这种新的模式显然带来了更多优势，原因如下：
团队不再受限于Step Function的容量限制，获得了更大的技术控制自由度。
去除了高昂的Step Function费用，云成本显著降低。如果进一步将Lambda替换为Nginx、Spring Gateway或更轻量级的方案，S3替换为MinIO，SNS替换为Kafka，成本还能进一步优化。
独立思考。
在解读完原文之后，您是否形成了自己的独立见解？以下是我对此事件的一些思考，希望能为您提供参考：
首先，AWS的Serverless、微服务以及单体架构，在各自适用的场景下都能够发挥巨大价值。这就像不同类型的汽车——跑车、货车、越野车——各有其最佳用途。用跑车运货或用货车进行浪漫约会，都不是明智的选择。
其次，Prime Video案例所涉及的业务逻辑相对简单，本质上只是视频转码与分析。这样的业务，即便拆分，也只需两个微服务（一个负责转码，一个负责分析），并可设计为流式处理。如果选择不拆分，整合为一个单体服务也完全合理，其粒度符合微服务定义。微服务划分有多种原则，此处我列举几个关键点：
边界上下文：微服务的粒度不应超越领域驱动设计中的边界上下文，即一个业务领域。
单一职责、高内聚、低耦合：将因相同原因而改变的功能聚合在一起（高内聚），将因不同原因而改变的功能分离（低耦合）。
事务与一致性：对于功能重度依赖、需要强事务和一致性保证的模块，最好不要拆分，应保持在同一个服务内。
组织架构匹配：将同一团队负责的功能放在一起，不同团队的则分开。
再者，Prime Video所遭遇的问题，并非出在微服务架构本身，而是AWS Step Function的处理能力不足且收费过高。这本质上是AWS产品层面的问题，而非技术架构的固有缺陷。或者说，是Prime Video团队对Step Function的使用方式可能存在不当，对于这种需要大量数据分析处理的场景，Step Function并非最佳选择。因此，我们不应因一个产品问题而得出微服务架构存在缺陷的结论，两者之间并无直接因果关系。试想，如果Step Function能够无限扩展，性能卓越，且价格低廉，Prime Video团队还会有动力转向单体架构吗？他们或许会反过来大力赞扬Serverless的优势。
此外，Prime Video与AWS在亚马逊集团内部是独立核算的实体，正如亚马逊的电商业务与AWS云服务一样。在服务化和微服务架构的理解与实践方面，亚马逊电商和AWS的水平，我认为是全球范围内其他任何公司都难以匹及的，包括谷歌和微软。您可以参考早期文章《Steve Yegge对Amazon和Google平台的吐槽》以获取更多信息。
最后，Prime Video的这个案例本质上可以被理解为一次“下云”行动，即从AWS Serverless服务中剥离。云计算服务成本较高，这既体现在费用上，也体现在潜在的供应商绑定问题上。Prime Video团队值得庆幸的是，他们的监控系统相对不复杂，重写成本较低，因此得以迅速转向更传统的“服务化”与“云计算”相结合的分布式架构。否则，他们可能需要像DHH那样，经历痛苦的“下云”过程，正如DHH的文章《Why We’re Leaving the Cloud》及其SRE团队博文《Our Cloud Spend in 2022》所揭示的，下云过程的艰辛及其带来的成本节约。
后记。
最后，容我做个简短的广告。在过去的几年创业中，我协助许多公司解决了分布式、微服务、云原生以及云计算成本优化等方面的挑战。如果您也有类似的需求，欢迎通过邮件（haoel@hotmail.com）与我联系。
此外，我们今年推出了MegaEase Cloud平台，旨在帮助用户在不牺牲云计算体验的前提下，通过自建高可用基础设施，实现至少50%的云计算成本节约。当前可降低成本的主要方式包括：
核心软件：通过开源软件实现自建部署。
内容分发：结合MinIO和Cloudflare的免费CDN服务。
我们即将发布直接与底层IDC合作的廉价GPU计算资源。
欢迎大家试用我们的服务。
访问途径分为中国区和国际区，它们完全独立，账户互不相通，请勿跨区使用。产品演示和介绍文章均已上线，欢迎使用MegaEase Cloud。2023年3月有重大更新。全文完。