架构师成长系列 | 从 2019 到 2020，Apache Dubbo 年度回顾与总结
作者 | 劉軍（陸龜）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 styleString 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 styleCompletableFuture<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 可能的部署環境包括：
從 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 年度回顾与总结的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： 架构师成长系列 | 云原生时代的 Dev
- 下一篇： Golang 1.14 发布 | 云原生