回望 Apache Dubbo 這一年走過的路

導讀：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 服務主要是在内部運轉，但有些服務仍期望隻對部分場景或使用者開放，比如某些涉及到敏感資料操作的服務，這就需要有鑒權能力的支援。

該

中有關于 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 的标準化的資料下發。