简介： 做过微服务开发的开发者相信对 Dubbo 都不陌生，Dubbo 是一款能帮助我们快速解决微服务开发、通信以及流量治理的框架。相比于之前只限定在 Java 语言范围内，Dubbo 的多语言版本在这两年呈现了良好的发展势头，其中，Dubbo Go 语言版本在功能、稳定性各个方面都已非常完备，其它几种主流的多语言版本在社区也有提供。

头图.png

作者 | 陆龟
来源 | 阿里巴巴云原生公众号

本文整理自作者在3月20日云原生中间件 Meetup 上海站的分享。回复关键字“中间件”可以获取视频录播地址和 PPT。

就在今天，Dubbo 社区刚刚发布了 3.0 的首个预览版本 - 3.0.0.preview。

https://github.com/apache/dubbo/releases/tag/3.0.0.preview

本文将和读者一起解读 Dubbo3 的首个 preview 版本：一方面，我们将深入分析 Dubbo3 云原生变革的核心理念；另一方面，我们将逐个解读 preview 版本的核心功能。

做过微服务开发的开发者相信对 Dubbo 都不陌生，Dubbo 是一款能帮助我们快速解决微服务开发、通信以及流量治理的框架。相比于之前只限定在 Java 语言范围内，Dubbo 的多语言版本在这两年呈现了良好的发展势头，其中，Dubbo Go 语言版本在功能、稳定性各个方面都已非常完备，其它几种主流的多语言版本在社区也有提供。

云原生视角的微服务变革

Dubbo 主要解决微服务开发、运行域问题，它和微服务的编程、通信、流量治理等密切关联，因此，在探寻 Dubbo3 的云原生变革之前，我们先尝试从云原生视角观察云原生基础设施带给微服务架构和实践的变革，进而总结出 Dubbo 这样一个和微服务实践密切相关的框架所面临的变革与挑战。

微服务在让业务开发演进更灵活、快捷的同时，也带来了一些它独有的特征和需求：如微服务之后组件数量越来越多，如何解决各个组件的稳定性，如何快速的水平扩容等。

这些诉求，尤其是运维、交付相关诉求，如微服务组件的生命周期、网络、通用服务绑定、服务状态管理等，并不应该是开发人员关注的重点，因为它们已经完全脱离了业务逻辑，开发人员更愿意专注在有业务价值组件上，但这个层次的诉求却是实现微服务交付的关键能力。开发者期望由底层基础设施来提供此类能力支持，而处于不同阶段发展的基础设施却不一定具备这样的能力，因此，在微服务软件架构和底层基础设施之间就出现了一条鸿沟，我们需要有组件能填补这一鸿沟，让微服务组件能更好的接入底层基础设施。

这里从一个更抽象的层面，尝试用两条发展曲线演示了软件架构诉求与底层基础设施能力丰富度之间的关系。总体上，两者之间的发展关系可拆分为两个阶段。

在第一个阶段，软件架构（这条红色的线）从单体应用、到面向服务的软件架构、再到微服务架构，快速演进，从而也提出了上文我们讲到的对基础设施对交付的诉求，这个时候基础设施层还多是以定制化的方式来满足软件架构的诉求，如过往的集中化的 ESB、各个不同的 PaaS 平台等。

第二个阶段，是从容器、Kubernetes 为代表的基础产品的出现开始，蓝线与红线之间的增长速度被快速拉近，以云原生技术为代表的底层基础设施丰富度得到了极大改善，它们不再只是被动的满足微服务开发的诉求，而是开始抽象更多的软件诉求到底层的基础设施，将它们下沉为基础能力，并开始以统一的、标准化的形式向上输出以满足微服务对交付、运维等的诉求，不仅如此，通过更深入的主动创新、持续的向上释放能力，底层基础设施还开始反过来影响微服务的开发、接入方式，如 sidecar、dapr 等模型。

Dubbo3 的云原生变革

通过上文云对原生基础设施演进给传统微服务带来变革的分析，我们得出，以 Dubbo 为代表的微服务开发框架，应重点在以下方向突破与变革。

更多的微服务组件及能力正下沉到以 Kubernetes 为代表的基础设施层。传统微服务开发框架应剔除一些冗余机制，积极的适配到基础设施层以做到能力复用；微服务框架生命周期、服务治理等能力应更好地与 Kubernetes 服务编排机制融合。
以 Service Mesh 为代表微服务架构给微服务开发带来的新的选择，但由于 Mesh 架构本身的复杂性，其距离大规模生产落地还有一段距离。我们相信，基于 ServiceMesh 的体系会逐步从孵化器走向成熟期，会有越来越多的企业采用 Service Mesh技术，但在未来在很长一段时间内，基于服务框架的传统微服务体系还将是主流，长期仍将占据半壁江山。

我们不妨回想一下，在云原生基础设施能力被充分释放前，围绕 Dubbo 构建微服务时，它给微服务开发提供了哪些能力？或者我们期望它提供哪些能力？

Dubbo2 提供了包括服务注册、服务发现、负载均衡、流量治理等相当丰富的能力，当然还包括微服务最需要的远程通信能力，这些能力很好地解决了微服务的诉求。

而在云原生架构之下，我们需要重新审视，Dubbo2 的哪些能力是冗余的，是需要接入基础设施的？哪些能力是已经不适合云原生时代的，需要被重构的？

首先，是接入云原生基础设施后，一些能力出现了重复，像服务定义、服务注册、甚至是服务治理能力在不同层面基础设施中出现了重复，需要 Dubbo3 作出适配与调整，以更好的解放业务开发效率，利用好这些基础能力。

其次，是 Dubbo 在微服务架构中的最基本的能力：RPC 远程通信。通信协议和数据传输格式的标准化应该算是 Dubbo2 面临的又一重要挑战，在云原生背影下，协议、数据定义、传输格式的标准化和穿透能力成为更需要优先考虑的指标，纵然私有协议具有更高效、灵活的潜力，但考虑到云原生下多语言、组件间互通、网关等代理设备友好性、避免厂商锁定等诉求，在 Dubbo3 中私有协议都应该被摒弃，转而拥抱基于 HTTP/2 的更通用的协议，采用跨语言的更通用的数据定义和传输格式。

最后，是关于服务治理能力，Dubbo 的服务治理能力应该充分结合底层基础设施的特点，比如之前绑定 ip 的流量过滤方案在地址不固定的 Kubernetes 平台就已不再适用，另外，流量治理也要充分的与调度平台的灰度发布、动态扩缩容能力整合起来；考虑到未来微服务可能会有多种不同的部署形态（下文会讲到），Dubbo3 应该制定一种能适用于各种部署形态的路由规则。

从云原生视角来说，Dubbo3 的核心能力基本上也就成围绕以上几点分析展开的，主要涉及：抽象全新的服务发现模型、定义下一代的更能用的 RPC 协议与数据传输格式、服务治理能力重构等。接下来，我们就看看 3.0 preview 中这些能力的具体实现。

Preview 版本功能速览

就在今天，Dubbo 3.0.0.preview 版本正式通过了 Apache 社区投票并完成了正式发布，作为 3.0 的首个发布版本，代表了社区 3.0 版本的全面启动，也展示了未来 3.0 的发展方向。当然，我们要意识到 preview 版本还远未达到生产可用，它只是为了让大家快速、方便了解 Dubbo3 的一个预览版本，离正式版本甚至 alpha 版本还有一段时间要走，具体大家可关注文后的 Dubbo Roadmap。

以下 preview 版本发布的几个核心特性：

全新的服务发现模型
下一代基于 HTTP/2 的 RPC 协议：Triple
服务治理重构：全新路由规则
性能提升
- 百万节点级水平扩容
- 调用链路 QPS 性能提升

在 preview 以上能力中，特别值得注意的是得益于 Dubbo3 与 HSF 的融合，Dubbo3 的整体性能也有望得到大幅提升。

Preview 版本是从架构层面对 Dubbo 的一次全面升级，接下来，社区一方面会从功能完善度、稳定性等几个方面继续增强 3.0 版本，并将在 6 月份发布首个稳定版本，另一方面社区将兑现更多新的功能。首先，接下来即将交付的是 Kubernetes Service 集成，而 Proxyless Mesh、基于反压的智能流量调度等功能正在前期的调研或开发阶段。

下面，我们就选取以上三个核心功能，深入了解它们的实现机制。

1. 全新服务发现模型

下图是 Dubbo2 的服务发现模型：Provider 注册服务地址，Consumer 经过注册中心协调并发现服务地址，进而对地址发起通信，这是被绝大多数微服务框架的经典服务发现流程。而 Dubbo2 的特殊之处在于，它把 “RPC 接口”的信息也融合在了地址发现过程中，而这部分信息往往是和具体的业务定义密切相关的。

而在接入云原生基础设施后，基础设施融入了微服务概念的抽象，容器化微服务被编排、调度的过程即完成了在基础设施层面的注册。如下图所示，基础设施即承担了注册中心的职责，又完成了服务注册的动作，而 “RPC 接口”这部分信息，由于与具体的业务相关，不可能也不适合被基础设施托管。

在这样的场景下，对 Dubbo3 的服务注册发现机制提出了两个要求：

Dubbo3 需要在原有服务发现流程中抽象出通用的、与业务逻辑无关的地址映射模型，并确保这部分模型足够合理，以支持将地址的注册行为和存储委托给下层基础设施；
Dubbo3 特有的业务接口同步机制，是 Dubbo3 需要保留的优势，需要在 1 中定义的新地址模型之上，通过框架内的自有机制予以解决。

这样设计的全新的服务发现模型，在架构兼容性、可伸缩性上都给 Dubbo3 带来了更大的优势。

在架构兼容性上，如上文所述，Dubbo3 复用下层基础设施的服务抽象能力成为了可能；另一方面，如 Spring Cloud 等业界其它微服务解决方案也沿用这种模型，在打通了地址发现之后，使得用户探索用 Dubbo 连接异构的微服务体系成为了一种可能。

Dubbo3 服务发现模型更适合构建可伸缩的服务体系，这点要如何理解？这里先举个简单的例子，来直观的对比 Dubbo2 与 Dubbo3 在地址发现流程上的数据流量变化：假设一个微服务应用定义了 100 个接口（Dubbo 中的服务），则需要往注册中心中注册 100 个服务，如果这个应用被部署在了 100 台机器上，那这 100 个服务总共会产生 100 100 = 10000 个虚拟节点；而同样的应用，对于 Dubbo3 来说，新的注册发现模型只需要 1 个服务（只和应用有关和接口无关），只注册和机器实例数相等的 1 100 = 100 个虚拟节点到注册中心。在这个简单的示例中，Dubbo 所注册的地址数量下降到了原来的 1 / 100，对于注册中心、订阅方的存储压力都是一个极大的释放。更重要的是，地址发现容量彻底与业务 RPC 定义解藕开来，整个集群的容量评估对运维来说将变得更加透明：部署多少台机器就会有多大负载，不会像 Dubbo2 一样，因为业务 RPC 重构就会影响到整个集群服务发现的稳定性。

2. 下一代通信协议：Triple

我们将 Dubbo3 的新协议命名为 Triple，有代表第 3 代协议的意思。在云原生背景下，Triple 协议需要解决两大问题：

通信协议和数据传输格式的标准化问题。这涉及到 RPC 协议、数据定义、数据传输等环节，未来可移植性、不被厂商锁定会成为每个上云企业用户的诉求，组件内的私有协议和特有数据格式，必然会成为很多用户选型的顾虑。
穿透性、通用性问题。在 Mesh 等架构设想下，微服务甚至所有组件的通信都要经过 sidecar 代理转发，理论上，Sidecar 是要透明的转发流量的（收到什么就转发什么），起码 payload 不应该是 Sidecar 关注的；而 Sidecar 在某些时候也需要感知流量内容的，因为它要基于些做流量的调度，这个时候，Triple 就要做到足够通用 -- 让所有的 Sidecar 都能在预期的地方取到其关注的元数据，而不用解析整个 payload。

除了以上两个核心问题，Triple 协议还需要被设计用来支持更多的业务语义。

协议应该提供更完善的请求模型，除了 Request/Response 模型，还应该支持 Streaming 和 Bidirectional。
在性能上，新的协议应该保留 request Id 机制，以避免 HOL 带来的性能损耗。
新协议应该易于扩展，包括但不限于 Tracing、Monitoring、BackPressure 等支持。

基于以上需求，Triple 协议是完全基于 HTTP/2 之上构建的，另外，Triple 协议将会做到完全兼容 gRPC 协议；在服务定义、数据格式定义以及传输格式上，Triple 将更增加对 Protobuf 的支持。

3. 统一的路由规则

Dubbo3 会对服务治理规则进行全面的重构，以更好的适应云原生基础设施的变革。

当前的 3.0 preview 版本提供了一个重构后的路由规则机制原型，虽然当前版本的实现还需要继续增强，但从设计理念上，我们可以解读出：Dubbo3 期望提供一种跨平台、跨语言、跨多种部署架构的通用路由规则。

随着微服务对治理需求的挖掘，Dubbo2 路由规则除了在语义表达上不能涵盖所有场景之外，更为重要的是，其基于特定语言、特定主机 ip 的过滤机制，已不再适应底层调度平台的工作机制，Dubbo3 需要引入一种全新设计的路由规则。而对于“跨多种部署架构” 这个点，我们设想未来以 Dubbo 构建的微服务会有三种部署架构：传统 SDK、基于 Sidecar 的 Service Mesh以及脱离 Sidecar 的 Service Mesh，这三种部署形态都将由 Dubbo3 统一的路由规则进行治理。

基于 Sidecar 的 Service Mesh，经典的 Mesh 架构，独立的 sidecar 运行时接管所有的流量。
脱离 Sidecar 的 Service Mesh，变种 Mesh 架构，没有 sidecar 运行时，富 SDK 直接通过 xDS 与控制面通信，我们将在后续发布关于 Proxyless 模式更详细的解读。

实践中的 Dubbo3

云原生微服务变革在各大厂商内部早已展开，相比于当前开源社区的 preview 版本，Dubbo3 在阿里巴巴的开发与实践已经在逐步铺开：部分功能已经在阿里巴巴的部分业务线上得到了规模化验证（考拉），并且更多的功能和业务线也将进入试点、推广阶段（饿了么、钉钉等）。有一点是值得特别提及的是：在接下来阿里巴巴的微服务架构升级战略中，Dubbo3 将成为阿里巴巴经济体未来唯一的标准服务框架，它将逐步在所有业务线取代 HSF 和 Dubbo2，并且我们期待在接下来的 1-2 年 Dubbo3 内能覆盖大多数重要的业务线。

说在这里，有必要提一下阿里巴巴的微服务框架演进历程。大概在 2011 年，阿里巴巴开源了 Dubbo2 这一款服务框架并获得极大成功，在 Dubbo2 开源不久，在阿里巴巴内部又发展出了一款全新的服务框架 -- HSF，两者在设计理念上是高度相似的，而经过这么些年的发展，HSF 得以跟随阿里巴巴的业务系统更快速的成长，由其是在大集群、大流量治理下展现出了更好的性能和稳定性。在阿里云原生微服务战略下，整合各个优秀的框架并发展统一品牌的 Dubbo3 被纳入发展规划，在此背景下，Dubbo3 实现了Dubbo2 与 HSF 的融合，并将推动实现内、外技术栈的统一。

除了阿里之外，工商银行等标杆用户也已启动了对 Dubbo3 项目的试点。从社区角度来说，preview 预览版本的发布只是开始，未来随着阿里巴巴、工商银行等更多标杆用户的全面落地，将推动项目更快、更高质量的发展，助力项目保持持续的创新能力和社区生命力。