ITPUB

微服务“水逆”之年,谷歌弃用微服务成本直接降9倍!

“长期以来,微服务被认为是云原生服务应用程序架构的事实方法,现在亚马逊和谷歌等云巨头开始重构微服务。也许我们做微服务的方式全错了?”这是由一群谷歌员工(由谷歌软件工程师 Michael Whittaker 领导)发表的一篇题为“Towards Modern Development of Cloud Applications”的研究论文的核心观点。

正如 Whittaker 等人指出的那样,从架构上来说,微服务很大程度上没有正确设置。错误地将逻辑边界(如何编写代码)与物理边界(如何配置代码)混为一谈。这就是问题的开始。
取而代之的是,谷歌工程师提出了另一种新的方法。将应用程序构建为逻辑整体,但将其交给自动化运行时,自动化运行时间根据应用程序的需求和可用内容来决定在何处运行工作负载。基于新提出的结构,他们能够将系统延迟降低15倍,并将成本降低多达9倍。

Amazon Prime Video :弃用微服务,改用单体

几个月前,亚马逊流媒体视频平台 Prime Video 的工程团队发表了一篇博文,其中提出一个颇具争议的观点:“在视频监控领域,单体架构的表现优于微服务和无服务器架构。我们通过回归单体架构,实现了运营成本高达90%的节约。”这一消息对于那些长期接受微服务架构优越性理念的工程师和架构师来说,无疑是一次颠覆性的震撼。

亚马逊工程师的任务是监控平台传送给客户的数千个视频流。最初,这项工作是由 AWS Step Functions(无服务器编排服务、AWS Lambda 无服务器服务)编排的一组分布式组件完成的。理论上,无服务器架构应该允许团队独立地扩展每个服务。然而,实际上,团队发现他们面临了严格的扩展限制,仅为预期负载的5%。由于需要在多个组件之间传输数据,扩大规模以监控数千个视频流的成本变得异常高昂。

Image
▴原始的亚马逊视频传输系统

起初,团队尝试对各个组件进行优化,但这并未带来显著的改进。于是,他们转变策略,决定将所有组件集成到一个单一的进程中,用单体的解决方案以降低成本并提升应用的扩展性。亚马逊团队得出重要结论:“微服务和无服务器组件是可以在大规模环境中有效工作的工具,但是否采用它们应根据具体的应用场景和需求来决定。”

著名的微服务批评者 Ruby-on-Rails 的创始人及 Basecamp 的联合创始人 David Heinemeier Hansson 对此评论道:“有趣的是,亚马逊曾是面向服务架构的典范。如今,实践中获得的见解揭示了微服务可能会在不必要的情况下增加系统的复杂性。而无服务器架构可能进一步加剧这种复杂性。”

揭秘微服务:了解其隐藏的缺点

“微服务”这一术语最早由 Peter Rodgers 在2005年提出,他当时称之为"微网络服务”。在他命名这一概念时,网络服务和面向服务的架构(SOA)正日益普及,

“微网络服务的主要理念在于将单一的大型整体设计分解为多个独立的组件/流程,从而使得代码库更加精细且易于管理。”软件工程师 Amanda Bennett 在一篇博客文章中这样解释道。这一概念在接下来的几十年中得到了广泛的应用,尤其是在云原生计算领域。然而,微服务也面临着一些批评。在谷歌工程师们撰写的论文“Towards Modern Development of Cloud Applications”中,他们详细列举了微服务方法的一些潜在缺点,包括:

Image

▴软件工程师 Alexander Kainz 为 TNS 贡献了

关于单体应用和微服务的精彩比较

性能:通过网络序列化数据并将其发送到远程服务会损害性能,如果应用程序变得足够复杂,甚至可能导致瓶颈。

理解:鉴于微服务之间存在大量交互,分布式系统中的错误非常难以追踪。

管理问题:应用程序的不同部分可以按照自己的时间表进行更新被认为是一个优点。但这导致开发人员必须管理大量二进制文件,每个二进制文件都有自己的发布时间表。祝您使用本地运行的服务运行端到端测试好运。

API 变得脆弱:微服务互操作性的关键是,一旦建立了微服务,API 就无法更改,让它们破坏依赖于该 API 的任何其他微服务。因此,API 只能通过更多 API 进行扩展,从而造成臃肿。

颠覆传统微服务,一种新型微服务的提出?

当 The New Stack 首次报道亚马逊 Prime Video 团队放弃微服务架构,转而采用单体架构的消息时,众多读者纷纷指出,视频团队实际采用的架构并非传统意义上的单体架构。

AWS 前云架构战略副总裁、现任 Nubank 顾问的 Adrian Cockcroft 在接受 The New Stack 采访时强调:“这绝不是一个微服务转向单体架构的故事。” Cockcroft 继续解释:“这是一种新型的微服务架构。如果你预见到最终会达到一定规模,那么你可能会选择从一开始就采用不同的构建方式。关键在于,你是否知道如何构建?你是否清楚你需要运行的规模?”

谷歌的研究人员通过他们的论文恰恰解决了这个问题,使开发人员的工作更加轻松,同时也为运行时基础设施找到运行这些应用程序最具成本效益的方式。正如谷歌研究人员在论文中写的:“通过将所有执行职责委托给运行时,我们的解决方案能够提供与微服务相同的优势,同时实现更高的性能和更低的成本。”

基础架构需要被重新考虑的一年

2023年,许多基本的架构理念都经历了重新评估,微服务并不是唯一受到挑战的黄金标准。云计算也成为了关注的焦点。

例如,6月,同时运营 Basecamp 和 Hey 电子邮件应用程序的 37signals 公司购买了一批戴尔服务器,并决定离开云服务,这一举动违背了长期以来将运营转移到外部部署以提升效率的行业趋势。

37signals 的联合创始人兼 CTO David Heinemeier Hansson 在博客文章中解释道:“云服务营销的一大误区是,一切都会变得更加简单,几乎不需要任何人员来操作。但事实上我从没见过这样的情况,无论是我们 37signals,还是其他运行大型互联网应用程序的公司。云服务确实有一些优势,但通常不会减少运营人员的数量。”

当然,DDH 作为一名赛车手,自然对裸机有更深的偏好。但也有人愿意支持这种转变。Oxide Computers 就推出了他们的新系统,旨在为有类似想法的人提供服务:在自家数据中心以更低的成本运行云计算工作负载。

随着云服务账单的到期,这种情绪似乎得到了更多的关注。越来越多的组织开始转向 KubeCost 等公司来控制云服务支出,使得 FinOps 在2023年成为了一个热门话题。当 DataDog 的客户收到高达6500万美元的云监控账单时,这无疑让许多人感到震惊。

对于一家年收入数十亿美元的公司来说,6500万美元的可观测性费用可能是有价值的投资。但是,随着首席架构师更加细致地审视过去十年所做的工程决策,他们可能会决定进行一些调整。微服务也不例外。

原文链接:https://thenewstack.io/year-in-review-was-2023-a-turning-point-for-microservices/

Image