长期以来，微服务一直被认为是云原生服务应用程序架构的事实标准，现在像亚马逊和谷歌这样的云巨头正在重构它们。
翻译自年度回顾：2023 年是微服务的转折点 作者：Joab Jackson 是 The New Stack 的高级编辑，负责云原生计算和系统运营。 他从事 IT 基础设施和开发工作已超过 25 年，曾在 IDG 和 Government Computer News 任职。 在那之前，他。 也许我们对微服务的理解有问题？
这正是文章“迈向云应用程序的现代开发”（PDF） 中关于 HOTOS 的一组 Google 工程师（由 Google 软件工程师 Michael Whittaker 领导）'6月举办的第23届（第19届操作系统热点问题研讨会）。 正如 Whittaker 等人所指出的，微服务大多在架构上没有正确设置。 它们混淆了逻辑边界（如何编写）和物理边界（如何部署）。 这就是问题所在。 相反，谷歌工程师想出了另一种方法。 将应用程序构建为逻辑整体，然后由自动化运行时处理，该运行时根据应用程序的需求和可用资源决定在何处运行工作负载。 通过这种类型的延迟，他们能够将系统的延迟降低 15 倍，并将成本降低多达 9 倍。
如果人们可以从有序的模块化开始，我们可以将部署架构视为实现细节，“Kelsey Hightower*** 在评论这项工作时说。 几个月前，Amazon Prime Video 的工程团队发表了一篇博客文章，解释说单体架构的性能优于微服务和无服务器方法，至少在监控方面是这样。 事实上，亚马逊通过放弃微服务架构节省了 90% 的运营成本。
这一代工程师和架构师是在微服务的优越性下成长起来的，这种说法确实令人震惊。 “这篇文章对于亚马逊作为一家公司来说是一个真正的完全尴尬。 根本没有内部协调或协同沟通，“Platify的分析师Donnie Berkholz写道，她最近创办了自己的行业分析公司。 “这个故事的独特之处在于，亚马逊是面向服务架构的缩影，”Ruby-on-Rails的创建者兼BaseCamp的联合创始人D**Id Heinemeier Hansson说。 另一方面，无服务器只会让事情变得更糟。 ”
亚马逊工程师的任务是监控 Prime 向客户提供的数千个 ** 流。 最初，这项工作由一组分布式组件完成，这些组件由 AWS Step Functions（一种使用 AWS Lambda 无服务器服务的无服务器编排服务）协调。 从理论上讲，使用无服务器应该允许团队独立扩展每个服务。 然而，事实证明，至少在团队实现组件的方式上，当他们只达到预期负载的 5% 时，他们遇到了硬性扩展限制。 由于需要在多个组件之间传输数据，扩展以监控数千个流的成本也将变得不经济。 最初，该团队试图优化各个组件，但这并没有带来显着的改进。 因此，该团队将所有组件迁移到一个进程中，该进程托管在 Amazon Elastic Compute Cloud （Amazon EC2） 和 Amazon Elastic Container Service （Amazon ECS） 上。
微服务和无服务器组件是大规模执行工作的工具，但必须根据具体情况选择它们而不是单体架构，“亚马逊团队总结道。
可以说，“微服务”一词最早是由 Peter Rodgers 在 2005 年创造的，尽管他称它们为“微 Web 服务”。 他为这个概念起了个名字，这个概念在当时的网络服务和面向服务架构（SOA）时代越来越受欢迎。
当时'微网服务'背后的主要动力是将单个大型'单体'设计拆分为多个独立的组件进程，使库更加精细和易于管理，“软件工程师Amanda Bennett在一篇博客文章中解释道。 这个概念在随后的几十年里得到了广泛的采用，尤其是在云原生计算时代，直到最近几年，它才开始在某些领域受到批评。
软件工程师 Alexander Kainz 对单体架构和微服务与 TNS 进行了出色的比较。
在他们的文章中，谷歌工程师列出了微服务方法的一些缺点，包括：
性能：序列化数据并通过网络将其发送到远程服务可能会影响性能，如果应用程序变得足够复杂，甚至会导致瓶颈。
理解：在分布式系统中，由于微服务之间的许多交互，臭虫通常难以跟踪。
管理问题：认为应用程序的不同部分可以根据自己的时间表进行更新是一个优势。 但这导致开发人员必须管理大量二进制文件，每个二进制文件都有自己的发布时间表。 当您想要在本地运行的服务上运行端到端测试时，您可能会遇到困难。 API 变得易受攻击微服务互操作性的关键在于，一旦建立了微服务，就无法更改 API，以免破坏依赖于该 API 的其他微服务。 因此，只能通过添加更多 API 来扩展 API，从而导致膨胀。
一种新型的微服务？
当 The New Stack 首次报道有关亚马逊的新闻时，许多人很快指出，该团队使用的架构也不完全是单体的。
这绝对不是一个从微服务到单体的故事，“亚马逊网络服务前副总裁、现任Nubank顾问的Adrian Cockcroft在接受The New Stack采访时说。 我认为问题之一是标签错误。 ”
他指出，在许多应用程序中，尤其是内部应用程序，开发成本超过了运行时成本。 在这些情况下，Step Functions 在节省开发时间方面很有意义，但在处理大量工作负载时可能会付出代价。
如果你知道你最终会以一定的规模执行它，“Cockcroft说，”你可能一开始就会以不同的方式构建它。 所以问题是，你知道怎么做吗，你知道它会以什么规模运行吗？科克罗夫特说。
Google 通过简化开发人员的工作并使运行时基础架构能够找出运行这些应用程序的最具成本效益的方式来解决这个问题。
通过将所有执行责任委托给运行时，我们的解决方案能够提供与微服务相同的优势，但具有更高的性能和更低的成本，“谷歌研究人员写道。
今年已经进行了许多基本的架构重新审视，微服务并不是唯一受到质疑的理想。
例如，云计算也受到了审查。
今年6月，同时运营Basecamp和Hey电子邮件应用程序的公司37signals收购了一批戴尔服务器并离开了云，打破了数十年来将运营迁移到更高效率的传统，并给出了更模糊的异地定义。 “这是云营销的核心欺骗，即一切都会变得如此简单，以至于你几乎不需要任何人来操作它，”D**ID Heinemeier Hansson在一篇博客文章中解释道。 “我从来没见过。 在37signals，也没有其他人运行大型互联网应用程序。 云计算具有一些优势，但通常不会在减少操作人员数量方面。 当然，DHH是一名赛车手，所以他很自然地深入挖掘硬件层。 但也有其他人愿意支持这个赌注。 今年晚些时候，Oxide Computers推出了他们的新系统，希望为其他具有类似观点的人提供服务：在自己的数据中心以更具成本效益的方式运行云计算工作负载。 这种情绪似乎得到了更多的考虑，至少在云账单到期时是这样。 FinOps 在 2023 年变得可见，越来越多的组织转向像 Kubecost 这样的公司来控制他们的云支出。 有多少人对 Datadog 客户收到 6500 万美元的云监控账单感到惊讶可以说，对于一家产生数十亿美元收入的公司来说，支付 6500 万美元的可观测性账单可能是值得的。 但是，当首席建筑师仔细研究过去十年的工程决策时，他们可能会决定进行一些调整。 微服务也不例外。
TNS 云原生记者 Scott M富尔顿三世为本报告做出了贡献。