导读：Apache Dubbo 是一款开源的 RPC 框架，其提供了简单易用、高性能的 RPC 能力、灵活可控的扩展、强大的服务治理，目前已有 Java、Go、JS、Python 等多个语言支持；并且已经悄然衍进为 Cloud Native 基础设施。这一切成就都离不开 Dubbo 社区的建设，本文将由 Apache Dubbo PMC 刘军来介绍 Dubbo 社区在过去的一年取得的成绩及未来 Dubbo 社区的发展新规划。

非常感谢大家对 Dubbo 社区的关注，通过这篇文章我们将：

• 总结过去一年 Dubbo 社区取得的成绩，包括社区和框架演进两个方面；
• 展望未来 Dubbo 社区和框架的新的规划（roadmap）。

社区建设是推动 Dubbo 健康持续发展的一个非常重要的环节，我们需要与社区保持良性的互动、有活跃的贡献者、有积极的富有建设性的讨论，而整个 Dubbo 社区过去一年在这方面都做的不错；在框架演进上，我们主要发布了 2.7.0 - 2.7.5 共 6 个特性版本，功能层面涵盖编程模型、协议、服务治理、性能优化等多个方面；除了已经发布的功能外，我们在 Dubbo 3.0 协议、服务自省和云原生等方向上也做了深入的探索，对这些方向的支持将是 Dubbo 接下来的重要工作方向，希望能通过这篇文章将其中更详细的思考和计划同步给大家。

社区回顾

回顾 Dubbo 社区过去一年的发展，其中一个重要的节点就是 2019 年 5 月从 Apache 孵化毕业，成为第二个由 Alibaba 捐献后从 Apache 毕业的项目，我有幸参与到了从重启开源、进入 Apache 孵化到毕业的整个过程。社区在此过程中做了大量的工作，包括邮件列表建设、代码规范检查、文档和代码国际化、issue/pr 处理等，这些一方面是 Apache 社区要求的工作，同时也为推动 Dubbo 的发展起到了正面的作用。

在从 Apache 毕业之后，Dubbo 相关的项目也进行了迁移，都迁移到了 github.com/apache 组织之下。

Dubbo 社区的项目总共有 24 个之多，维护如此多的项目，并不是单纯靠几个活跃的开发者就能做到的，而是靠整个社区共同努力的结果。我总结了过去一年提名的所有 Committer/PMC，共有 27 人获得提名（23 名 committer、4 名 PMC）。

通过下方的饼状图可以看出，只有不到 20% 的贡献者是来自于 Alibaba，80% 以上是来自各个不同组织的开发者或爱好者。这样的 Committer 分布，是加入 Apache 带给 Dubbo 社区的一个最重要的变化之一：Dubbo 项目是属于整个社区的，反映的是不同组织不同开发者的共同诉求，它的发展不是由一个公司控制或决定的，而是由社区共同讨论后决定的。如果你对参与到 Dubbo 社区感兴趣，都可以参与到 Dubbo 发展的讨论、决策和 coding 中来，也非常期待各位能成为下一个 Committer。

过去一年 Dubbo 社区组织了超过 10 场的线下 meetup 活动，基本覆盖了国内所有开发者聚集的城市，与广大 Dubbo 开发者和使用者保持了密切交流。通过这些线下、线上的直播活动，分享了超过 100 个 topic 的演讲，深度讲解了 Dubbo 社区的最新动态、功能模块开发和近期规划等。在所有的主题演讲中，绝大多数都是通过社区采集的方式，最终由 Dubbo 的深度企业分享的实践主题，其中典型的代表包括携程、工商银行、考拉、信用算力等。

从 Github 上来看，Dubbo 在过去一年也受到了非常高的关注度，一个重要的里程碑是 Star 数突破 3w，相比重启开源时增长了近 5 倍；贡献者由最初的几十个增长到现在的 282 个，而这其中有六七十个已经被提名为 committer，不论是贡献者数量还是 committer 比例都得到很大的提升；另一个数据是发布的版本，总共发布了 64 个版本，大家如果要了解每个版本的具体信息，也可以从这里点进去查看。

当前社区维护的大版本主要有 3 个，分别是 2.5.x、2.6.x 和 2.7.x。

• 其中 2.7.x 是我们的主要开发版本，在过去的一年共发布了 6 个版本（2.7.0 - 2.7.5），每个版本都带来了一些值得关注的特性或功能升级，涵盖从编程模型、服务治理、性能到协议的多个方面的增强；
• 2.6.x 版本定位为 bugfix 版本，过去一年共发布了 3 个版本，主要以修复问题和安全漏洞为主，并没有增加什么新 feature，因此这一系列的版本在稳定性上是得到保证的；
• 2.5.x 版本从去年初开始已宣布 EOF，只做安全修复；而到了下半年已经完全停止了维护。还在使用这个版本的用户建议尽快升级到 2.6 或 2.7 版本。

关于 2.6 和 2.7 版本的用户分布情况，目前并没有官方的统计数据，但是根据我们从 issue 分布及一些深度用户的跟踪情况来看，这两个版本的使用分布大概是 40% - 60% 的状态。同时我们还观察到一个趋势，即很大一部分 2.6 的用户都已经开始调研升级到 2.7 版本或在升级的过程中，毕竟一个框架是否能很好的满足业务开发诉求，一个重要的因素是其是否不断的有功能加入、是否能跟进新的技术趋势，2.6 版本已很难满足这些诉求。

对于很多开发者来说，要升级到 2.7 版本，当前最大的顾虑是其稳定性。因为 2.7 的每个版本都会增加很多新内容且迭代速度较快，要保证每个发布版本的稳定性对社区来说也是一个充满挑战的事情。为了方便用户更好的完成升级评估，我们近期在 github 上单独列了一个 issue 来统计现在包括未来版本的稳定性：

	版本	重要功能	升级建议
1	2.7.5	服务自省 HTTP/2（gRPC） Protobuf TLS 性能优化	不建议大规模生产使用
2	2.7.4.1	bugfixes and enhancements of 2.7.3	推荐生产使用
3	2.7.3	bigfixes of and enhancements of 2.7.2	推荐生产使用
4	2.7.2	bigfixes of and enhancements of 2.7.1	不建议大规模生产使用
5	2.7.1	bigfixes of and enhancements of 2.7.0	不建议大规模生产使用
6	2.7.0	异步编程模型 - 消费端/提供端异步 服务治理规则增强 简化的注册模型 配置中心、元数据中心 package 重构	beta 版本，2.6.x 重构后首个版本

其中 2.7.5 版本预计将在接下来的 1-2 个版本之后逐步达到稳定状态。

对于接下来的版本是否通过标识性的后缀如 -beta、RC 等来区分不同阶段的发布版本，社区也有过类似的讨论，后续我们将视未来发展情况而定。

重点功能回顾

接下来针对 2.7 版本中发布的新功能，从编程模型、性能优化、服务治理、传输协议、生态发展等几个角度来做具体的讲解。

编程模型

Dubbo 中涉及编程模型相关的改动主要是以下几点：

• CompletableFuture 异步方法签名的服务
• 服务端异步支持 API
• IDL 跨语言服务定义
• Reactive-style 方法签名的服务

首先，我们先来看一下异步化相关的增强。

Dubbo Java 版本的典型服务定义如下：

public interface HelloService {
  // Synchronous style
  String sayHello(String name); 
}

如果要实现消费端的异步服务调用，则需要单独配置异步标识，并通过 RpcContext API 配合使用：

String result = helloService.sayHello("world"); // result is always null
Future future = RpcContext.getContext().getFuture();

在 2.7 版本之后，我们可以直接定义如下方法接口，以更直观的实现消费端/提供端异步：

public interface HelloService {
  // Asynchronous style
  CompletableFuture<String> sayHello(String name); 
}

CompletableFuture<String> future = helloService.sayHello("world");

以上示例都是基于 Java Interface 来描述 Dubbo 服务的，如果要和多语言异构的微服务实现互调，则服务又需要用相应语言的方式重新定义一遍，无法实现跨语言的服务复用；另外跨语言的序列化也是需要注意的一个问题。

为此 2.7.5 版本引入了对 IDL + Protobuf 的支持，以解决跨语言的服务定义问题，具体可参见示例。

对 Reactive-style API 的支持则和上面 CompletableFuture 有些类似，允许用户定义 RxJava、Reactor API 的服务接口。

但是需要注意的一点是，由于外围的 Reactive API 需要有底层传输协议的支持才有意义，因此，目前 Reactive API 只能在使用 gRPC 协议时才有意义，具体请参见示例及下文。

性能优化

2.7 版本在性能优化方面也做了很多的工作，对 Dubbo 业务系统的吞吐量、调用链路响应速度、服务治理链路性能等都有明显提升。

1. 系统吞吐量

和提升系统吞吐量相关的增强主要有框架的全异步化改造、消费端线程模型优化、引入 Stream 语义协议等。

全异步化改造，很关键的一点是 Filter 链路的异步化，之前的 Filter 只有一个同步的 invoke 方法，现在为了支持异步回调，增加了 Listener 回调监听器，从而可以实现对异步调用结果的监听与拦截。

关于消费端线程模型的优化，对于网关类应用，需要消费大量服务的应用，都会在系统稳定性和性能表现上有很大提升，其优化后的总体工作原理图如下所示，具体解析可以参见之前发布的文章：《里程碑式 Dubbo 2.7.5 版本发布，性能提升30%，支持 HTTP/2、TLS、Protobuf 等特性》。

老线程模型工作原理：

新线程模型工作原理：

2. RPC 调用链路

从 2.7.0 到 2.7.5，以我们的测试数据来看，通过一系列的优化，调用链路性能提升在 30% 以上。总体来说，优化的目标是减少调用过程中的内存分配和 cpu 计算，主要有两个方面的改造：

• 服务元数据静态化，在启动阶段尽可能多的计算并缓存，以减少调用过程中的计算成本，加快响应速度；
• 减少调用过程中的 URL 操作产生的内存分配。

3. 服务治理链路

服务治理链路上主要有以下几点值得关注：地址推送、服务治理规则推送、服务治理规则计算、路由选址等，尤其是在大规模服务集群的场景下，以上每个点都可能成为性能或稳定性瓶颈。在 2.7 版本中，着重对 “地址推送” 相关计算路径做了优化，简单概括起来主要是以下几点：

• 地址推送事件合并，避免短时间重复计算
• 全量地址推送时，避免 URL 重新分配
• 在 URL 合并链路上，引入 URL 可变状态，避免 URL 拷贝造成的开销

服务治理

服务治理也是 2.7 版本中着重增强的一个模块。总体上可以分为三部分：

• 普通路由规则相关的优化和增强
• 增强对跨区域、跨机房部署的路由支持
• 元数据中心、配置中心

我们针对这三部分逐步展开讲解。以下是 2.7 版本路由规则的几个例子。

其中，最明显的一个变化是路由规则都以 YAML 进行了重写，并且后续所有的路由规则都计划以 YAML 为基本描述语言；相比于之前路由规则直接存储于注册中心，在 2.7 版本中增加了配置中心后，新版本的路由规则默认将存储在于独立的配置中心，配置格式推送机制都得到了优化；另外，2.7 版本中还增加了应用粒度的路由规则，方便从整个应用的角度去设置流量规则。

新增加的跨注册中心的路由机制，可以实现调用流量在多个注册中心间的负载均衡，对于需要做异地容灾、同机房优先或者注册中心迁移的场景比较有用处。

当前支持的注册中心集群负载均衡策略有：

• 同区域优先
• 权重轮询
• 指定优先级
• 任意可用

元数据中心存储了 Dubbo 服务方法定义的描述，目前主要的用途是服务测试，将来也可用作服务 API 管理、网关参数映射等。

新增的配置中心主要有两个用途：存储/推送配置规则、应用配置托管，接下来着重讲解应用配置托管相关功能，看其对 Dubbo 的开发与运维配置的影响。Dubbo 当前支持 JVM 动态参数、配置中心、API、本地配置文件等几种配置源，它们之间按照优先级从高到低的顺序实现配置覆盖，如下图所示：

配置中心相当于是共享版本的 dubbo.properties 的远程托管，其中，key 值有特定的命名规范：

# 应⽤用级别
dubbo.{config-type}[.{config-id}].{config-item} {config-item-value}
# 服务级别
dubbo.service.{interface-name}[.{method-name}].{config-item} {config-item-value}
dubbo.reference.{interface-name}[.{method-name}].{config-item} {config-item-value}
# 多配置项
dubbo.{config-type}s.{config-id}.{config-item} {config-item-value}

传输协议

2.7 版本在 RPC 协议层和序列化层进行了扩展，RPC 协议层增加了对 gRPC 协议的支持，序列化层增加了对 Protobuf 协议的支持。

支持 gRPC 的一个重要原因是其基于 HTTP/2 协议构建，HTTP/2 协议作为 HTTP 标准协议，在各个层次的网络设备及网关代理上都得到了很好的支持，因此具有更好的穿透性和通用性。通过支持 gRPC 协议，对于期望使用 HTTP/2 的 Dubbo 用户提供了一种传输协议选择。

gRPC 在 HTTP/2 上构建了 Stream 的 RPC 语义，支持 Request - Response、Stream - Response、Request - Stream、Bi-Stream 等多种语义，能满足不同的业务调用场景。

在 Dubbo 的设计中，所有的 RPC 协议都处于一个平等的地位，无论是自有的 Dubbo 协议，还是扩展的其他三方协议如 Thrift、Hessian、gRPC 等，得益于这样的设计，我们可以扩展任何新协议支持。关于如何扩展 RPC 协议及其应用场景，请参见之前发布的《使用 Dubbo 连接异构微服务体系》一文。

Protobuf 序列化协议支持更多的是考虑其在跨语言、安全性和性能方面。

Roadmap

未来社区将会持续推动 Dubbo 的发展，重点来说有以下几个方向：

• 继续增强服务治理相关能力，以更好的满足微服务开发和运维的需求；
• 协议层面，着手研发下一代的 RPC 协议，新协议将提供更丰富的如 Stream、Flow Control 等内置语义，同时将具有更好的扩展性、网关的友好性等；
• 基于应用粒度的服务发现机制，
• 云原生带来了底层基础设施的变化，同时在此基础上衍生出了如 ServiceMesh 的微服务解决方案，我们需要继续探索 Dubbo ；

微服务功能

目前正在开发或规划中的微服务功能有服务鉴权、熔断、路由规则增强等，预计将在接下来的 2.7.6 等版本中陆续发布。后续也将会根据社区中的诉求，陆续增加其他的微服务功能支持。

以当前正在开发的服务鉴权功能为例，这是社区中很多 Dubbo 使用者在实际使用中遇到的需求：虽然 Dubbo 服务主要是在内部运转，但有些服务仍期望只对部分场景或用户开放，比如某些涉及到敏感数据操作的服务，这就需要有鉴权能力的支持。

该 issue 中有关于 Dubbo 当前正在开发中的鉴权功能的详细讨论，总体来说 Dubbo 提供的鉴权功能约束了 Dubbo 侧鉴权的基本流程，这是一套通用鉴权的方案，在 token 计算、校验等环节都被设计为可扩展的，因此可以方便的对接到各种认证及权限管理系统。

非常感谢社区的活跃开发者，现就职于爱奇艺的 https://github.com/CodingSinger，其是鉴权模块的发起者和主要开发贡献者。

协议 - 3.0

以下是 Dubbo 2.0 协议，我们之前已经在多个场合做过详细的讲解。

Dubbo 2.0 协议在云原生、mesh 等场景下暴露出一些问题，如：

• 协议缺少扩展性
• RPC 协议层和 payload 耦合在一起
• 基于 TCP 构建的二进制私有协议
• 缺少 Stream 语义的支持

所以，针对以上问题，新一代的 Dubbo 协议将突出以下特点：

• Reactive Stream

Reactive Stream 引入 RPC，带来更丰富的通信语义和 API 编程模型支持，如 Request-Stream、Bi-Stream 等。

• 协议升级

协议内置应⽤层协议协商机制，包括自建协议升级机制、ALPN 等，以方便将来协议升级或兼容老版本协议的迁移。

• HTTP/2

微服务云原⽣场景下，基于 HTTP/2 构建的通信协议具有更好的通用性和穿透性。

• 可扩展

协议可扩展，区分协议头 Metadata 与 RPC 方法的参数。

• 多语⾔支持

如通过支持 Protobuf 提供了更完善的跨语言服务定义与序列化传输的支持。

• Mesh

协议对 Mesh 更友好，方便完成与 Mesh 的协作，包括流量控制机制、应用层配置协商等。

• 流量控制

协议内置流控机制，支持类似 Reqctive Stream 的 Request (n)  流控机制。

• 协议通用性

兼顾通用性与性能，支持协议能在各种设备上运行。

服务自省 - 应用粒度的服务注册

Dubbo 最大的优势之一在于其易用性及面向接口（RPC 方法）的编程模型。同时，面向接口的治理也带来了一些问题：

• 地址数量成倍增长，给地址推送带来很大压力
• 和主流微服务体系模型不匹配，如 SpringCloud、Kubernetes 等

为此，我们计划引入应用粒度的服务注册机制，主要有以下几个重点：

• 注册中心按 “应用 - 实例IP” 组织，不再关心 RPC 接口同步
• 引入独立的元数据服务完成 RPC 接口同步工作

以下是应用粒度服务注册（服务自省）的基本工作原理，请持续关注后续对这部分的具体解析和开发进展。

云原生

云原生带来了底层基础设施，应用开发、部署和运维等全方位的变化。

基础设施

• 基础设施调度机制变化，带来运维（生命周期）、服务治理等方面的变化；
• 服务发现能力下沉， Kubernetes 抽象了 Native Service Discovery。

Service Mesh - 云原生微服务解决方案

• Mesh 为跨语言、sdk 升级等提供了解决方案，Dubbo sdk 要与 Mesh 协作，做到功能、协议、服务治理等多方便的适配；
• Mesh 尚未大规模铺开，且其更适合对流量管控更关注的应用，传统 SDK 的性能优势仍旧存在，两者混部迁移场景可能会长期存在。

从应用场景上，Dubbo 可能的部署环境包括：

1. 不使用 Kubernetes Native Service，Kubernetes 只作为容器编排调度设施，继续使用 Dubbo  自建的服务注册、发现机制；
2. 复用 Kubernetes Native Service，Dubbo 不再关心服务注册，Dubbo Client 负责服务发现与流量分配；
3. Dubbo sdk 往 Mesh 迁移，一方面要做到适应 Mesh 架构，成为 Mesh 体系下的 RPC 编程和通信方案；另一方面要做到 Dubbo 与 Mesh 架构长期共存，互相打通服务发现和治理体系；
4. Kubernetes 上与云下混合部署的平滑迁移支持，包括服务发现的统一与网络通信方案的打通。

从 Dubbo 功能划分上，将着重从以下方面提供对云原生基础设施的支持：

• 生命周期： Dubbo 与 Kubernetes 调度机制绑定，保持服务生命周期与 Pod 容器等生命周期的自动对齐；
• 治理规则： 服务治理规则在规则体、规则格式方面进行优化，如规则体以 YAML 描述、取消过滤规则对 IP 的直接依赖，定义规则特有的 CRD 资源等；
• 服务发现： 支持 K8S Native Service 的服务发现，包括 DNS、API-Server，支持 xDS 的服务发现；
• Mesh 架构协作： 构建下一代的基于 HTTP/2 的通信协议，支持 xDS 的标准化的数据下发。