作者 | 劉軍

4 月 15 日-16 日，由 InfoQ 主辦的 DIVE 全球基礎軟體創新大會通過雲上展廳的形式成功召開。在微服務 & 服務治理專場，Apache Dubbo PMC、Dubbo 開源專案負責人劉軍帶來了主題為《Dubbo3 落地實踐及其 Mesh 解決方案》的演講，以下為主要內容。

下一代雲原生服務框架 Dubbo3

首先帶大家瞭解下 Dubbo3 到底是什麼？與 2.7 架構的主要區別是什麼？提供了哪些特性、可以解決哪些實際的問題？其中也包括大家都關心的相容性、升級成本以及與 HSF2 的關係等問題。

Dubbo3 核心設計原則與特性

我們定義 Dubbo3 是下一代的雲原生服務框架，但 3.0 架構到底都包含哪些內容？

先來看下 Dubbo 3.0 的一些核心設計原則：

• 首先，在架構層面，Dubbo 是面向雲原生設計的，支援超大規模的微服務叢集實踐 - 百萬例項級別，期望通過智慧化流量排程系統提升系統穩定性與吞吐量；

• 在策略層面，Dubbo3 的核心將是毫無保留開源的，它將成為國內公有云事實標準的服務框架，得到各大公有云廠商的支援，並通過靈活的 SPI 擴充套件機制支援不同部署場景的定製化需求；

• 在業務價值上，Dubbo3 將顯著降低單機資源消耗，提升全鏈路資源利用率與服務治理效率。

這就是 3.0 設計過程中遵循的核心原則或目標，也讓我們從一個更高的層面認識了 Dubbo3。

具體到選型 Dubbo3 框架，大家除了會關心 Dubbo3 提供了哪些新功能，Dubbo 老使用者還會關心 Dubbo3 的相容性，Dubbo3 的遷移成本以及其能帶來的核心價值。

首先，Dubbo3 是從其自身 2.0 架構演進而來，因此它繼承了 2.0 幾乎所有的特性，且保持了對 Dubbo2 的完全相容，因此，老使用者幾乎可以零成本遷移到 Dubbo3。

其次，Dubbo3 是在企業實踐經驗的基礎上演進而來的。Dubbo 最初是由阿里開源並貢獻給 Apache 社群，而這一次，阿里也已將 Dubbo3 定位為其下一代服務框架。因此，Dubbo3 融合了 HSF2 的幾乎所有服務治理特性，並且已經開始在阿里巴巴全面取代 HSF2 框架。

Dubbo3 提供的核心特性主要包括四部分：

• 全新服務發現模型。 應用粒度服務發現，面向雲原生設計，適配基礎設施與異構系統，效能與叢集伸縮性大幅提升。
• 下一代 RPC 協議 Triple。

為什麼要升級 Dubbo3？

接下來，我將重點分析升級 Dubbo3 能帶來的收益。 首先是效能、資源利用率的提升。升級 Dubbo3 的應用預期能實現單機記憶體 50% 的下降，對於越大規模的叢集效果將越明顯，Dubbo3 從架構上支援百萬例項級別的叢集橫向擴充套件,同時依賴應用級服務發現、Triple 協議等可以大大提供應用的服務治理效率和吞吐量。

其次，Dubbo3 讓業務架構升級變得更容易、更合理。其中值得重點關注的就是協議，在 2.x 版本中，web、移動端與後端的通訊都要經過閘道器代理，完成協議轉換、型別對映等工作，Triple 協議讓這些變得更容易與自然，並通過流式通訊模型滿足更多的業務場景。

最後，得益於 Dubbo3 的完善雲原生解決方案，Dubbo3 可以幫助業務遮蔽底層雲原生基礎設施細節，使得業務的遷移成本更低。

Dubbo3 的首個社群版本釋出於 2021 年 6 月，在此之後，經過了多個版本的快速迭代。自 3.0.6 版本開始，Dubbo3 已經進入穩定迭代狀態，並同步釋出了 Java、Golang 等多語言 SDK 版本，目前最新版本的核心功能已經穩定並可用於大規模生產實踐。

之前我們提到過，Dubbo3 不止是一個社群版本，它也是阿里定義的下一代服務框架，Dubbo3 已經在整個阿里經濟體大規模推開，包括阿里的多條生態業務線、阿里電商系統以及阿里雲。

其中，阿里生態如本地生活餓了麼、釘釘、考拉等都已經全面升級 Dubbo3；天貓、淘寶等電商核心鏈路也已啟動 Dubbo3 升級，預期 2022 雙 11 都將跑在 Dubbo3 之上；阿里雲的微服務平臺、多條產品線目前也完全基於 Dubbo3 構建。

此外，像小米、工商銀行、風火遞、平安健康等企業也已經成功實踐了 Dubbo3 核心特性，社群也在持續收到更多企業對於 Dubbo3 的調研及試點諮詢。

Dubbo 官方專門開闢了一個 Dubbo3 使用者登記視窗，在試點/使用/調研 Dubbo3 的使用者都可在此填寫資訊，包括對 Dubbo 的期待，社群將在後續與登記使用者取得聯絡並探索深入支援與合作的可能性。如果你當前正在推動或調研 Dubbo3 的企業實踐，可以在此 issue 登記使用資訊，一方面可以得到社群開發者的更快速的支援，另一方面也方便社群使用者之間的互相交流。

GitHub 地址：https://github.com/apache/dubbo/issues/9436

Dubbo3 企業實踐案例

下面，我將分享一些 Dubbo3 的企業實踐案例，看看 Dubbo3 已經在哪些企業得到了應用，解決了哪些實際問題，取得了什麼效果，給大家引入 Dubbo3 做一些穩定性與功能性的參考。

工商銀行的 Dubbo3 實踐

工商銀行選型 Dubbo3 的應用級服務發現架構，核心原因是 2.x 版本架構在超大規模叢集實戰上的效能和容量瓶頸。

上圖右側是經典的 Dubbo 的工作原理圖，服務提供者和消費者通過註冊中心協調實現地址的自動發現。

工商銀行面臨的主要瓶頸是在註冊中心與服務消費端，介面級別地址的數量已經是億級規模，一方面儲存容量達到瓶頸、另一方面推送效率明顯下降；而在消費端這一側，Dubbo2 框架常駐記憶體已超 40%，每次地址推送帶來的 cpu 等資源消耗率也非常高，影響正常的業務呼叫。

這已經是架構問題，通過常規的效能優化無法從根本上解決問題。因此工商銀行採用了 Dubbo3 中提出的應用級服務發現模型，經過實測，新的服務發現模型能實現節點到註冊中心間資料傳輸量 90% 的下降，這就使得註冊中心的壓力極大降低，同時消費端的框架常駐記憶體也實現超 50% 下降。

下面是工商銀行聯合 Dubbo 社群給出的一組基於真實服務特點給出的模擬壓測資料。

上圖是對使用了應用級服務發現的消費端程序取樣的記憶體對比資料。其中橫軸是不同的 Dubbo 版本，縱軸是實際取樣到的記憶體表現，可以看到 Dubbo 2.6、2.7 版本表現幾乎一致，而升級到 3.0 版本後，即使不升級應用級服務發現，記憶體也降低接近 40%，而當切換到應用級服務發現之後，記憶體佔用下降到只有原來的 30%。

上圖是消費端的 GC 情況統計，同樣的，橫軸是不同的 Dubbo 版本，縱軸是實際取樣到的 GC 表現。這裡的壓測資料，是通過模擬註冊中心不停的往消費端程序推送地址列表的場景得到的。可以看到 Dubbo 2.6、2.7 版本表現幾乎一致，而在 3.0 版本中切換到應用級服務發現之後，GC 已經趨近於零次。

阿里生態跨閘道器互通

第二個案例是 Dubbo3 的 Triple 協議在阿里經濟體的應用。

阿里經濟體內很多業務之間都有資料互通的訴求，相互之間需要互相呼叫，很多這樣的呼叫在部署架構上都是跨域的，因此面臨服務治理資料隔離、訪問安全性等問題，所以不得不考慮基於閘道器的互通方案。

在升級 Dubbo3 之後，由於 Triple 協議從設計上對閘道器更友好、原生支援 TLS 安全連結，通過直接將 HSF2 的應用升級為 Dubbo3，Dubbo3 業務暴露 Triple 協議，可以實現高效、安全得的多條業務線的跨域互通。

目前包括未來阿里經濟體內的跨域互通方案，都將會執行在 Dubbo3 協議之下。

阿里巴巴的 Dubbo3 實踐

Dubbo3 在阿里內部上線後，一個更大的優勢在於其對整體架構穩定性的提升，新的服務發現架構使得對於整個叢集容量、可伸縮性評估變得更容易、更準確。

上圖中我們將應用開發粗略劃分為業務開發、運維部署兩個層次，其中變化比較頻繁的因素包括服務（介面）、應用、機器例項。

在 2.x 時代，所有這三個因素的增長都會影響微服務叢集的總體容量，尤其是介面增減帶來的波動，對整體容量評估是非常不透明的。而在 3.0 中叢集容量變化僅與應用名、機器例項兩個因素相關，而我們容量評估的物件往往都是應用與例項，因此整個叢集叢集變的更穩定透明。

Dubbo3 Mesh 方案解析

最後分享下 Dubbo3 即將釋出的 Mesh 解決方案。當前 Java、Golang 等語言都發布了 POC 或 beta 版本，關於這部分的正式版本將在 3.1 中和大家見面。

提到 Service Mesh，我們就會想到經典的 Sidecar Mesh 部署架構，Dubbo3 毫無疑問將提供對此部署架構的支援。

如上圖所示，Dubbo 可以與 Sidecar 部署在同一個 Pod 或容器中，通過在外圍部署一個獨立的控制平面，實現對流量和治理的統一管控。控制面與 SIcecar 之間通過圖中虛線所示的 xDS 協議進行配置分發，而 Dubbo 程序間的通訊不再是直連模式，轉而通過 Sidecar 代理，Sidecar 攔截所有進出流量，並完成路由定址等服務治理任務。

Sidecar 模式的 Mesh 架構有很多優勢，如平滑升級、多語言、業務侵入小等，但也帶來了一些額外的問題，比如：

• Sidecar 通訊帶來了額外的效能損耗，這在複雜拓撲的網路呼叫中將變得尤其明顯。
• Sidecar 的存在讓應用的宣告週期管理變得更加複雜。
• 部署環境受限，並不是所有的環境都能滿足 Sidecar 部署與請求攔截要求。

針對上述問題，Dubbo 社群自很早之前就做了 Dubbo 直接對接到控制面的設想與思考，並在國內開源社群率先提出了 Proxyless Mesh 的概念，當然就 Proxyless 概念的說法而言，最開始是谷歌提出來的。

Proxyless 模式使得微服務又回到了 2.x 時代的部署架構。如上圖所示，和我們上面看的 Dubbo 經典服務治理模式非常相似，所以說這個模式並不新鮮， Dubbo 從最開始就是這麼樣的設計模式。但相比於 Mesh 架構，Dubbo2 並沒有強調控制面的統一管控，而這點恰好是 Service Mesh 所強調的，強調對流量、可觀測性、證書等的標準化管控與治理，也是 Mesh 理念先進的地方。

在 Dubbo3 Proxyless 架構模式下，Dubbo 程序將直接與控制面通訊，Dubbo 程序之間也繼續保持直連通訊模式，我們可以看出 Proxyless 架構的優勢：

• 沒有額外的 Proxy 中轉損耗，因此更適用於效能敏感應用。
• 更有利於遺留系統的平滑遷移。
• 架構簡單，容易運維部署。
• 適用於幾乎所有的部署環境。

至於 Proxyless 是如何工作的，如上圖所示，集成了 Proxyless 功能的 Dubbo3 程序部署在容器或 Pod 中，通過 xDS 與控制面做策略互動。但在 SDK 與控制面中間，有一個獨立部署的 Agent 元件，它是 SDK 與控制面通訊的代理元件，通常僅完成包括認證及證書更新等任務。

具體 Agent 元件的職責與特定的控制面選型相關，當然 Dubbo 也計劃支援無 Agent 代理直連控制面的實現。但由於這個 Agent 並不在流量通訊鏈路上，只負責證書的下發，理論上對整體架構並無太大影響。

當前 Dubbo3 提供支援的特性包括：

• 應用級別的服務地址發現。
• 路由規則等服務管控策略。

Proxyless 模型也面臨一些限制，如：

• 繫結特定的 Control Plane。
• 多語言實現的限制。
• 與 Sidecar 版本功能上的差異。
• 無法複用如 Envoy 生態擴充套件，但 dubbo 擴充套件同樣相對容易。

未來的 Dubbo3 Mesh 部署形態

當前 Dubbo3 對於 Mesh 的支援已經發布了 poc 版本，涵蓋了 Java 與 Golang 兩種語言實現，並將在隨後的 3.1 版本中正式釋出與大家見面，我們預測在未來的一段時間內，Sidecar 模式與 Proxyless 模式將長期共存，尤其是從穩定性、效能、遷移成本等多方面考量。

通過混合部署的模式，將能夠實現實現服務治理控制面的共享，應對不同場景的部署要求，適應複雜的基礎設施環境並從總體上提升架構的可用性。

總結

Dubbo 長期以來都是國內開源微服務領域的首選 RPC 框架，在金融保險、網際網路巨頭、科技公司、各大傳統企業中都有著非常廣泛、大規模的應用。而 3.0 作為 Dubbo 面向雲原生的下一代服務框架，受到了以阿里巴巴為代表的企業全力支援，隨著 Dubbo3 在餓了麼、考拉、釘釘、阿里巴巴、阿里雲、工行銀行、小米、平安健康、風火遞等企業的大規模落地，標誌著 Dubbo3 正式步入了穩定迭代狀態。

同時，Dubbo3 作為國內首個提出 Proxyless Mesh 方案的開源社群，已經在社群全面啟動了對 Service Mesh 解決方案的開發與支援，並將在 3.1 中迎來首個正式版本釋出。如果你當前正在推動或調研 Dubbo3 的企業實踐，可以在此 issue 登記使用資訊。

作者簡介：劉軍，Dubbo 開源社群負責人，Apache Dubbo PMC，推動 Dubbo 重啟開源併成為 Apache 頂級專案，領導了 Dubbo3 的整體架構設計與部分開發工作。當前工作在阿里雲-雲原生應用平臺團隊，主要負責下一代雲原生服務框架的演進推廣相關工作，開源愛好者。