[译] Prime Video 并没有重回单体架构

原文：Amazon Prime Video’s Microservices Move Doesn’t Lead to a Monolith after All

作者：Scott M. Fulton III

太长不看版

本文主体由 Deepl 翻译，局部经过 ChatGPT 润色，后大面积返工。

1. Prime Video 不是整个 Amazon，也不是 AWS。
2. 身处 IT 企业，经常会误以为其他企业也有同等规模和素质的 IT 团队和投入
3. 架构跟时尚一样，会存在周期性的反复，业务目标和组织结构始终是个决定性因素
4. 和平年代和战争年代，对架构工作的前瞻性和时效性会有截然不同的选择。

正文

在任何组织结构中，一旦你把常规工作分解成过于琐碎的任务，并把它们委托给太多的人，他们的信息传递很快就会变得无法管理，组织也会停止发展。 去年 3 月 22 日，亚马逊 Prime Video 的工程师在一篇几周内未被注意的博文中报告说，他们在微服务平台上创建的，为确定流媒体视频的服务质量（QoS）水平而构建的服务质量监控应用程序，在低于 10% 负载情况下也会失败。

更重要的是，他们已经应用了一种补救措施：他们的帖子描述的解决方案是“单体应用”。

Prime Video 是《权力的游戏》和《了不起的麦瑟尔夫人》等点播节目的发源地，击败传统广播机构获得 NFL 周四晚间足球赛的直播权之后五年，发生了这样的问题。

成为流媒体市场领导者之一之后，Prime Video 同时为 1660 万观众提供服务。为了跟上体育实况观众的网络需求，Prime Video 的发展需要加速。

可惜，在 2022 年 9 月的橄榄球赛季开幕时，Prime Video 发出了不少以 “很抱歉给您带来了不便”开头的推文。

工程师们在博客中报告说，Prime Video 的工程师们将原本分离在孤立的 AWS Step Functions 和 Lambda 函数中的 QoS 监控操作整合到一个统一的代码模块中，解决了这一问题。

正如最初报道的那样，这件事的发展，似乎最终证实了许多组织在过去十年中的猜测，即维持系统复杂性和信息传递开销所产生的成本，完全有可能抵消微服务架构所带来的收益。

可想而知，那篇博文稍作炒作，就会有专家来给为服务架构宣判死刑。Ruby on Rails 的创始人 David Heinemeier Hansson 写道：“很明显，在实践中，微服务可能会诱导你构建不必要的复杂系统”，而.NET MVP Milan Jovanović 在 Twitter 上问：“我们会看到雄伟的单体重新出现吗？”。

杰夫-德莱尼（Jeff Delaney）在 YouTube 频道 Fireship 上说到：“这一举措给 Amazon 省了不少钱，但这也是个可能失去重要收入来源的坏消息”。

然而有其他专家，包括 CodeOpinion.com 的 Derek Comartin，他们将 Prime 的架构图相互比较，并注意到这些图和他们的附带叙述之间存在一些明显的脱节。

在 TNS 访谈中，有业界知名专家提到（并且得到 Amazon 高级网络服务工程师的证实），Prime Video 的新解决方案，不仅不符合单体应用的特征，和原架构相比，新版本在扩展性等重要方面，都是一个进化了的微服务架构

传说中的完美

AWS 的前云架构战略副总裁，现在是 Nubank 的顾问 Adrian Cockcroft 在接受 The New Stack 采访时说到：“这绝对不是一个从微服务到单体的故事，而是一个 Step Function 到微服务的故事。”

许多 The New Stack 的读者都知道，Cockcroft 是微服务架构的发起人之一，当然也是其最直接的支持者。自从成为顾问以来，他没有直接参与 Prime Video 或 AWS 的工作，但他熟悉那里实际发生的事情，当 Prime 的流质量监测项目开始时，他是 AWS 的高管。他为我们描述了一种原型设计策略，即企业利用 AWS 的 Step Functions，加上 Serverless 编排，对业务流程进行可视化建模。

通过这种采用策略，架构师基本上可以随意重组数字流程，最终发现它们与业务流程的最佳匹配。他对这种方法非常熟悉，因为它是 AWS 最佳实践的一部分–他也是起草人之一。在与我们交谈时，Cockcroft 赞扬了 Prime Video 团队，认为该团队遵循了这一最佳实践。

根据 Cockcroft 的理解，Step Functions 的决策，并不是以 NFL 体育赛事直播的规模来设计的。这些流程的最终状态需要有更多算法、更有效、更巩固。因此，要使 Step Functions 模型不仅用于原型设计，其诀窍不仅仅是可扩展性，而且还要具有可迁移性。

Cockcroft 说：“如果你知道你最终的业务规模，你可能会采用完全不同的架构。所以真正的问题有两个：在什么规模上，用什么方式做事？这是两个不同的问题，如果你不知道问题的答案，或者如果你知道它是小规模的、复杂的，但却不知如何构建这一系统，那么你会需要快速建设一个原型。”

然而，他建议，如果一个组织从一开始打算建设广泛使用的大规模系统，就应该在前期加大投入来解决这些问题。而 Prime Video 团队却没有这样的条件。在这种情况下，Cockcroft说，该团队遵循的是最佳实践：建立他们能做的最好的系统，以完成他们当时所理解的业务目标。

Cockcroft 解释说：“很多企业内部的 IT 工作负载都是相对较小规模的事情，往往会发现，建设系统的花费超出了系统的运行费用，在这种情况下，你大概会想通过超级快速的构建过程来节省开发人员的时间。我认为第一个版本……就是这样思考的，它并不打算大规模运行。”

随着基于 Step Functions 的系统的完善，根据这些相同的最佳实践，其进化的下一个阶段将是迁移阶段。与流行的观念相反，这种蜕变的一部分可能涉及服务整合。不管 Prime Video 的博文怎么说，但整合的结果不是一个单体。它现在是一个完全成熟的微服务，能够提供工程师所吹嘘的 90% 的成本削减。

Cockcroft说：“这是整个 Prime Video 工作负载的一个可独立扩展的部分，如果他们现在不运行直播流，它就会缩容或关停–这也是一开始就用 Step Function 和 Lambda 来构建它的重要原因。而如果流服务在发展，它就会进行扩容。那是一个微服务。Prime Video 的其他部分也是独立扩展的。”

这篇文章发表后，AWS 发言人联系了 The New Stack，就如何在组织内使用 Step Functions 提供了进一步的建议。这位发言人告诉我们，许多 AWS 客户，包括 Liberty Mutual 和 Taco Bell，都从 Step Functions 开始他们的架构计划，并选择在其部署规模扩大时继续使用该服务。发言人称，Prime 视频流 QoS 服务是 Prime 博客原文的主题，是流媒体公司在 AWS 平台上利用的许多服务之一，其他许多服务可能在可预见的未来继续使用Step Functions。

The New Stack 采访了 AWS Lambda 及其管理的容器服务 App Runner 的总经理 Ajay Nair。Nair 完整地证实了 Cockcroft 的说法，即该项目最初是如何以 Step Functions 为框架开始构建，以及它最终如何成为一个可扩展的微服务。

Nair 为我们概述了一个典型的微服务开发模式。原始应用的业务流程经常会被过于僵硬地耦合在一起，难以进化和适应。所以要进行解耦和隔离。这种分解使开发者能够定义合同，阐明每个服务的预期输入和输出、要求和结果。业务团队第一次可以直接观察到交易活动，而在这之前，这些要素完全被其复杂性和意外的设计限制所掩盖。

Nair 接着说，软件工程师可以把孤立的 Serverless 函数编排为服务。在这样做的过程中，他们可能会进一步分解一些服务，例如 AWS 把 S3 拆分为 300 多个微服务类。服务合并也是可能的：观察它们的行为可能会发现，它们实际上并不需要被独立扩展。

Nair 说：“这是任何架构的自然演进，所构建的服务会被整合和重新分配，由此产生的能力仍然有一个完善的合同，[并且]有一个单一的团队管理和部署它。所以它在技术上符合微服务的定义。”

分解

Kubernetes 的 Co Founder，现任微软企业副总裁的 Brendan Burns 说：“我认为微服务的定义不一定很明确，我倾向于从功能、扩展和团队规模的角度来考虑它。一个微服务应该是一个或多个一致的功能–这就像良好的面向对象设计。如果你的微服务是 CatAndDog() 服务，你可能要考虑把它分成 Cat() 和 Dog() 服务。但如果你的微服务是 ThatOneCatOnMyBlock()，那可能就是拆的太碎了。”

F5 的 Lori MacVittie 在接受 The New Stack 采访时解释说，“微服务的粒度仍然受到物理定律、网络速度、你实际包裹的[代码]多少的限制。你能做到这一点吗？你能在一个容器化的环境中做所有的功能，并使其发挥作用吗？可以。它将会慢得要命。人们不会使用它。”

Adrian Cockcroft 建议，即使是对于一个非开发人员来说，每个服务的核心目的也是可解释的，这应该是微服务架构本身的一个原则。仅仅是这一事实就应该减轻对不良设计选择的影响。

“它应该简单到一个人就能理解它是如何工作的，” Cockcroft 提倡说。“有很多关于微服务的定义，但是一个基本共识就是把问题分割成多个独立可扩展的块。”

F5 的 MacVittie 说：“我们说的不过就是没有标准化的 SOA，你可以看一下框架、对象和层次结构，你会觉得——这和以前没什么不同。我们可以对此进行争论。谁赢了？这有关系吗？亚马逊大概会说——你是对的，这是一个大的微服务，谢谢你。这能改变什么吗？不，他们已经解决了他们的一个问题，通过改变他们的设计方式。如果他们碰巧偶然发现了他们一开始就应该做的事情，根据互联网上的专家的说法，很好。这对他们有用。他们省钱了，而且他们确实暴露了其中的一个问题，就是在没有足够能力的时候进行了过度的分解。”

她继续说：“我们有点被物理困住了，我们不太可能比现在的速度更快，所以我们必须绕过这个问题。”

也许你已经注意到了：企业的技术故事总在二元对立中茁壮成长。为了将任何软件架构作为有价值的东西介绍给读者，供应商和记者将新架构与其他架构对立起来。当一个同等的系统或方法还不存在时，新的架构可能最终被描绘成颠覆传统的革命的预兆。

其中一个原因可能是，网上的讨论要么是由供应商主导，要么是由倾向于首先与供应商对话的记者主导。

Platify Insights 的分析师 Donnie Berkholz 说：“软件公司的运作方式和世界其他地方的运作方式之间一直存在着这种脱节。在一家软件公司，你有十倍于其他许多公司的人均人员配置和软件工程。这让你有很多能力和人才来做其他人无法跟上的事情。”

大概巨大的 Amazon 品牌掩盖了一个事实：Prime Video 是 AWS 的客户。Prime 工程师的博文被放大了。某些技术作家可能非常专注于微服务架构的某些方面，以至于他们让读者认为该架构的替代方案必须是什么样子。如果根据定义，微服务是小的（一位记者特别强调了这一点），那么其邪恶的对应物一定是大的。在这种假设下，如果亚马逊的 Prime Video 拥抱了单体架构，那么所有的 Amazon 也必须拥抱。在第四节为单体架构打出一次反败为胜的触地得分，并演奏每周四的的橄榄球主题曲。

Berkholz 说，“多年以来，我们看到同样的事情不断发生，领先的软件公司、网络公司和初创公司因为规模原因，遇到的问题，会在几年之后才开始冲击大众。”

积累

服务导向二分法中最初的“邪恶轴心”是 1999 年的 Big Ball of Mud。这个概念首先由伊利诺伊大学厄巴纳-香槟分校的 Brian Foote 和Joseph Yoder 教授提出，它提出了对分布式系统的支持。但是泥巴球不能简单地和单体应用划上等号。

泥巴球并不是一座由僵硬、不灵活、紧密耦合的进程组成的令人生畏的高塔，而是将程序杂乱无章地堆积在其他程序上，通过将文件转储到软盘上，用纸板箱从办公室的楼梯上搬下来，在它们之间进行数据交换。在 20 世纪 90 年代和 21 世纪初的架构乱世中，如果一个系统脱离了泥巴球架构，那么可以说他已经相当优秀了。

Forrester 高级分析师 David Mooter 回忆说：“SOA 架构的理念和微服务是相同的，这个理念就是，服务与业务能能力和业务运营模式相一致。而大多数组织只是随意构建 Web Service，也就是用 SOAP 来构建业务。杂乱无章的 SOAP，就变成了杂乱无章的泥巴球。因为每个人都在用 SOAP 来实现最差的 SOA，SOAP 的骂名由此而来。”

Mooter 在一篇名为《The Death of Microservices?》的 Forrester 博文中分享了他的一些最新观点。在与我们的采访中，他指出：“我认为，通过对亚马逊博客的一些反应，你会发现当你采用了最糟糕的微服务实践，并将责任归咎于微服务而不是你糟糕的架构决策时，每个人都说微服务糟透了…抛开微服务不谈：任何时髦的技术趋势都无法弥补糟糕的架构决策。”

泥巴球“是一个模糊的、可塑的隐喻”，过去四分之一个世纪以来几乎所有失宠的方法论或架构都与之相关。当微服务在组织中取得进展时，单体架构就会被戴上荆棘的皇冠。最近，通过一些巧妙的措辞，微服务背上了耻辱的名号。

The New Stack 的老朋友、专业工程教练 Laura Tacho 表示：“我们的行业在创新、实验和增长（有时被称为和平时期）与紧缩和追求效率（战时）之间像钟摆一样摆动，当然，大多数公司在不同领域都面临这两种情况，但显然我们现在处于紧缩时期。在这种时期，微服务拆分造成的效率影响就不再是一个易于回避的问题了”

Berkholz 一直在观察同样的趋势：“行业内一直在摇摆，从单体到微服务，然后又回来。几年前，它是 SOA，然后再回来。”

为了抵御这种周期性的摇摆，微服务的捍卫者说，他们的架构并不适合每一种情况，甚至不适合每一个组织。但这是个大问题。如果同时存在两个或更多相等的、相互竞争的解决方案，那么这个市场就会被判断为碎片化市场——而企业通常会主动避免参与碎片化市场。

“分散意味着问题还没有为每个人很好地解决，”Berkholz告诉我们，”当有很多不同的解决方案，而没有人整合在一个单一的解决方案上，在大多数时候是有意义的。这是企业需要关注的问题。这是一个支离破碎的生态系统，很难做出选择？或者这是一个有明确和明显主宰的生态系统？” Lori MacVittie 告诉我们，F5 Networks 会对其客户进行调查，询问他们的应用组合中被描述为单体、微服务、移动应用和中间件注入的客户/服务器应用的相对百分比。她告诉我们，大多数组织都在以其中的某个百分比运作。如果只问只把应用程序分为“传统的”还是“现代的”，通常是 ⁶⁰⁄₄₀ 的比例。“他们用不同的风格做事，这是一种混乱吗？我不这么认为。特定模式的应用会有特定的用途。”

微软的 Brendan Burns 表示：“我有点觉得微服务对单体并不是一个很好的争论，这就像争论向量与链表，或垃圾收集与内存管理。这些设计都是工具，更重要的是要了解你从每一种设计中得到的价值，以及你何时可以利用这种价值。如果你坚持对所有的东西进行微服务，你肯定会对一些单体进行微服务，而这些单体可能是你应该单独留下的。但如果你说，’我们不做微服务’，你可能会把一些敏捷性、可靠性和效率留在桌上。”

大泥球的创造者引用了康威法则，作为软件架构变得臃肿和不方便的原因：“任何组织设计一个系统（广义的定义）都会产生一个设计，其结构是该组织的通信结构的副本。”多年来，微服务的倡导者们将这一概念向前推进了几步，建议业务结构甚至组织结构图都应该被刻意改造，以便与软件、系统和服务保持一致。

Tacho 指出，当 IT 架构潮流的钟摆开始回摆，玩家们也会重新考虑既有观念，也许这不仅仅是康威法则敲响了警钟，甚至还还有一种可能：市场条件是否允许我们暂时无视康威法则，以便在效率和创新之间进行权衡？沿用前面战争与和平的比喻，Tacho 继续说道：“一切都是一种权衡。过去因为微服务可能导致开发减缓、流程变得不那么高效的决策，在和平时期可能完全没问题，但在战时还要不断为这些低效性辩护，则是令人厌倦的。在战时，大多数公司不会针对庞大的代码库进行重构的投资。他们必须考虑业务回报率更高的其他优先事项，但像亚马逊这样的庞然大物会拥有更多的灵活性。”

Forrester 的 Mooter 建议说：“你首先应该看的是你的业务， 什么是正确的架构？微服务不是目的，业务成果才是。你要实现的业务成果是什么？”，Forrester 称之为“结果驱动的架构”。“我们如何调整我们的 IT 系统和基础设施以及应用程序，以优化你的能力来实现这些？它将随着时间的推移而改变。”

微软的 Burns 说，“微服务设计的好处之一是，它拥有非常具体的 API，团队之间的合同很清晰，使小团队能够自主地行动。如果你的开发文化的其他部分阻止你的小团队自主运作，那么你就永远不会获得微服务的敏捷性好处。当然，微服务也有其他的好处，比如增加弹性，以及通过更优化的扩展来提高潜在的效率。这不是一个全有或全无的问题，但也是一个情况，即在实施微服务时，独立和自主的工程文化结构会做得更好。我不认为这与十年前与 DevOps 运动相关的文化变革有多大区别。”

Prime Video 在 NFL 橄榄球版权上进行了一场巨大的商业赌博，而随着时间的推移，这场赌博是否会得到回报，目前还没有定论。这一举措在 Prime Video 工程团队的某些敏感区域点燃了一把火。他们可能突然被要求提前提供原计划在三到五年后提供的能力。所以他们做了一个架构上的转变，这个转变可能是计划内的，也可能是被迫的。他们是否像他们的最佳实践建议的那样，在未来的道路上实现了业务灵活性？或者他们只是把 Prime Video 绑在一个服务合同上，他们的业务将被迫永远适应这个合同？从这个角度来看，人们很容易忘记哪个选项是单体，哪个是微服务。

这是我们向 AWS 的 Ajay Nair 提出的一个难题，他的回答值得密切关注，不仅仅是软件工程师：”建立一个可演化的架构软件系统是一种战略，而不是一种宗教。”

更新：自出版以来，这个故事已被更新，加入了 AWS 围绕 Step Function 提供的额外材料。