作者 | 刘军

4 月 15 日-16 日，由 InfoQ 主办的 DIVE 全球基础软件创新大会通过云上展厅的形式成功召开。在微服务 & 服务治理专场，Apache Dubbo PMC、Dubbo 开源项目负责人刘军带来了主题为《Dubbo3 落地实践及其 Mesh 解决方案》的演讲，以下为主要内容。

下一代云原生服务框架 Dubbo3

首先带大家了解下 Dubbo3 到底是什么？与 2.7 架构的主要区别是什么？提供了哪些特性、可以解决哪些实际的问题？其中也包括大家都关心的兼容性、升级成本以及与 HSF2 的关系等问题。

Dubbo3 核心设计原则与特性

我们定义 Dubbo3 是下一代的云原生服务框架，但 3.0 架构到底都包含哪些内容？ 先来看下 Dubbo 3.0 的一些核心设计原则：

• 首先，在架构层面，Dubbo 是面向云原生设计的，支持超大规模的微服务集群实践 - 百万实例级别，期望通过智能化流量调度系统提升系统稳定性与吞吐量；

• 在策略层面，Dubbo3 的内核将是毫无保留开源的，它将成为国内公有云事实标准的服务框架，得到各大公有云厂商的支持，并通过灵活的 SPI 扩展机制支持不同部署场景的定制化需求；

• 在业务价值上，Dubbo3 将显著降低单机资源消耗，提升全链路资源利用率与服务治理效率。

这就是 3.0 设计过程中遵循的核心原则或目标，也让我们从一个更高的层面认识了 Dubbo3。

具体到选型 Dubbo3 框架，大家除了会关心 Dubbo3 提供了哪些新功能，Dubbo 老用户还会关心 Dubbo3 的兼容性，Dubbo3 的迁移成本以及其能带来的核心价值。

首先，Dubbo3 是从其自身 2.0 架构演进而来，因此它继承了 2.0 几乎所有的特性，且保持了对 Dubbo2 的完全兼容，因此，老用户几乎可以零成本迁移到 Dubbo3。

其次，Dubbo3 是在企业实践经验的基础上演进而来的。Dubbo 最初是由阿里开源并贡献给 Apache 社区，而这一次，阿里也已将 Dubbo3 定位为其下一代服务框架。因此，Dubbo3 融合了 HSF2 的几乎所有服务治理特性，并且已经开始在阿里巴巴全面取代 HSF2 框架。

Dubbo3 提供的核心特性主要包括四部分：

• 全新服务发现模型。应用粒度服务发现，面向云原生设计，适配基础设施与异构系统，性能与集群伸缩性大幅提升。

• 下一代 RPC 协议 Triple。基于 HTTP/2 的 Triple 协议，兼容 gRPC，网关穿透性强、多语言友好、支持 Reactive Stream。

• 统一流量治理模型。面向云原生流量治理，SDK、Mesh、VM、Container 等统一治理规则，支持更丰富的流量治理场景。

• Service Mesh。Sidecar Mesh 与 Proxyless Mesh，更多架构选择，降低迁移、落地成本。

为什么要升级 Dubbo3？

接下来，我将重点分析升级 Dubbo3 能带来的收益。 首先是性能、资源利用率的提升。升级 Dubbo3 的应用预期能实现单机内存 50% 的下降，对于越大规模的集群效果将越明显，Dubbo3 从架构上支持百万实例级别的集群横向扩展,同时依赖应用级服务发现、Triple 协议等可以大大提供应用的服务治理效率和吞吐量。

其次，Dubbo3 让业务架构升级变得更容易、更合理。其中值得重点关注的就是协议，在 2.x 版本中，web、移动端与后端的通信都要经过网关代理，完成协议转换、类型映射等工作，Triple 协议让这些变得更容易与自然，并通过流式通信模型满足更多的业务场景。

最后，得益于 Dubbo3 的完善云原生解决方案，Dubbo3 可以帮助业务屏蔽底层云原生基础设施细节，使得业务的迁移成本更低。

Dubbo3 的首个社区版本发布于 2021 年 6 月，在此之后，经过了多个版本的快速迭代。自 3.0.6 版本开始，Dubbo3 已经进入稳定迭代状态，并同步发布了 Java、Golang 等多语言 SDK 版本，目前最新版本的核心功能已经稳定并可用于大规模生产实践。

之前我们提到过，Dubbo3 不止是一个社区版本，它也是阿里定义的下一代服务框架，Dubbo3 已经在整个阿里经济体大规模推开，包括阿里的多条生态业务线、阿里电商系统以及阿里云。

其中，阿里生态如本地生活饿了么、钉钉、考拉等都已经全面升级 Dubbo3；天猫、淘宝等电商核心链路也已启动 Dubbo3 升级，预期 2022 双 11 都将跑在 Dubbo3 之上；阿里云的微服务平台、多条产品线目前也完全基于 Dubbo3 构建。

此外，像小米、工商银行、风火递、平安健康等企业也已经成功实践了 Dubbo3 核心特性，社区也在持续收到更多企业对于 Dubbo3 的调研及试点咨询。

Dubbo 官方专门开辟了一个 Dubbo3 用户登记窗口，在试点/使用/调研 Dubbo3 的用户都可在此填写信息，包括对 Dubbo 的期待，社区将在后续与登记用户取得联系并探索深入支持与合作的可能性。如果你当前正在推动或调研 Dubbo3 的企业实践，可以在此 issue 登记使用信息，一方面可以得到社区开发者的更快速的支持，另一方面也方便社区用户之间的互相交流。

GitHub 地址：https://github.com/apache/dubbo/issues/9436

Dubbo3 企业实践案例

下面，我将分享一些 Dubbo3 的企业实践案例，看看 Dubbo3 已经在哪些企业得到了应用，解决了哪些实际问题，取得了什么效果，给大家引入 Dubbo3 做一些稳定性与功能性的参考。

工商银行的 Dubbo3 实践

工商银行选型 Dubbo3 的应用级服务发现架构，核心原因是 2.x 版本架构在超大规模集群实战上的性能和容量瓶颈。

上图右侧是经典的 Dubbo 的工作原理图，服务提供者和消费者通过注册中心协调实现地址的自动发现。

工商银行面临的主要瓶颈是在注册中心与服务消费端，接口级别地址的数量已经是亿级规模，一方面存储容量达到瓶颈、另一方面推送效率明显下降；而在消费端这一侧，Dubbo2 框架常驻内存已超 40%，每次地址推送带来的 cpu 等资源消耗率也非常高，影响正常的业务调用。

这已经是架构问题，通过常规的性能优化无法从根本上解决问题。因此工商银行采用了 Dubbo3 中提出的应用级服务发现模型，经过实测，新的服务发现模型能实现节点到注册中心间数据传输量 90% 的下降，这就使得注册中心的压力极大降低，同时消费端的框架常驻内存也实现超 50% 下降。

下面是工商银行联合 Dubbo 社区给出的一组基于真实服务特点给出的模拟压测数据。

上图是对使用了应用级服务发现的消费端进程采样的内存对比数据。其中横轴是不同的 Dubbo 版本，纵轴是实际采样到的内存表现，可以看到 Dubbo 2.6、2.7 版本表现几乎一致，而升级到 3.0 版本后，即使不升级应用级服务发现，内存也降低接近 40%，而当切换到应用级服务发现之后，内存占用下降到只有原来的 30%。

上图是消费端的 GC 情况统计，同样的，横轴是不同的 Dubbo 版本，纵轴是实际采样到的 GC 表现。这里的压测数据，是通过模拟注册中心不停的往消费端进程推送地址列表的场景得到的。可以看到 Dubbo 2.6、2.7 版本表现几乎一致，而在 3.0 版本中切换到应用级服务发现之后，GC 已经趋近于零次。

阿里生态跨网关互通

第二个案例是 Dubbo3 的 Triple 协议在阿里经济体的应用。

阿里经济体内很多业务之间都有数据互通的诉求，相互之间需要互相调用，很多这样的调用在部署架构上都是跨域的，因此面临服务治理数据隔离、访问安全性等问题，所以不得不考虑基于网关的互通方案。

在升级 Dubbo3 之后，由于 Triple 协议从设计上对网关更友好、原生支持 TLS 安全链接，通过直接将 HSF2 的应用升级为 Dubbo3，Dubbo3 业务暴露 Triple 协议，可以实现高效、安全得的多条业务线的跨域互通。 目前包括未来阿里经济体内的跨域互通方案，都将会运行在 Dubbo3 协议之下。

阿里巴巴的 Dubbo3 实践

Dubbo3 在阿里内部上线后，一个更大的优势在于其对整体架构稳定性的提升，新的服务发现架构使得对于整个集群容量、可伸缩性评估变得更容易、更准确。

上图中我们将应用开发粗略划分为业务开发、运维部署两个层次，其中变化比较频繁的因素包括服务（接口）、应用、机器实例。

在 2.x 时代，所有这三个因素的增长都会影响微服务集群的总体容量，尤其是接口增减带来的波动，对整体容量评估是非常不透明的。而在 3.0 中集群容量变化仅与应用名、机器实例两个因素相关，而我们容量评估的对象往往都是应用与实例，因此整个集群集群变的更稳定透明。

Dubbo3 Mesh 方案解析

最后分享下 Dubbo3 即将发布的 Mesh 解决方案。当前 Java、Golang 等语言都发布了 POC 或 beta 版本，关于这部分的正式版本将在 3.1 中和大家见面。

提到 Service Mesh，我们就会想到经典的 Sidecar Mesh 部署架构，Dubbo3 毫无疑问将提供对此部署架构的支持。

如上图所示，Dubbo 可以与 Sidecar 部署在同一个 Pod 或容器中，通过在外围部署一个独立的控制平面，实现对流量和治理的统一管控。控制面与 SIcecar 之间通过图中虚线所示的 xDS 协议进行配置分发，而 Dubbo 进程间的通信不再是直连模式，转而通过 Sidecar 代理，Sidecar 拦截所有进出流量，并完成路由寻址等服务治理任务。

Sidecar 模式的 Mesh 架构有很多优势，如平滑升级、多语言、业务侵入小等，但也带来了一些额外的问题，比如：

• Sidecar 通信带来了额外的性能损耗，这在复杂拓扑的网络调用中将变得尤其明显。

• Sidecar 的存在让应用的声明周期管理变得更加复杂。

• 部署环境受限，并不是所有的环境都能满足 Sidecar 部署与请求拦截要求。

针对上述问题，Dubbo 社区自很早之前就做了 Dubbo 直接对接到控制面的设想与思考，并在国内开源社区率先提出了 Proxyless Mesh 的概念，当然就 Proxyless 概念的说法而言，最开始是谷歌提出来的。

Proxyless 模式使得微服务又回到了 2.x 时代的部署架构。如上图所示，和我们上面看的 Dubbo 经典服务治理模式非常相似，所以说这个模式并不新鲜， Dubbo 从最开始就是这么样的设计模式。但相比于 Mesh 架构，Dubbo2 并没有强调控制面的统一管控，而这点恰好是 Service Mesh 所强调的，强调对流量、可观测性、证书等的标准化管控与治理，也是 Mesh 理念先进的地方。

在 Dubbo3 Proxyless 架构模式下，Dubbo 进程将直接与控制面通信，Dubbo 进程之间也继续保持直连通信模式，我们可以看出 Proxyless 架构的优势：

• 没有额外的 Proxy 中转损耗，因此更适用于性能敏感应用。

• 更有利于遗留系统的平滑迁移。

• 架构简单，容易运维部署。

• 适用于几乎所有的部署环境。

至于 Proxyless 是如何工作的，如上图所示，集成了 Proxyless 功能的 Dubbo3 进程部署在容器或 Pod 中，通过 xDS 与控制面做策略交互。但在 SDK 与控制面中间，有一个独立部署的 Agent 组件，它是 SDK 与控制面通信的代理组件，通常仅完成包括认证及证书更新等任务。

具体 Agent 组件的职责与特定的控制面选型相关，当然 Dubbo 也计划支持无 Agent 代理直连控制面的实现。但由于这个 Agent 并不在流量通信链路上，只负责证书的下发，理论上对整体架构并无太大影响。 当前 Dubbo3 提供支持的特性包括：

• 应用级别的服务地址发现。

• 路由规则等服务管控策略。

Proxyless 模型也面临一些限制，如：

• 绑定特定的 Control Plane。

• 多语言实现的限制。

• 与 Sidecar 版本功能上的差异。

• 无法复用如 Envoy 生态扩展，但 dubbo 扩展同样相对容易。

未来的 Dubbo3 Mesh 部署形态

当前 Dubbo3 对于 Mesh 的支持已经发布了 poc 版本，涵盖了 Java 与 Golang 两种语言实现，并将在随后的 3.1 版本中正式发布与大家见面，我们预测在未来的一段时间内，Sidecar 模式与 Proxyless 模式将长期共存，尤其是从稳定性、性能、迁移成本等多方面考量。 通过混合部署的模式，将能够实现实现服务治理控制面的共享，应对不同场景的部署要求，适应复杂的基础设施环境并从总体上提升架构的可用性。

总结

Dubbo 长期以来都是国内开源微服务领域的首选 RPC 框架，在金融保险、互联网巨头、科技公司、各大传统企业中都有着非常广泛、大规模的应用。而 3.0 作为 Dubbo 面向云原生的下一代服务框架，受到了以阿里巴巴为代表的企业全力支持，随着 Dubbo3 在饿了么、考拉、钉钉、阿里巴巴、阿里云、工行银行、小米、平安健康、风火递等企业的大规模落地，标志着 Dubbo3 正式步入了稳定迭代状态。

同时，Dubbo3 作为国内首个提出 Proxyless Mesh 方案的开源社区，已经在社区全面启动了对 Service Mesh 解决方案的开发与支持，并将在 3.1 中迎来首个正式版本发布。如果你当前正在推动或调研 Dubbo3 的企业实践，可以在此 issue 登记使用信息。

作者简介：刘军，Dubbo 开源社区负责人，Apache Dubbo PMC，推动 Dubbo 重启开源并成为 Apache 顶级项目，领导了 Dubbo3 的整体架构设计与部分开发工作。当前工作在阿里云-云原生应用平台团队，主要负责下一代云原生服务框架的演进推广相关工作，开源爱好者。