作者 | 劉軍（陸龜）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 相關的項目也進行了遷移，都遷移到了 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 可能的部署環境包括：

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

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

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

“阿里巴巴雲原生關注微服務、Serverless、容器、Service Mesh 等技術領域、聚焦雲原生流行技術趨勢、雲原生大規模的落地實踐，做最懂雲原生開發者的技術圈。”

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

社區回顧

重點功能回顧

編程模型

性能優化

1. 系統吞吐量

2. RPC 調用鏈路

3. 服務治理鏈路

服務治理

傳輸協議

Roadmap

微服務功能

協議 - 3.0

服務自省 - 應用粒度的服務註冊

雲原生

基礎設施

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

美團一面：項目中有 10000 個 if else 如何優化？想了半天，被問懵了！

京東面試：如何進行JVM調優？

Python 將PowerPoint (PPT/PPTX) 轉爲HTML

SQL優化-20231016

深度解讀暢捷通雲原生架構轉型實戰歷程

雲原生下的灰度體系建設

WebAssembly + Dapr = 下一代雲原生運行時？

無責任暢想：雲原生中間件的下一站

支持 gRPC 長鏈接，深度解讀 Nacos 2.0 架構設計及新模型

https://yachay.unat.edu.pe/blog/index.php?comment_area=format_blog&comment_component=blog&comment_co

linux以太網驅動總結