透过 3.0 Preview 看 Dubbo 的云原生变革

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

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

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

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

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

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

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

• 更多的微服务组件及能力正下沉到以 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 版本发布的几个核心特性：

• 全新的服务发现模型

• 下一代基于 HTTP/2 的 RPC 协议：Triple

• 服务治理重构：全新路由规则

• 性能提升

• 百万节点级水平扩容

• 调用链路 QPS 性能提升

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

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

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

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

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

1. Dubbo3 需要在原有服务发现流程中抽象出通用的、与业务逻辑无关的地址映射模型，并确保这部分模型足够合理，以支持将地址的注册行为和存储委托给下层基础设施；

2. Dubbo3 特有的业务接口同步机制，是 Dubbo3 需要保留的优势，需要在 1 中定义的新地址模型之上，通过框架内的自有机制予以解决。

• 通信协议和数据传输格式的标准化问题。这涉及到 RPC 协议、数据定义、数据传输等环节，未来可移植性、不被厂商锁定会成为每个上云企业用户的诉求，组件内的私有协议和特有数据格式，必然会成为很多用户选型的顾虑。

• 穿透性、通用性问题。在 Mesh 等架构设想下，微服务甚至所有组件的通信都要经过 sidecar 代理转发，理论上，Sidecar 是要透明的转发流量的（收到什么就转发什么），起码 payload 不应该是 Sidecar 关注的；而 Sidecar 在某些时候也需要感知流量内容的，因为它要基于些做流量的调度，这个时候，Triple 就要做到足够通用 -- 让所有的 Sidecar 都能在预期的地方取到其关注的元数据，而不用解析整个 payload。

• 协议应该提供更完善的请求模型，除了 Request/Response 模型，还应该支持 Streaming 和 Bidirectional。

• 在性能上，新的协议应该保留 request Id 机制，以避免 HOL 带来的性能损耗。

• 新协议应该易于扩展，包括但不限于 Tracing、Monitoring、BackPressure 等支持。

• 基于 Sidecar 的 Service Mesh，经典的 Mesh 架构，独立的 sidecar 运行时接管所有的流量。

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

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

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

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

本文开篇关于云原生微服务变革部分思想引自阿里云高级技术专家、CNCF TOC 张磊 《Microservices - A Cloud Native View》一文分享。