作者 | 劉軍（陸龜）Apache Dubbo PMC

本文整理自架構師成長系列 2 月 18 日直播課程。

關注“阿里巴巴雲原生”公眾號，回覆 **“218”**，即可獲取對應直播回放連結及 PPT 下載連結。

> **導讀**：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 相關的專案也進行了[遷移](https://github.com/apache?utf8=✓&q=dubbo&type=&language=)，都遷移到了 github.com/apache 組織之下。

Dubbo 社群的專案總共有 24 個之多，維護如此多的專案，並不是單純靠幾個活躍的開發者就能做到的，而是靠整個社群共同努力的結果。我總結了過去一年提名的所有 Committer/PMC，共有 27 人獲得提名（23 名 committer、4 名 PMC）。

透過下方的餅狀圖可以看出，只有不到 20% 的貢獻者是來自於 Alibaba，80% 以上是來自各個不同組織的開發者或愛好者。這樣的 Committer 分佈，是加入 Apache 帶給 Dubbo 社群的一個最重要的變化之一：Dubbo 專案是屬於整個社群的，反映的是不同組織不同開發者的共同訴求，它的發展不是由一個公司控制或決定的，而是由社群共同討論後決定的。如果你對參與到 Dubbo 社群感興趣，都可以參與到 Dubbo 發展的討論、決策和 coding 中來，也非常期待各位能成為下一個 Committer。

![1.png](https://ucc.alicdn.com/pic/developer-ecology/9245b27c36044dcb99aa79e73a769a62.png)

過去一年 Dubbo 社群組織了超過 10 場的線下 [meetup 活動](https://developer.aliyun.com/article/740578)，基本覆蓋了國內所有開發者聚集的城市，與廣大 Dubbo 開發者和使用者保持了密切交流。透過這些線下、線上的直播活動，分享了超過 100 個 topic 的演講，深度講解了 Dubbo 社群的最新動態、功能模組開發和近期規劃等。在所有的主題演講中，絕大多數都是透過社群採集的方式，最終由 Dubbo 的深度企業分享的實踐主題，其中典型的代表包括攜程、工商銀行、考拉、信用算力等。

從 Github 上來看，Dubbo 在過去一年也受到了非常高的關注度，一個重要的里程碑是 Star 數突破 3w，相比重啟開源時增長了近 5 倍；貢獻者由最初的幾十個增長到現在的 282 個，而這其中有六七十個已經被提名為 committer，不論是貢獻者數量還是 committer 比例都得到很大的提升；另一個資料是釋出的版本，總共釋出了 64 個版本，大家如果要了解每個版本的具體資訊，也可以從這裡點進去檢視。

![3.png](https://ucc.alicdn.com/pic/developer-ecology/300232359589495faed64d362ef6bb0b.png)

當前社群維護的大版本主要有 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 ](https://github.com/apache/dubbo/issues/5669)來統計現在包括未來版本的穩定性：

|  | **版本** | **重要功能** | **升級建議** |
| --- | --- | --- | --- |
| 1 | 2.7.5 | [服務自省 HTTP/2（gRPC） Protobuf TLS 效能最佳化](https://github.com/apache/dubbo/releases/tag/dubbo-2.7.5)   | 不建議大規模生產使用 |
| 2 | 2.7.4.1 | [bugfixes and enhancements of 2.7.3](https://github.com/apache/dubbo/releases/tag/dubbo-2.7.4.1) | **推薦生產使用** |
| 3 | 2.7.3 | [bigfixes of and enhancements of 2.7.2](https://github.com/apache/dubbo/releases/tag/dubbo-2.7.3) | **推薦生產使用** |
| 4 | 2.7.2 | [bigfixes of and enhancements of 2.7.1](https://github.com/apache/dubbo/releases/tag/dubbo-2.7.2) | 不建議大規模生產使用 |
| 5 | 2.7.1 | [bigfixes of and enhancements of 2.7.0](https://github.com/apache/dubbo/releases/tag/dubbo-2.7.1) | 不建議大規模生產使用 |
| 6 | 2.7.0 | [非同步程式設計模型 - 消費端/提供端非同步 服務治理規則增強 簡化的註冊模型 配置中心、後設資料中心 package 重構](https://github.com/apache/dubbo/releases/tag/dubbo-2.7.0)   | beta 版本，2.6.x 重構後首個版本 |

其中 2.7.5 版本預計將在接下來的 1-2 個版本之後逐步達到穩定狀態。

對於接下來的版本是否透過標識性的字尾如 -beta、RC 等來區分不同階段的釋出版本，社群也有過類似的討論，後續我們將視未來發展情況而定。

# 重點功能回顧

接下來針對 2.7 版本中釋出的新功能，從程式設計模型、效能最佳化、服務治理、傳輸協議、生態發展等幾個角度來做具體的講解。

## 程式設計模型

Dubbo 中涉及程式設計模型相關的改動主要是以下幾點：

- CompletableFuture 非同步方法簽名的服務
- 服務端非同步支援 API
- IDL 跨語言服務定義
- Reactive-style 方法簽名的服務

首先，我們先來看一下非同步化相關的增強。

Dubbo Java 版本的典型服務定義如下：

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

如果要實現消費端的非同步服務呼叫，則需要單獨配置非同步標識，並透過 RpcContext API 配合使用：

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

在 2.7 版本之後，我們可以直接定義如下方法介面，以更直觀的實現消費端/提供端非同步：

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

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

以上示例都是基於 Java Interface 來描述 Dubbo 服務的，如果要和多語言異構的微服務實現互調，則服務又需要用相應語言的方式重新定義一遍，無法實現跨語言的服務複用；另外跨語言的序列化也是需要注意的一個問題。

為此 2.7.5 版本引入了對 IDL + Protobuf 的支援，以解決跨語言的服務定義問題，具體可參見[示例](https://github.com/apache/dubbo-samples/tree/master/java/dubbo-samples-protobuf)。

![4.png](https://ucc.alicdn.com/pic/developer-ecology/881c9f5bad7d47588c2a29c33970fbbb.png)

對 Reactive-style API 的支援則和上面 CompletableFuture 有些類似，允許使用者定義 RxJava、Reactor API 的服務介面。

![5.png](https://ucc.alicdn.com/pic/developer-ecology/40373b73968940ca9a1c308a3c5dc1fe.png)

但是需要注意的一點是，由於外圍的 Reactive API 需要有底層傳輸協議的支援才有意義，因此，目前 Reactive API 只能在使用 gRPC 協議時才有意義，具體請[參見示例](https://github.com/apache/dubbo-samples/tree/master/java/dubbo-samples-grpc/dubbo-samples-rxjava)及下文。

## 效能最佳化

2.7 版本在效能最佳化方面也做了很多的工作，對 Dubbo 業務系統的吞吐量、呼叫鏈路響應速度、服務治理鏈路效能等都有明顯提升。

### 1. 系統吞吐量
和提升系統吞吐量相關的增強主要有框架的全非同步化改造、消費端執行緒模型最佳化、引入 Stream 語義協議等。

全非同步化改造，很關鍵的一點是 Filter 鏈路的非同步化，之前的 Filter 只有一個同步的 invoke 方法，現在為了支援非同步回撥，增加了 Listener 回撥監聽器，從而可以實現對非同步呼叫結果的監聽與攔截。

![6.png](https://ucc.alicdn.com/pic/developer-ecology/748489fb320e46148b6f48edb389f8cc.png)

關於消費端執行緒模型的最佳化，對於閘道器類應用，需要消費大量服務的應用，都會在系統穩定性和效能表現上有很大提升，其最佳化後的總體工作原理圖如下所示，具體解析可以參見之前釋出的文章：[《里程碑式 Dubbo 2.7.5 版本釋出，效能提升30%，支援 HTTP/2、TLS、Protobuf 等特性》](https://mp.weixin.qq.com/s?__biz=MzAwMDU1MTE1OQ==&mid=2653551746&idx=1&sn=e3609a67e2c2c023ae344ae7604e36b7&scene=21#wechat_redirect)。

老執行緒模型工作原理：

![7.png](https://ucc.alicdn.com/pic/developer-ecology/9d57087a74de473385f481763b4f9b36.png)

新執行緒模型工作原理：

![8.png](https://ucc.alicdn.com/pic/developer-ecology/70c2c1fabd5245aea60b684a9dbc4313.png)

### 2. RPC 呼叫鏈路
從 2.7.0 到 2.7.5，以我們的測試資料來看，透過一系列的最佳化，呼叫鏈路效能提升在 30% 以上。總體來說，最佳化的目標是減少呼叫過程中的記憶體分配和 cpu 計算，主要有兩個方面的改造：

- 服務後設資料靜態化，在啟動階段儘可能多的計算並快取，以減少呼叫過程中的計算成本，加快響應速度；
- 減少呼叫過程中的 URL 操作產生的記憶體分配。

### 3. 服務治理鏈路
服務治理鏈路上主要有以下幾點值得關注：地址推送、服務治理規則推送、服務治理規則計算、路由選址等，尤其是在大規模服務叢集的場景下，以上每個點都可能成為效能或穩定性瓶頸。在 2.7 版本中，著重對 “地址推送” 相關計算路徑做了最佳化，簡單概括起來主要是以下幾點：

- 地址推送事件合併，避免短時間重複計算
- 全量地址推送時，避免 URL 重新分配
- 在 URL 合併鏈路上，引入 URL 可變狀態，避免 URL 複製造成的開銷

## 服務治理

服務治理也是 2.7 版本中著重增強的一個模組。總體上可以分為三部分：

- 普通路由規則相關的最佳化和增強
- 增強對跨區域、跨機房部署的路由支援
- 後設資料中心、配置中心

我們針對這三部分逐步展開講解。以下是 2.7 版本路由規則的幾個例子。

![9.png](https://ucc.alicdn.com/pic/developer-ecology/b4df116346a14943a9d349245be5bf5d.png)

![10.png](https://ucc.alicdn.com/pic/developer-ecology/032ea90f685b4afeb35d5ef420877481.png)

其中，最明顯的一個變化是路由規則都以 YAML 進行了重寫，並且後續所有的路由規則都計劃以 YAML 為基本描述語言；相比於之前路由規則直接儲存於註冊中心，在 2.7 版本中增加了配置中心後，新版本的路由規則預設將儲存在於獨立的配置中心，配置格式推送機制都得到了最佳化；另外，2.7 版本中還增加了應用粒度的路由規則，方便從整個應用的角度去設定流量規則。

新增加的跨註冊中心的路由機制，可以實現呼叫流量在多個註冊中心間的負載均衡，對於需要做異地容災、同機房優先或者註冊中心遷移的場景比較有用處。

![11.png](https://ucc.alicdn.com/pic/developer-ecology/74da4dad6b2844908d35ece2e41b9d16.png)

當前支援的註冊中心叢集負載均衡策略有：

- 同區域優先
- 權重輪詢
- 指定優先順序
- 任意可用

後設資料中心儲存了 Dubbo 服務方法定義的描述，目前主要的用途是服務測試，將來也可用作服務 API 管理、閘道器引數對映等。

新增的配置中心主要有兩個用途：儲存/推送配置規則、應用配置託管，接下來著重講解應用配置託管相關功能，看其對 Dubbo 的開發與運維配置的影響。Dubbo 當前支援 JVM 動態引數、配置中心、API、本地配置檔案等幾種配置源，它們之間按照優先順序從高到低的順序實現配置覆蓋，如下圖所示：

![12.png](https://ucc.alicdn.com/pic/developer-ecology/e3a302726b8b41249afa3c6e13610402.png)

配置中心相當於是共享版本的 `dubbo.properties` 的遠端託管，其中，key 值有特定的命名規範：

```properties
# 應⽤用級別
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 等多種語義，能滿足不同的業務呼叫場景。

![13.png](https://ucc.alicdn.com/pic/developer-ecology/15210ec1d3b5499d8b70b52988030be5.png)

在 Dubbo 的設計中，所有的 RPC 協議都處於一個平等的地位，無論是自有的 Dubbo 協議，還是擴充套件的其他三方協議如 Thrift、Hessian、gRPC 等，得益於這樣的設計，我們可以擴充套件任何新協議支援。關於如何擴充套件 RPC 協議及其應用場景，請參見之前釋出的[《使用 Dubbo 連線異構微服務體系》](https://mp.weixin.qq.com/s/-fvDeGlCLjz0n60naZJnQg)一文。

Protobuf 序列化協議支援更多的是考慮其在跨語言、安全性和效能方面。

# Roadmap

未來社群將會持續推動 Dubbo 的發展，重點來說有以下幾個方向：

- 繼續增強服務治理相關能力，以更好的滿足微服務開發和運維的需求；
- 協議層面，著手研發下一代的 RPC 協議，新協議將提供更豐富的如 Stream、Flow Control 等內建語義，同時將具有更好的擴充套件性、閘道器的友好性等；
- 基於應用粒度的服務發現機制，
- 雲原生帶來了底層基礎設施的變化，同時在此基礎上衍生出瞭如 ServiceMesh 的微服務解決方案，我們需要繼續探索 Dubbo ；

## 微服務功能

目前正在開發或規劃中的微服務功能有服務鑑權、熔斷、路由規則增強等，預計將在接下來的 2.7.6 等版本中陸續釋出。後續也將會根據社群中的訴求，陸續增加其他的微服務功能支援。

以當前正在開發的服務鑑權功能為例，這是社群中很多 Dubbo 使用者在實際使用中遇到的需求：雖然 Dubbo 服務主要是在內部運轉，但有些服務仍期望只對部分場景或使用者開放，比如某些涉及到敏感資料操作的服務，這就需要有鑑權能力的支援。

該[ issue](https://github.com/apache/dubbo/issues/5461) 中有關於 Dubbo 當前正在開發中的鑑權功能的詳細討論，總體來說 Dubbo 提供的鑑權功能約束了 Dubbo 側鑑權的基本流程，這是一套通用鑑權的方案，在 token 計算、校驗等環節都被設計為可擴充套件的，因此可以方便的對接到各種認證及許可權管理系統。

非常感謝社群的活躍開發者，現就職於愛奇藝的 [https://github.com/CodingSinger](https://github.com/CodingSinger)，其是鑑權模組的發起者和主要開發貢獻者。

## 協議 - 3.0

以下是 Dubbo 2.0 協議，我們之前已經在多個場合做過詳細的講解。

![14.png](https://ucc.alicdn.com/pic/developer-ecology/769897b329924f85a17d1440e029f7f7.png)

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 介面同步工作

以下是應用粒度服務註冊（服務自省）的基本工作原理，請持續關注後續對這部分的具體解析和開發進展。

![15.png](https://ucc.alicdn.com/pic/developer-ecology/501722aa064f428286a9e5778f0290cd.png)

## 雲原生

雲原生帶來了底層基礎設施，應用開發、部署和運維等全方位的變化。

### 基礎設施

- 基礎設施排程機制變化，帶來運維（生命週期）、服務治理等方面的變化；
- 服務發現能力下沉， Kubernetes 抽象了 Native Service Discovery。

### Service Mesh - 雲原生微服務解決方案

- Mesh 為跨語言、sdk 升級等提供瞭解決方案，Dubbo sdk 要與 Mesh 協作，做到功能、協議、服務治理等多方便的適配；
- Mesh 尚未大規模鋪開，且其更適合對流量管控更關注的應用，傳統 SDK 的效能優勢仍舊存在，兩者混部遷移場景可能會長期存在。

從應用場景上，Dubbo 可能的部署環境包括：

1. 不使用 Kubernetes Native Service，Kubernetes 只作為容器編排排程設施，繼續使用 Dubbo  自建的服務註冊、發現機制；
1. 複用 Kubernetes Native Service，Dubbo 不再關心服務註冊，Dubbo Client 負責服務發現與流量分配；
1. Dubbo sdk 往 Mesh 遷移，一方面要做到適應 Mesh 架構，成為 Mesh 體系下的 RPC 程式設計和通訊方案；另一方面要做到 Dubbo 與 Mesh 架構長期共存，互相打通服務發現和治理體系；
1. Kubernetes 上與雲下混合部署的平滑遷移支援，包括服務發現的統一與網路通訊方案的打通。

從 Dubbo 功能劃分上，將著重從以下方面提供對雲原生基礎設施的支援：

- **生命週期**： Dubbo 與 Kubernetes 排程機制繫結，保持服務生命週期與 Pod 容器等生命週期的自動對齊；
- **治理規則**： 服務治理規則在規則體、規則格式方面進行最佳化，如規則體以 YAML 描述、取消過濾規則對 IP 的直接依賴，定義規則特有的 CRD 資源等；
- **服務發現**： 支援 K8S Native Service 的服務發現，包括 DNS、API-Server，支援 xDS 的服務發現；
- **Mesh 架構協作**： 構建下一代的基於 HTTP/2 的通訊協議，支援 xDS 的標準化的資料下發。

![直播海報.png](https://ucc.alicdn.com/pic/developer-ecology/64429188758c4d118dba3f255f8f56c5.png)

> “[阿里巴巴雲原生](https://developer.aliyun.com/group/alisoftwaretech/)關注微服務、Serverless、容器、Service Mesh 等技術領域、聚焦雲原生流行技術趨勢、雲原生大規模的落地實踐，做最懂雲原生開發者的技術圈。”</string></string>

架構師成長系列 | 從 2019 到 2020，Apache Dubbo 年度回顧與總結

相關文章