标签 可扩展性 下的文章

这两天技术圈里热议的一件事就是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计算资源…

欢迎大家试用。

如何访问

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

产品演示

介绍文章

 

开发软件就像一次旅行，在这个过程中，团队需要不断做出决策，既包括他们所构建产品的功能（即 MVP，最小可行产品），也包括支撑该 MVP 所需的架构（即 MVA，最小可行架构）。

 

采用这种方法的主要挑战在于，我们必须足够快速地构建出可发布的产品，以便团队能尽快获得关键反馈。

 

当团队寻求更快捷的获取反馈的方式时，他们必须决定，是选择一条他人已经走过的路径，还是另辟蹊径、自行探索。

 

有一种重用架构的方式，那就是使用其他团队已经采用的相同的平台或框架。一个优秀的平台或框架能让每个团队专注于自身独有的“增值部分”。重复造轮子毫无价值，因此忽视现有的平台和框架团队，实际上就是在浪费精力，未能聚焦于只有他们自己才能完成的事情。

 

平台和框架就像已经铺设好的道路，它们能够帮助团队在开发旅程中更快地前进，并提供定义明确的“出口匝道”或扩展点，让团队可以在需要时对平台进行扩展以满足自身的需求。但它们也附带一些副作用，可能使其变得不够理想。

 

团队需要针对如下问题做出判断，即何时（如果有的话）应当离开他人铺设的道路，通过扩展平台/框架，甚至开发全新的平台/框架，走出自己的路。

 

当团队以平台或框架作为其软件架构的基础时，所面临的挑战在于，选择一条最接近其目标目的地的“铺好的路”（即平台或框架），同时尽量减少绕行或新建工程。但是，MVP 的问题是这个“目的地”在项目初期往往是未知的。

平台和框架会替你做出许多决策，但其中有些是你根本不需要的

平台和框架通常具有一定的倾向性，这意味着在构建 MVA 时，团队需要做的架构决策更少。关键问题在于，团队能否接受平台开发者所做的那些决策？理想情况下，团队应审视自身所需的架构决策，并与平台已做出的决策进行对比。

 

这带来了两个重要的挑战：

  1. 团队往往会在实验获得的经验反馈中，逐步发现他们真正需要做哪些决策；

  2. 平台开发者所做的决策并不总是明确或最终的，尤其当平台提供了扩展点，要求使用团队自行填充代码时更是如此。在“铺好的路”这一隐喻中，这些扩展点正是团队可以偏离主路、走上自己方向的地方。

 

许多平台的决策是无害的，只要不影响团队必须满足的质量属性需求（QAR），就可以接受甚至忽略。判断这些决策是否会造成损害的唯一方法，就是通过实验暴露平台在哪些方面未能达成系统的目标。由于平台开发者所做的决策常常未被记录，甚至是未知的，所以团队必须要测试他们的系统（包括所依赖的平台），以确保架构目标（即 QAR）得以实现。

 

即使技术上可行，扩展平台或框架也可能非常复杂。其他使用该平台或框架的人可能不同意你所提出的决策及相关变更，或者他们可能更偏好其他方案，而这些方案又无法满足某些团队的实际需求。这也是为什么存在如此多功能相似的平台和框架的原因之一。

 

此外，当团队决定扩展某个平台或框架时，他们实际上做出了一个隐含承诺，也就是长期维护这些扩展。他们必须将这种成本和所需的时间/精力纳入决策考量。这包括未来升级应用以适配平台/框架新版本的成本和工作量；若不及时升级，可能导致应用崩溃、安全漏洞无法修复，也无法利用新版本在性能和可扩展性方面的改进。

平台和框架能节省时间，直到它们无法做到这一点为止

在我们的简化视角中，平台是指应用程序运行所使用的软件环境（以及提供支撑的基础设施），平台的一个样例就是 Amazon Web Services（AWS）。框架则是应用程序（或其一部分）部分完成的“骨架”，团队在它的基础上添加自身特定的业务逻辑，例如 Java Spring UI 框架。大语言模型（LLM）也可被视为一种平台，团队通过提示词（prompt）对其进行扩展。平台和框架通过提供大量现成的能力，简化了应用程序的开发。

 

但有时候，团队需要的功能与平台或框架所提供的有所差异，举例来说，LLM 可能无法处理团队所需输入类型，比如，需要处理电话通话的音频并响应指令。LLM 在录音室环境下表现良好，但面对在嘈杂的机场录制的语音时，可能就无法工作。团队需要先构建音频降噪过滤器，但随后可能发现这些过滤器仍不足以解决问题。此时，他们就不得不训练自己的 LLM，以便使用包含“噪声”的对话数据。

 

用“铺好的路”作比喻，LLM 提供了一条已被验证的路径，但它无法带领团队抵达真正想去的地方。一旦发生这种情况，团队别无选择，只能在如下三种方案中做出选择：尝试扩展该平台（如果可行）、寻找另一个平台，或者从头构建自己的平台。

 

他们的挑战在于，需要花费一定的时间才能判断，究竟是基于现有平台继续开发更高效，还是必须为自己的场景构建独特的方案。他们的选择受限于平台开发者所做的决策。如果能接受这些决策，那么基于平台开发可能是最佳选择；但如果不能接受，那么在此基础上开发就是在浪费时间，而时间，恰恰是他们最宝贵的资产。

帮助厘清替代方案的三个关键问题

MVP 和 MVA 本质上是对潜在解决方案的“下注”。它们可能正确，也可能错误，而评估这些“赌注”是否成功的唯一方式就是实验。以下三个关于MVP的核心问题，有助于判断平台是否满足你的需求：这个产品值得构建吗？它能否在预期负载下实现可扩展性和性能？ 它是否具备长期可维护性？

图 1：帮助确定架构决策的三个问题

 

团队在评估某个平台时，应结合这三个问题进行思考：

  1. 该平台有助于 MVP 的开发，还是阻碍 MVP 的开发？平台可能提供面向用户的功能，简化 MVP 的开发，但也可能附带团队无法接受的架构决策。借用道路的隐喻来说，唯一的方法是先沿着这条路走一小段，通过架构实验，检验平台所做的决策是否契合团队对 MVA 的需求。

  2. 该平台能否在预期的负载下实现可扩展性和性能？这里的难点在于，通常只有通过实验，你才能真正了解自己的可扩展性需求。借用道路的隐喻来说，你往往并不清楚自己需要的是一条车流稀少的双车道乡间小路，还是一条能够承载海量车流的高速公路。

  3. 基于该平台构建的架构是否具备长期可维护性？平台的演进速度通常比具体的业务系统更慢，因为它们的变更往往需要社区共识。当平台无法快速调整以满足需求时，团队就需要有明确的机制来扩展平台，直到平台本身能够做出相应修改。

 

这些问题不应该仅仅停留在激发思考和讨论的层面，必须通过实验进行实证评估。在实践中，这些实验体现为可执行的测试，可以在系统构建过程中持续运行。频繁对系统进行测试，以评估当前架构是否仍然适合目标用途，有助于避免后期出现不可控的大规模返工。

 

尽管上述三个问题看似按线性顺序展开，但实际上它们构成了一个循环（如图 1 所示）：针对性能/可扩展性和模块化所做的调整，不应危及整体解决方案的有效性。

结论

平台就像一条现成的道路，可以让团队在交付 MVP 的旅程中更加轻松，但前提是，这条路确实通往他们想去的地方。团队在使用平台时面临的核心挑战在于，至少在项目初期，他们并不完全清楚自己的目的地，因此也无法确定平台所提供的“铺好的路”是否能带领他们抵达那里。

 

判断这条道路是否适合其 MVP 的一个重要方法，就是先走一小段，看看方向是否仍然正确，而这个“正确的方向”，正是由团队的质量属性需求（QAR）所定义的。

 

最终，团队不可避免地会在某个时刻离开平台所提供的“铺好的路”，走出自己的路径。通过实验，他们可以判断何时、何地需要这样做，是扩展平台以满足自身需求，还是开发平台完全未提供的全新解决方案，甚至彻底替换掉原有的平台。

 

The Architect’s Dilemma: Choose a Proven Path or Pave Your Own Way?

这两天技术圈里热议的一件事就是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计算资源…

欢迎大家试用。

如何访问

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

产品演示

介绍文章