Apache Dubbo 3.0.0 正式发布 - 全面拥抱云原生

简介：一个新的里程碑！

1、背景

自从 Apache Dubbo 在 2011 年开源以来，在一众大规模互联网、IT公司的实践中积累了大量经验后，Dubbo 凭借对 Java 用户友好、功能丰富、治理能力强等优势在过去取得了很大的成功，成为国内外热门主流的 RPC 框架之一。

但随着云原生时代的到来，以 Apache Dubbo、Spring Cloud 等为表明的 Java 微服务治理体系面临了许多新的需求，包括指望应用能够更快的启动、应用通讯的协议穿透性能够更高、可以对多语言的支持更加友好等。例如Spring 也在今年推出了其基于 GraalVM 的 Spring Native Beta 解决方案，拥有毫秒级启动的能力、更高的处理性能等优化提高。

这样的背景对下一代 Apache Dubbo 提出了两大要求：一是要保留已有的开箱即用和落地实践背景下积累的优势，这也是众多开发者所指望的；二是尽量地遵循云原生思想，能更好的复用底层云原生基础设施而且更贴合云原生的微服务架构。

2、拥抱云原生

在现在的大背景下，Apache Dubbo 3 选择全面拥抱云原生，将 Dubbo 的架构升级，提出了全新的服务发现模型、下一代 RPC 协议和云原生基础设施适配等优化方案。

一、全新服务发现模型（应用级服务发现）

应用级注册模型

以 Dubbo 原有的设计，存储在注册中心中的数据会在很大程度上存在重复的内容，这其实浪费了一部分的存储。而当整个集群的规模足够大的时候，因为服务注册发现是服务维度的，注册中心的数据量就会爆发式地增加。

当前一样是微服务治理工具的 Spring Cloud 和 gRPC 都是基于应用级的服务发现，若是仍使用接口级别的注册方式，Dubbo 就很难和他们进行互通。但假如 Dubbo 也能够像 Spring Cloud 同样以服务级注册，那么在异构体系下将能够很轻松地工做起来。

异构下部署方案

应用级服务发现机制是 Apache Dubbo 面向云原生走出的重要一步，它帮 Apache Dubbo 打通了与其余微服务体系之间在地址发现层面的鸿沟，也成为 Apache Dubbo 适配 Kubernetes Native Service 等基础设施的基础。

基于应用级服务发现，注册中心的数据将被从新组织，注册中心的压力大大减轻。同时，因为地址量减小了，应用自身的内存消耗也能够大幅下降。

性能提高

在通常状况下，应用中存储的地址量能够下降约一半，针对上游应用大规模部署的场景（好比部署了 1000 个节点、提供了 50 个服务）甚至能够达到 95% 以上，这对于核心应用的内存压力环境带来的优化是巨大的。

二、下一代 RPC 协议 —— Triple

在云原生时代，Dubbo RPC 协议主要面临两个挑战：

一、生态不互通，Dubbo 协议基于二进制流定制了与 RPC 强绑定的核心语义，包括协议头、标志位、请求 ID 以及请求/响应数据等。而对于愈来愈多的云原生治理设施，要让他们都 “读” 懂 Dubbo 的二进制 “语义” 并不容易。

二、因为协议设计的问题，Dubbo 协议的协议头已没法再承载更多的元数据信息。而对于 Mesh 等网关型组件，若是想要对数据进行治理就须要对完整的数据包进行解析才能获取到必要的元数据信息（如 RPC 上下文），从性能到易用性方面都会面临挑战。

Dubbo 协议通讯方式

在支持已有的功能和解决存在的问题的前提下，Apache Dubbo 3 提出了下一代 RPC 协议——Triple。

基于 Tripe 协议，咱们指望能够解决这些问题：

一、跨语言互通的问题。传统的多语言多 SDK 模式和 Mesh 化跨语言模式都须要一种更通用易扩展的数据传输格式；

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

请求模型示意图

三、易扩展、穿透性高。包括但不限于 Tracing / Monitoring 等支持，也应该能被各层设备识别，网关设施等能够识别数据报文，对 Service Mesh 部署友好，下降用户理解难度；

四、支持 Java 用户无感知升级。不须要定义繁琐的 IDL 文件，仅须要简单的修改协议名即可以轻松升级到 Triple 协议。

基于这些指望，咱们以为 HTTP/2 做为底层通讯协议，使用 protobuf 做为序列化协议的组合是最合理的，这套组合方案也是 gRPC 协议使用的方案。因此对于 Triple 协议来讲，咱们能够基于 gRPC 协议进行演变，以知足 Apache Dubbo 已有的优秀特性，这同时也保证了在生态系统上新协议和 gRPC 是可以互通和共享的。

Triple 协议通讯方式

三、云原生设施接入

针对于 Kubernetes 的场景， Apache Dubbo 3 为此作了两方面的接入：

一是原生支持与 Kubernetes Pod 生命周期对齐，基于 Dubbo QoS 机制，Kubernetes 可以感知到运行在 Pod 容器中的 Dubbo 应用当前是什么状态，并且得益于 Dubbo SPI 机制用户能够自定义探针检测的维度，实现框架和业务的生命周期都达到统一。

第二是 Dubbo 也将支持接入 Kubernetes Native Service 体系，原生支持基于 Kubernetes API Server 和 DNS 的服务发现体系，实现部署架构下的服务概念与 Dubbo 中的服务概念进行对齐。

Kubernetes 架构下部署方案

而对于 Service Mesh 体系，若是应用使用 Apache Dubbo 2 想要部署以 Mesh 方式部署，须要使用 Sidecar 对 Dubbo 流量进行拦截，而同时因为 Dubbo 自己是具备必定的治理能力的，从应用来讲会多作了不少无用的事情，从集群的角度来讲会形成调用的紊乱。

基于此，Apache Dubbo 3 提出了两种部署模式，一种是配合 Sidecar 部署的 Thin SDK 模式、另外一种是直接接入控制面的 Proxyless Mesh 模式。

Dubbo 3 在 Mesh 场景下部署架构

除了部署架构的接入，在 Apache Dubbo 3 中还定义了一套面向云原生流量治理，支持传统 SDK、Mesh 场景的统一治理规则。

Apache Dubbo 3 指望使用这一套规则，即可以实现如金丝雀发布、A/B测试等丰富的路由语义，只须要配置一套规则，写入统一的控制面，就能够统一地控制全部集群。这样不管使用 Kubernetes 直接部署、亦或者是 Mesh 场景下使用 Thin SDK 或 Proxyless 混合部署甚至是用户直接手动部署集群都可以被同一套规则所控制，实现定义一次，处处使用的目标。

3、将来展望

Apache Dubbo 3.0.0 是捐给 Apache 后的一个里程碑版本，表明着 Apache Dubbo 全面拥抱云原生的一个重要节点。

在 2021 年 11 月咱们会发布 Apache Dubbo 3.1 版本，届时咱们会带来 Apache Dubbo 在 Mesh 场景下部署的实现与实践。

在 2022 年 3 月咱们会发布 Apache Dubbo 3.2 版本，在这个版本中咱们将带来全新的大规模应用部署下智能流量调度机制，提升系统稳定性与资源利用率。

Apache Dubbo 3 目前已经和阿里巴巴集团内部的 RPC 框架实现了融合，指望用它来解决内部落地问题，作到技术栈统一。将来，Apache Dubbo 3 将大规模落地阿里集团，承载 61八、双十一等复杂业务场景。

社区衷心地但愿欢迎你们向社区提交 issue 和 PR，社区的同窗会尽快进行 review 和回复。另外，社区会尽量保证一个较短的发版周期，及时对已有的问题进行修复。

同时在 Apache Dubbo 3 开始，社区也会采用更开放的态度对待生产环境下的定制需求，咱们欢迎你们将本身的定制化实现贡献给开源社区，dubbo-spi-extensions 仓库将来会对这些定制化进行支持。

本文内容由阿里云实名注册用户自发贡献，版权归原做者全部，阿里云开发者社区不拥有其著做权，亦不承担相应法律责任。具体规则请查看《阿里云开发者社区用户服务协议》和《阿里云开发者社区知识产权保护指引》。若是您发现本社区中有涉嫌抄袭的内容，填写侵权投诉表单进行举报，一经查实，本社区将马上删除涉嫌侵权内容。