年度回顾：2023 年成为微服务的转折点 [译]

长期以来，微服务被认为是云原生服务的应用架构标准。但现在，云计算巨头如 Amazon 和 Google 开始重新思考并改造微服务的架构。

我们对微服务的理解可能一直存在误区？

这是 Google 一组研究人员（由 Google 软件工程师 Michael Whittaker 领衔）在 6 月的 HOTOS '23 操作系统热点话题研讨会上发表的论文《向云应用的现代化发展》（PDF）的主要观点。

Whittaker 等人指出的问题在于，大多数情况下，微服务在架构设计上并不恰当。它们将逻辑边界（如何编写代码）和物理边界（如何部署代码）混为一谈，这就是问题的起源。

Google 工程师们提出了一种不同的方法。他们建议将应用程序作为逻辑上的单体构建，但由自动化运行时来管理，根据应用程序的需求和可用资源来决定工作负载的部署位置。

通过这种方法，他们成功地将系统的延迟降低了 15 倍，成本减少了多达 9 倍。

Kelsey Hightower 在 10 月对这项工作的评论是：“如果人们能从有组织的模块化代码开始，那么部署架构就能变成一个幕后的实现细节。”

微服务究竟出了哪些问题？

几个月前，Amazon Prime Video 的工程团队发布了一篇博客文章，在这篇文章中，他们说明了在视频监控这一领域，传统的单体架构相比于采用微服务和无服务器架构，展现出了更出色的性能。

热门故事推荐：

1. 年度回顾：2023 年对于微服务而言是个转折点
2. Amazon Prime Video 的微服务之旅，并非最终归于单体
3. 了解事件驱动架构的基本概念
4. 事件流与事件源：主要区别解析
5. 如何在服务网格中通过相互 TLS 保障微服务的安全

实际上，Amazon 在放弃微服务架构后，在运营成本上节省了高达 90%。

对于那些自幼受到微服务优越论教育的工程师和架构师们来说，这种观点无疑是颠覆性的。

“对于 Amazon 这样的公司而言，这篇文章简直是羞耻。它完全暴露了公司内部缺乏一致性和有效沟通的问题。”如是说行业分析师Donnie Berkholz，他最近创立了自己的分析机构Platify。

“亚马逊在服务导向架构方面一直是一个典范，这使得它的故事格外引人关注，”Ruby-on-Rails 的创造者和 Basecamp 联合创始人 David Heinemeier Hansson 评论说。“但现在，当这些理论被真实世界验证后，我们可以明确看到，在实际操作中，微服务 (microservices) 往往是复杂化系统的一大隐患，而无服务器 (serverless) 技术则进一步加剧了这个问题。”

亚马逊视频和微服务的经历

亚马逊工程师的任务是监控 Prime 提供给客户的成千上万的视频流。最初，这项任务是由一系列分布式组件来完成的，这些组件由 AWS Step Functions（一种无服务器编排服务）和 AWS Lambda 无服务器服务共同协调。

理论上，采用无服务器技术可以让团队独立地扩展每个服务。但实际上，至少对于团队所实施的组件，它们在承受预期负荷的仅 5% 时就遭遇了扩展的瓶颈。而且，为了监控数千个视频流，扩展的成本非常高，因为需要在多个组件之间传递数据。

最初，团队尝试优化各个组件，但这并未带来明显改进。于是，团队决定将所有组件整合到一个流程中，部署在亚马逊弹性计算云 (Amazon EC2) 和亚马逊弹性容器服务 (Amazon ECS) 上。

亚马逊团队最终得出结论：“微服务 (microservices) 和无服务器 (serverless) 组件确实可以在大规模环境下发挥作用，但选择使用它们而不是单体架构，需要根据具体情况来决定。”

微服务的不足之处

“微服务”这一术语可能首次由 Peter Rodgers 在 2005 年提出，当时他称之为“微型网络服务 (micro web services)”。他为许多人当时正思考的概念命名，特别是在网络服务和面向服务的架构（SOA）开始受到重视的时期。

软件工程师 Amanda Bennett 在一篇博客中解释说：“当时，‘微型网络服务’的主要目的是将庞大的单一‘单体 (monolithic)’设计分解为多个独立的组件/过程，使代码库变得更细致、更易于管理。”

这个概念在随后的几十年中得到了发展，尤其是在云原生计算领域，但直到近年来才开始在某些圈子中受到批评。

放大查看

软件工程师 Alexander Kainz 在 TNS 上进行了关于单体架构和微服务的深入比较。

谷歌工程师在他们的论文中指出了微服务方法的几个缺点，包括：

• 性能问题：序列化并通过网络向远程服务传输数据会降低性能，如果应用过于复杂，甚至可能成为性能瓶颈。
• 理解困难：在分布式系统中，微服务之间复杂的交互使得追踪错误异常困难。
• 管理挑战：不同应用部分可以独立更新，这虽然是优点，但也导致开发者需要管理众多各有其发布计划的二进制文件。而在本地服务上运行端到端测试更是一项挑战。
• API 变得脆弱：微服务之间的互操作性关键在于，一旦建立了微服务，其 API 就不能更改，否则会破坏依赖该 API 的其他微服务。因此，API 只能通过增加新的 API 来扩展，导致体系膨胀。

微服务的新发展？

当科技新闻媒体 The New Stack 首次报道亚马逊的最新动态时，很多人迅速指出，该视频团队所使用的架构并非纯粹的单体架构。

“这个故事其实不是从微服务转向单体架构，”AWS 云架构策略前副总裁 Adrian Cockcroft，现为 Nubank 顾问，他在 与 The New Stack 的一次采访 中这样说道。“这更像是从 AWS 的 Step Functions（一种服务器无需管理的服务）转向微服务的过程。而其中的一个问题是标签使用不当。”

他指出，在许多应用，尤其是内部应用中，开发成本往往超出运行成本。在这种情况下，使用 Step Functions 可以显著节省开发时间，尽管对于处理大量工作负载而言可能成本较高。

Cockcroft 补充说：“如果你知道最终会在一定规模上实施，可能一开始就会采用不同的构建方式。问题在于你是否了解要做的事情，以及预期的运行规模。”

谷歌的论文则从另一个角度着手，旨在简化开发者的工作，同时通过运行时的基础架构来寻找运行这些应用最节省成本的方法。

谷歌研究人员在论文中写道：“通过将所有执行任务交由运行时来处理，我们的方案不仅能够提供类似于微服务的优势，同时还能在性能更高、成本更低的情况下实现。”

反思之年

今年标志着对基本架构的深刻反思，其中不仅包括微服务的理念受到质疑。

例如，云计算也被重新审视。

6 月，37signals（负责运营 Basecamp 和 Hey 电子邮件应用）采购了一系列 Dell 服务器，决定退出云计算，打破了长久以来将业务外包以追求模糊定义的“更高效率”的传统。

David Heinemeier Hansson 在一篇博客文章中明确指出了云计算市场的误导之处：“市场上常说，云计算简单到几乎不需要人来操作，但我从未见过这种情况。无论是在 37signals 还是其他大型互联网应用公司中都是如此。云计算确实有其优势，但通常并不体现在减少运维人员上。”

当然，作为一名赛车手，DHH 自然更倾向于深入探究硬件本质。而且，还有其他人愿意支持这一理念。今年晚些时候，Oxide Computers 推出了他们的新型服务器系统，目标是为他人提供服务，以更经济高效的方式在自己的数据中心运行云计算任务。

随着云服务成本的逐渐显现，这种关注似乎至少变得更加普遍。FinOps 在 2023 年成为了一个显著的趋势，越来越多的组织选择了像 KubeCost 这样的公司来控制他们的云服务支出。许多人都对 DataDog 的一个客户因云监控而收到的 6500 万美元账单感到震惊。

可以说，对于年收入达数十亿美元的企业来说，6500 万美元用于云监控的费用可能是合理的。但是，随着首席架构师对过去十年的工程决策进行更深入的审视，他们可能会考虑做出一些调整。在这些调整中，微服务也不会是例外。

TNS 云原生通讯记者 Scott M. Fulton III 对本篇报告也有所贡献。