架構師成長系列 | 從 2019 到 2020，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/二、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 的標準化的數據下發。

查看更多：https://yqh.aliyun.com/detail..._content=g_1000106109

上雲就看雲棲號：更多雲資訊，上雲案例，最佳實踐，產品入門，訪問：https://yqh.aliyun.com/