微服务已过时？谷歌内部正在测试的下一代架构范式

微服务的辉煌与困境

长期以来，微服务被认为是云原生服务应用程序架构的事实标准 ，在过去的十年中，微服务架构风靡全球，成为了众多企业构建应用程序的首选架构。它将大型应用程序拆分为多个小型、独立的服务，每个服务都可以独立开发、部署和扩展，这种高灵活性、可扩展性和可维护性的特性，让它在云原生时代大放异彩。

许多知名企业，如 Uber、Netflix 等，都采用了微服务架构，并取得了显著的业务成果。以 Uber 为例，在 2012-2013 年，它主要拥有两个单体服务，随着业务的增长，遇到了可用性风险高、部署困难、缺乏关注点分离和执行效率低下等问题。于是，Uber 采用了微服务架构，使得系统变得更加灵活，团队更加独立，系统可靠性提高，关注点分离更加清晰，职责更加明确，开发人员速度也得到了提升。

然而，随着时间的推移和业务的不断发展，微服务架构的一些问题也逐渐暴露出来。对于 Uber 来说，微服务架构也带来了新的挑战。随着公司规模的扩大，从 100 名工程师发展到 1000 名工程师，系统复杂性不断升高。使用微服务架构，用单体代码库换取黑盒功能，这些黑盒功能随时可能改变，并且很容易导致意外的行为。工程师必须对多个团队的多个服务进行检查，以调查问题的根本原因，理解服务之间的依赖关系变得相当困难，依赖的第 n 个服务的延迟峰值可能会导致上游问题的级联，调试变得困难。

办公管理软件公司 Managed by Q 也有类似的经历。他们的应用程序原本是一个部署在 ECS 上的 Django 单体，为了赶上现代化开发实践的步伐，转向微服务架构。但很快发现，每多一个新服务，就会增加一些基础设施，开发一个跨多个服务的功能需要做更多的工作。结果，在转向微服务两年之后，他们开始合并微服务，一些微服务被合到了单体中，其他的则合并成较大的服务。

从这些案例可以看出，微服务架构并非完美无缺。当企业规模不断扩大，业务复杂度不断增加时，微服务架构的维护成本、管理难度以及性能问题等都可能成为制约企业发展的因素。这也引发了业界对于微服务架构的反思：微服务，是否已经过时？

谷歌的新探索：打破传统，迈向新范式

面对微服务架构的困境，谷歌率先做出了新的探索。今年 6 月，一群谷歌员工（由谷歌软件工程师 Michael Whittaker 领导）发表了一篇名为 “Towards Modern Development of Cloud Applications” 的论文 ，对当下的微服务架构提出了挑战。

论文指出，从架构上讲，微服务本身存在问题，它将逻辑边界（如何编写代码）与物理边界（如何部署代码）混为一谈 。这一观点切中了微服务架构的要害，也引发了业界的广泛关注。

基于这样的认识，谷歌的工程师们提出了一种堪称 “微服务 2.0” 的方法。该方法鼓励开发人员编写分为逻辑组件的单片应用程序，将物理分布和执行模块化单片的挑战推迟到运行时，并且原子部署应用程序。简单来说，就是将应用程序构建为逻辑整体，但将其交给自动化运行时，后者可以根据应用程序所需的内容和可用的内容来决定在哪里运行工作负载。

为了实现这一方法，谷歌还推出了 Service Weaver 框架。这是一个用于编写、部署和管理分布式应用程序的编程框架，开发者可以在机器上本地运行、测试和调试 Service Weaver 应用程序，然后使用单个命令将该应用程序部署到云中。

通过这种新的方法和框架，谷歌取得了显著的成果。基于新提出的结构，他们能够将系统的延迟降低 15 倍，成本降低 9 倍 。这一成果无疑是令人瞩目的，也为云应用开发带来了新的思路和方向。

新架构的独特之处：模块化单体的魅力

谷歌提出的这种新架构，被称为 “模块化单体” ，它既不是传统的单体架构，也不是纯粹的微服务架构，而是一种融合了两者优点的创新架构。

在这种架构中，应用程序被构建为一个逻辑整体，就像单体架构一样，代码集中管理，便于开发和维护。但与单体架构不同的是，它又被分成了多个独立的组件，每个组件都有自己的职责和功能，组件之间通过明确定义的接口进行通信，这又具备了微服务架构的灵活性和可扩展性。

以一个电商系统为例，在传统的单体架构中，订单管理、商品管理、用户管理等功能模块都紧密耦合在一起，牵一发而动全身，任何一个小的改动都可能影响整个系统的稳定性。而在微服务架构中，这些功能模块被拆分成一个个独立的服务，虽然提高了灵活性和可扩展性，但也带来了服务间通信复杂、管理难度大等问题。

而模块化单体架构则很好地平衡了两者的优缺点。在这个电商系统中，订单管理、商品管理、用户管理等功能模块可以作为独立的组件存在，它们之间通过接口进行通信。当需要对订单管理组件进行升级或修改时，只要接口不变，就不会影响到其他组件的正常运行。同时，由于这些组件都在同一个代码库中，开发人员可以更方便地进行代码的管理和维护。

在谷歌推出的 Service Weaver 框架中，组件是一个非常独特且核心的概念。一个应用会包含多个组件，并且每一个组件都是一个 Go 的 interface。例如，在一个简单的字符串处理应用中，可能会有一个 Reverser 组件，它的定义如下：

// Reverser component. type Reverser interface { Reverse(context.Context, string) (string, error) }

上述代码定义了一个 Reverser 接口，其中包含一个 Reverse 方法，用于反转字符串。而这个接口的实现可以是这样：

// Implementation of the Reverser component. type reverser struct { weaver.Implements[Reverser] } func (r *reverser) Reverse(_ context.Context, s string) (string, error) { runes := []rune(s) n := len(runes) for i := 0; i < n/2; i++ { runes[i], runes[n-i-1] = runes[n-i-1], runes[i] } return string(runes), nil }

在实际使用中，我们可以通过weaver.Get()来获取一个组件的实例。比如：

func main() { // 初始化相关上下文等 root := weaver.Init(context.Background()) // 获取Reverser组件的实例 reverser, err := weaver.Get[Reverser](root) if err!= nil { log.Fatal(err) } // 调用Reverse方法反转字符串 reversed, err := reverser.Reverse(context.Background(), "Hello, Weaver") if err!= nil { // 处理错误 } fmt.Println(reversed) }

从组件的概念和使用方式可以看出，它和依赖注入中的 IOC 容器有着异曲同工之妙。在依赖注入中，我们也是先定义一个接口，然后实现这个接口，最后从 IOC 容器中获取这个接口的实例，以此来实现依赖解耦，简化对象创建流程。在 Service Weaver 框架中，通过组件的方式，同样达到了这样的效果，让代码的结构更加清晰，可维护性和可扩展性更强。

微服务与新架构的对比：优势与局限的碰撞

为了更清晰地了解谷歌提出的新架构的优势，我们不妨将它与传统的微服务架构进行一番对比。在性能、开发运维复杂度、成本等多个关键维度上，两者展现出了截然不同的特点。

性能表现：网络通信的挑战与突破

在性能方面，微服务架构存在着一些先天的不足。由于微服务之间通过网络进行通信，序列化数据并通过网络发送数据的开销越来越成为瓶颈。当应用程序变得足够复杂，微服务数量众多时，这些开销会显著增加，导致系统性能下降，延迟升高 。

相比之下，谷歌的模块化单体架构则在性能上展现出了明显的优势。由于应用程序被构建为一个逻辑整体，减少了服务间的网络通信次数，从而降低了延迟。根据谷歌的实验结果，基于新架构的原型应用最多可减少延迟 15 倍 ，这一数据充分证明了新架构在性能提升上的巨大潜力。

开发运维复杂度：分工与协作的权衡

从开发和运维的复杂度来看，微服务架构虽然将应用程序拆分成多个小型服务，使得每个服务可以独立开发、部署和扩展，提高了开发的灵活性，但也带来了管理上的挑战。开发人员需要管理多个服务的生命周期，协调不同服务之间的接口和依赖关系，这无疑增加了开发的难度和成本。同时，运维团队也需要面对多个服务的部署、监控和维护工作，运维复杂度大幅提升。

而模块化单体架构则在一定程度上简化了开发和运维的流程。开发人员可以将应用程序作为一个整体进行开发和测试，减少了服务间协调的工作量。在运维方面，由于应用程序是原子部署的，避免了不同版本之间的交互问题，降低了运维的风险和难度。此外，自动化运行时的引入，使得系统能够根据应用程序的需求自动分配资源，进一步提高了运维的效率。

成本考量：资源利用与经济账的计算

成本也是衡量架构优劣的重要因素。在微服务架构中，由于每个服务都需要独立的资源支持，包括服务器、内存、网络带宽等，随着服务数量的增加，资源的消耗也会大幅上升，从而导致成本的增加。

谷歌的新架构在成本控制上表现出色。通过将应用程序作为一个逻辑整体进行部署，减少了资源的浪费，提高了资源的利用率。同时，由于新架构能够降低系统的延迟，提高性能，使得同样的硬件资源能够支持更多的业务量，从而间接降低了成本。根据谷歌的实验，新架构最多可将成本降低 9 倍 ，这对于企业来说，无疑具有巨大的吸引力。

行业的回响：变革中的思考与展望

谷歌的这一探索，无疑在行业内引起了巨大的回响。它让人们开始重新审视微服务架构的地位，也为其他企业在架构选择上提供了新的思路。

其实，并非只有谷歌一家企业对微服务架构产生了质疑并做出改变。亚马逊 Prime Video 团队就曾发布案例研究，称他们决定放弃无服务器、微服务架构，改用单体架构 。这一举措为他们节省了 90% 的运营成本，并简化了系统。亚马逊 Prime Video 的视频质量分析（VQA）团队最初使用一组分布式组件来监控视频流，这些组件由 AWS Step Functions 和 AWS Lambda 编排。但在实际运行中，他们发现这些组件的扩展性存在问题，成本也过高。于是，团队将所有组件转移到一个进程中，托管在亚马逊弹性计算云（Amazon EC2）和亚马逊弹性容器服务（Amazon ECS）上，采用单体架构，成功降低了成本，提升了系统的伸缩能力。

这些案例表明，在架构选择上，并没有一种放之四海而皆准的方案。企业需要根据自身的业务特点、发展阶段以及技术实力等因素，综合考虑选择最适合自己的架构。

当然，新架构的推广和应用也并非一帆风顺。从开发人员的角度来看，习惯了微服务架构的开发模式，要转变观念接受新的架构范式，需要一定的时间和学习成本。而且，新架构往往需要新的技术栈和工具支持，这也对开发人员的技术能力提出了更高的要求。

从技术生态的角度来看，目前的软件开发生态大多是基于微服务架构构建的，新架构的出现可能会面临与现有技术生态不兼容的问题。例如，一些针对微服务架构的监控工具、服务治理框架等，在新架构下可能无法直接使用，需要进行相应的调整和适配。

尽管面临诸多挑战，但新架构的出现无疑为软件开发的未来发展指明了方向。随着技术的不断进步和实践的不断积累，我们有理由相信，新架构将逐渐完善，并在未来的软件开发中发挥重要作用。在未来，或许会出现更多融合创新的架构模式，它们将充分汲取各种架构的优点，为企业的数字化转型提供更强大的技术支持。