日前，亚马逊旗下的流媒体平台Prime Video发布了一篇技术博客，题为《规模化Prime Video的音视频监控服务，成本降低90%》。文章副标题明确指出，从分布式微服务架构转向单体应用程序，是实现更高规模、更强弹性和更低成本的关键。此文一经发布，迅速在技术圈内掀起轩然大波，特别是在Reddit和Hacker News等社区引发了激烈讨论。
技术界对于这个话题的关注度空前高涨，因为亚马逊作为云服务和微服务领域的领军企业，其自身的实践似乎与主流技术趋势背道而驰。知名开发者DHH在对TypeScript发出批评后，又紧接着发表文章《即便亚马逊也无法理解Serverless或微服务》，进一步抨击微服务架构，使得这一话题瞬间登顶技术热搜。
围绕此事件，多篇文章开始流传，例如《微服务是不是个蠢主意？》、《单体回归？亚马逊放弃用于视频监控的微服务》和《从微服务转为单体架构、成本降低90%，亚马逊内部案例引发轰动》。这些标题虽然吸人眼球，但不免带有夸大和片面之嫌。许多评论者甚至仅凭标题就妄下结论，未能深入阅读原文。
要深入理解此次事件，需要仔细研读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的扩展性瓶颈。主要体现在两方面：第一，由于需要极高并发的Step Function实例，很快就达到了账户的硬性限制；第二，AWS Step Function按状态转换次数计费，导致成本高昂得难以承受。可见，问题的症结在于：1）账户对Step Function存在限制，2）Step Function的成本过高。
为解决这些问题，Prime Video团队采取了以下措施：
他们将Media Conversion和Step Function的功能整合在一个应用程序中。原先通过S3进行通信的Media Conversion和Step Function模块，现在改为通过内存进行通信。处理结果在一个线程中汇总后写入S3。
随后，他们对这个单体架构进行了分布式部署，依然利用AWS Lambda作为入口调度器。
现在，通过EC2实现水平扩展不再受限，可以根据需求灵活配置CPU和内存资源。视频转码和监控分析功能本身并不复杂，将其整合在一起反而更为高效，解决了Step Function的限制。技术掌控力更强，AWS的昂贵成本也随之降低。如果进一步将Lambda替换为Nginx或Spring Gateway，S3替换为MinIO，SNS替换为Kafka，成本还能进一步优化。
基于以上对原文的解读，我们可以进行以下独立思考：
无论是AWS的Serverless、微服务还是单体架构，都有其适用的场景，关键在于选择合适的工具。如同各式汽车，跑车、货车、越野车各有所长，若用跑车拉货或用货车越野，效果自然不佳。
Prime Video案例中的业务场景较为简单，本质上是视频转码和分析。即便采用微服务，也只需两个服务（一个转码、一个分析），或是将其整合为流式处理。微服务的划分应遵循一些关键原则，例如：遵循限界上下文（Bounded Context），以业务领域为界；遵循单一职责、高内聚、低耦合原则，将因相同原因变化的功能聚合，将不同原因变化的功能解耦；对于需要原子事务和强一致性的功能，最好不拆分；以及与组织架构匹配，将同一团队负责的功能聚合。
Prime Video所面临的问题并非微服务架构本身的缺陷，而是AWS Step Function的产品限制和高昂收费所致。换言之，这是AWS的产品问题，或者说是Prime Video对Step Function的滥用（大规模数据分析与处理并非Step Function的理想应用场景）。因此，不应将一个产品层面的问题推导出微服务架构存在问题的结论。试想，若Step Function能够无限扩展、性能优异且价格低廉，Prime Video团队还会选择转向单体架构吗？届时他们反而会推崇Serverless。
Prime Video与AWS在亚马逊内部是两个独立核算的公司。亚马逊电商和AWS在服务化或微服务架构的理解和运营经验方面，堪称业界翘楚。这一经验远超谷歌或微软。若有兴趣，可查阅过往文章《Steve Yegg对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提供中国区和国际区服务，两区域独立运行，账号不互通，请勿跨区使用。详细信息可在产品演示和介绍文章中查看。
欢迎体验MegaEase Cloud。
（本文已于2023年3月进行了重大更新）