标签 EC2 下的文章

这两天技术圈里热议的一件事就是Amazon的流媒体平台Prime Video在2023年3月22日发布了一篇技术博客《规模化Prime Video的音视频监控服务，成本降低90%》，副标题：“从分布式微服务架构到单体应用程序的转变有助于实现更高的规模、弹性和降低成本”，有人把这篇文章在五一期间转到了reddit 和 hacker news 上，在Reddit上热议。这种话题与业内推崇的微服务架构形成了鲜明的对比。从“微服务架构”转“单体架构”，还是Amazon干的，这个话题足够劲爆。然后DHH在刚喷完Typescript后继续发文《即便是亚马逊也无法理解Servless或微服务》，继续抨击微服务架构，于是，瞬间引爆技术圈，登上技术圈热搜。

今天上午有好几个朋友在微信里转了三篇文章给我，如下所示：

看看这些标题就知道这些文章要的是流量而不是好好写篇文章。看到第二篇，你还真当 Prime Video 就是 Amazon 的全部么？然后，再看看这些文章后面的跟风评论，我觉得有 80%的人只看标题，而且是连原文都不看的。所以，我想我得写篇文章了……

原文解读

要认清这个问题首先是要认认真真读一读原文，Amazon Prime Video 技术团队的这篇文章并不难读，也没有太多的技术细节，但核心意思如下：

1）这个系统是一个监控系统，用于监控数据千条用户的点播视频流。主要是监控整个视频流运作的质量和效果（比如：视频损坏或是音频不同步等问题），这个监控主要是处理视频帧，所以，他们有一个微服务主要是用来把视频拆分成帧，并临时存在 S3 上，就是下图中的 Media Conversion 服务。

2）为了快速搭建系统，Prime Video团队使用了Serverless 架构，也就是著名的 AWS Lambda 和 AWS Step Functions。前置 Lambda 用来做用户请求的网关，Step Function 用来做监控（探测器），有问题后，就发 SNS 上，Step Function 从 S3 获取 Media Conversion 的数据，然后把运行结果再汇总给一个后置的 Lambda ，并存在 S3 上。

整个架构看上去非常简单 ，一点也不复杂，而且使用了 Serverless 的架构，一点服务器的影子都看不见。实话实说，这样的开发不香吗？我觉得很香啊，方便快捷，完全不理那些无聊的基础设施，直接把代码转成服务，然后用 AWS 的 Lamda + Step Function + SNS + S3 分分钟就搭出一个有模有样的监控系统了，哪里不好了？！

但是他们遇到了一个比较大的问题，就是 AWS Step Function 的伸缩问题，从文章中我看到了两个问题（注意前方高能）：

  1. 需要很多很多的并发的 AWS Step Function ，于是达到了帐户的 hard limit。
  2. AWS Step Function 按状态转换收费，所以，贵得受不了了。

注意，这里有两个关键点：1）帐户对 Step Function 有限制，2）Step Function 太贵了用不起。

然后，Prime Video 的团队开始解决问题，下面是解决的手段：

1） 把 Media Conversion  和 Step Function 全部写在一个程序里，Media Conversion 跟 Step Function 里的东西通过内存通信，不再走S3了。结果汇总到一个线程中，然后写到 S3.

2）把上面这个单体架构进行分布式部署，还是用之前的 AWS Lambda 来做入门调度。

EC2 的水平扩展没有限制，而且你想买多少 CPU/MEM 的机器由你说了算，而这些视频转码，监控分析的功能感觉就不复杂，本来就应该写在一起，这么做不更香吗？当然更香，比前面的 Serverless 的确更香，因为如下的几个原因：

  1. 不再受 Step Function 的限制了，技术在自己手里，有更大的自由度。
  2. 没有昂贵的 Step Function 云成本的确变得更低了，如果你把 Lambda 换成 Nginx 或 Spring Gateway 或是我司的 Easegress，你把 S3 换成 MinIO，你把 SNS 换成 Kafka，你的成本 还能再低。

独立思考

好了，原文解读完了，你有自己的独立思考了吗？下面是我的独立思考，供你参考：

1）AWS 的 Serverless 也好， 微服务也好，单体也好，在合适的场景也都很香。这就跟汽车一样，跑车，货车，越野车各有各的场景，你用跑车拉货，还是用货车泡妞都不是一个很好的决定。

2）这篇文章中的这个例子中的业务太过简单了，本来就是一两个服务就可以干完的事。就是一个转码加分析的事，要分开的话，就两个微服务就好了（一个转码一个分析），做成流式的。如果不想分，合在一起也没问题了，这个粒度是微服务没毛病。微服务的划分有好些原则，我这里只罗列几个比较重要的原则：

  • 边界上下文。微服务的粒度不能大于领域驱动里的 Bounded Context（具体是什么 大家自行 Google），也就是一个业务域。
  • 单一职责，高内聚，低耦合。把因为相同原因变化的合在一起（内聚），把不同原因变化的分开（解耦）
  • 事务和一致性。对于两个重度依赖的功能，需要完成一个事务和要保证强一致性的，最好不要拆开，要放在一起。
  • 跟组织架构匹配。把同一个团队的东西放在一起，不同团队的分开。

3）Prime Video 遇到的问题不是技术问题，而是 AWS  Step Function 处理能力不足，而且收费还很贵的问题。这个是 AWS 的产品问题，不是技术问题。或者说，这个是Prime Video滥用了Step Function的问题（本来这种大量的数据分析处理就不适合Step Function）。所以，大家不要用一个产品问题来得到微服务架构有问题的结论，这个没有因果关系。试问，如果 Step Funciton 可以无限扩展，性能也很好，而且白菜价，那么 Prime Video 团队还会有动力改成单体吗？他们不会反过来吹爆 Serverless 吗？

4）Prime Video 跟 AWS 是两个独立核算的公司，就像 Amazon 的电商和 AWS 一样，也是两个公司。Amazon 的电商和 AWS 对服务化或是微服务架构的理解和运维，我个人认为这个世界上再也找不到另外一家公司了，包括 Google 或 Microsoft。你有空可以看看本站以前的这篇文章《Steve Yegg对Amazon和Google平台的吐槽》你会了解的更多。

5）Prime Video 这个案例本质上是“下云”，下了 AWS Serverless 的云。云上的成本就是高，一个是费用问题，另一个是被锁定的问题。Prime Video 团队应该很庆幸这个监控系统并不复杂，重写起来也很快，所以，可以很快使用一个更传统的“服务化”+“云计算”的分布式架构，不然，就得像 DHH 那样咬牙下云——《Why We’re Leaving the Cloud》（他们的 SRE 的这篇博文 Our Cloud Spend in 2022说明了下云的困难和节约了多少成本）

后记

最后让我做个我自己的广告。我在过去几年的创业中，帮助了很多公司解决了这些 分布式，微服务，云原生以及云计算成本的问题，如果你也有类似问题。欢迎，跟我联系：[email protected]

另外，我们今年发布了一个平台 MegaEase Cloud，就是想让用户在不失去云计算体验的同时，通过自建高可用基础架构的方式来获得更低的成本（至少降 50%的云计算成本）。目前可以降低成本的方式：

  1. 基础软件：通过开源软件自建，
  2. 内容分发：MinIO + Cloudflare 的免费 CDN，
  3. 马上准备发布的直接与底层IDC合作的廉价GPU计算资源…

欢迎大家试用。

如何访问

注：这两个区完全独立，帐号不互通。因为网络的不可抗力，千万不要跨区使用。

产品演示

介绍文章

 

Slack 工程团队发表了一篇博文，深入分析了他们近期对基于Chef的配置管理系统所做的改进，目的是在不干扰现有工作流程的情况下，使部署更安全、更有弹性。更新后的基础设施消除了单点故障，并在可用区之间引入了分阶段的环境感知型部署流程，降低了在资源配置和配置变更过程中发生大规模故障的风险。

 

以前，Slack 的 EC2 配置依赖于单一的共享 Chef 生产环境。尽管通过 cron 任务将集群中的 Chef 运行错开可以减少并发，但任何对中央环境的不良更改都可能立即传播到新配置的节点，尤其是在快速横向扩展期间，这会带来显著的可靠性风险。为解决这个问题，Slack 将单体的 Chef 生产环境拆分为多个独立的单元（如 prod-1 至 prod-6），每个单元绑定到特定的可用区。该策略可以确保配置变更每次仅影响一个相对比较小的节点子集，有效地限制了影响范围，从而可以实现更安全的故障检测与修复。

 

Slack 还调整了触发 Chef 运行的方式。由于分阶段环境不再兼容固定的 cron 计划，工程师构建了一个名为 Chef Summoner 的服务。Chef Summoner 在每个节点上运行，通过增强版Chef Librarian服务触发的 S3 事件监听信号，并且仅在有新工件可用时调度 Chef 运行。为了避免负载峰值和资源争用，该服务采用 splay value 使任务执行在相互隔离的节点上错开进行。如果没有检测到新工件，为了确保合规性，Chef Summoner 将至少每 12 小时运行一次，即使是在静默期也能保障运营安全。

 

新发布模型采用了面向分阶段环境的发布序列模式。首先，Slack 将新的 cookbook 更改推广到沙箱和开发环境，然后逐步推广到 prod-1（被视为金丝雀），再然后是剩余的生产分片。因为 prod-1 接收频繁的小范围更新，所以在问题影响集群的更大部分之前就能被及早发现。只有在成功通过早期阶段后，后续环境才会更新。这进一步降低了风险，并使运维团队能够在问题广泛传播之前捕捉和修复回归。

 

这些更改体现了 Slack EC2 配置平台的渐进式演变，既提高了安全性，又不需要对现有的 cookbook 或角色做破坏性的大幅修改。展望未来，Slack 计划推出一个新的 EC2 生态系统，名为 Shipyard，旨在支持服务级部署、指标驱动的发布和完全自动化的回滚，解决当前架构中仍然存在的限制，并使平台能为尚未迁移到容器化环境的团队提供更好的支持。

 

Slack 的方法展示了如何通过精心构建的部署管道和环境分割来减轻大型动态基础设施生态系统中的操作风险。结合分阶段的生产环境、信号驱动的运行和 cron 安全网等回退机制，该公司提高了基础设施的可靠性，而又没有对开发和运维团队造成重大干扰——其他大型组织在演变自己的配置管理策略时可能会发现这种模式具有指导意义。

 

Slack 的做法体现了整个行业向更安全的渐进式大规模基础设施变更方式转变的趋势。Netflix、Uber 和 GitHub 等公司通过金丝雀发布、分阶段部署和功能开关等机制，在真实生产流量环境下验证变更并限制更新的影响范围。Slack 将类似的渐进式交付原则应用于其基于 Chef 的基础设施，展示了如何在无需进行颠覆性平台变更的前提下，通过现代化传统配置管理系统来提升安全性和可靠性。

 

为了降低部署风险，许多大型工程组织都采用渐进式的方法来推广技术。例如，金丝雀部署首先将更改暴露给一小部分用户或工作负载，允许团队在扩展发布范围之前监控性能和错误率。这种策略在 LinkedIn 等公司被广泛使用，通常与功能标志（将代码部署与功能暴露解耦）搭配，使团队能够在不重新部署的情况下快速回滚。

 

其他公司，包括 Netflix、Uber、GitHub 和 Etsy，通过功能标志、蓝绿部署和不可变基础设施扩展了这种模型，整个环境在流量转移之前都经过验证。在云原生环境中，像Kubernetes和ArgoCD这样的工具支持分阶段发布和同步波（synchronization wave），可以防止突然的负载峰值并控制更改传播。

 

这些方法的共同原则与 Slack 的交错式 Chef 策略类似：限制影响范围，在小范围内观察行为，并逐步扩展更改。通过应用分层发布控制，团队在运营大规模基础设施时实现了速度和可靠性的平衡。

 

https://www.infoq.com/news/2026/01/slack-chef-deployments/