一文速覽 Dubbo 3.0

本文將帶你快速瞭解 Dubbo3 的設計背景、總體架構與核心特性、與典型用戶如阿裡巴巴 HSF2 的關係等。也可以通過如下部分瞭解更多：

• 小白用戶，快速瀏覽 Dubbo3 核心特性：
  • 下一代通信協議 - Triple
  • 百萬實例集群的秘密 - 應用級服務發現
  • Dubbo Mesh
• Dubbo3 的相容性與遷移成本?
  • Java - 遷移指南
  • Golang - 遷移指南
• Dubbo3 相關資源：
  • 更多資料，如性能指標、高級特性說明等請參考 多語言 SDK 實現

背景

Dubbo3 的設計與開發有兩個大的背景。

首先，如何更好的滿足企業實踐訴求。 Dubbo 自 2011 由阿裡巴巴捐獻開源以來，一直是眾多大型企業微服務實踐的首選開源服務框架。在此期間，企業架構經歷了從 SOA 架構到微服務架構變遷，Dubbo 社區自身也在不斷的更新迭代以更好的滿足企業訴求。然而 Dubbo2 架構上的局限逐漸在實踐中凸顯：

• 協議，Dubbo2 協議以性能、簡潔著稱，但卻在雲原生時代遇到越來越多的通用性、穿透性問題；
• 可伸縮性，Dubbo2 在可伸縮性上依舊遠超很多其他框架，但隨著微服務帶來更多應用與實例我們不得不思考如何應對更大規模集群的實戰；
• 服務治理易用性，如更豐富的流量治理、可觀測性、智能負載均衡等。

其次，適配雲原生技術棧的發展。 微服務讓業務開發演進更靈活、快捷的同時，也帶來了一些它獨有的特征和需求：如微服務之後組件數量越來越多，如何解決各個組件的穩定性，如何快速的水平擴容等，以 Docker、Kubernetes、Service Mesh 為代表的雲原生基礎設施為解決這些問題帶來了一些新的選擇。隨著更多的微服務組件及能力正下沉到以 Kubernetes 為代表的基礎設施層，傳統微服務開發框架應剔除一些冗餘機制，積極的適配到基礎設施層以做到能力復用，微服務框架生命周期、服務治理等能力應更好地與 Kubernetes 服務編排機制融合； 以 Service Mesh 為代表微服務架構給微服務開髮帶來的新的選擇，Sidecar 給多語言、透明升級、流量管控等帶來的優勢，但同時也帶來運維複雜性、性能損耗等弊端，因此基於服務框架的傳統微服務體系還將是主流，長期仍將占據半壁江山，在長時間內將會維持混合部署狀態。

總體目標

Dubbo3 依舊保持了 2.x 的經典架構，以解決微服務進程間通信為主要職責，通過豐富的服務治理（如地址發現、流量管理等）能力來更好的管控微服務集群；Dubbo3 對原有框架的升級是全面的，體現在核心 Dubbo 特性的幾乎每個環節，通過升級實現了穩定性、性能、伸縮性、易用性的全面提升。

• 通用的通信協議。 全新的 RPC 協議應摒棄私有協議棧，以更通用的 HTTP/2 協議為傳輸層載體，藉助 HTTP 協議的標準化特性，解決流量通用性、穿透性等問題，讓協議能更好的應對前後端對接、網關代理等場景；支持 Stream 通信模式，滿足不同業務通信模型訴求的同時給集群帶來更大的吞吐量。
• 面向百萬集群實例，集群高度可伸縮。 隨著微服務實踐的推廣，微服務集群實例的規模也在不停的擴展，這得益於微服務輕量化、易於水平擴容的特性，同時也給整個集群容量帶來了負擔，尤其是一些中心化的服務治理組件；Dubbo3 需要解決實例規模擴展帶來的種種資源瓶頸問題，實現真正的無限水平擴容。
• 更豐富的編程模型，更小的業務侵入。 在開發態業務應用面向 Dubbo SDK 編程，在運行態 SDK 與業務應用運行在同一個進程，SDK 的易用性、穩定性與資源消耗將在很大程度上影響業務應用；因此 3.0 應該具備更抽象的 API、更友好的配置模式、更少的侵占業務應用資源、具備更高的可用性。
• 更易用、更豐富的服務治理能力。 微服務的動態特性給治理工作帶來了很高的複雜性，而 Dubbo 這方面一直做的不錯，是最早的一批治理能力定義者與實踐者；3.0 需面向更豐富的場景化，提供諸如可觀測性、安全性、灰度發佈、錯誤註入、外部化配置、統一的治理規則等能力。
• 全面擁抱雲原生。

面向企業生產實踐痛點

Dubbo2 仍舊是國內首選開源服務框架，被廣泛應用在互聯網、金融保險、軟體企業、傳統企業等幾乎所有數字化轉型企業中，久經規模化生產環境檢驗。以 Dubbo2 的貢獻者和典型用戶阿裡巴巴為例，阿裡巴巴基於 Dubbo2 在內部維護的 HSF2 框架經歷了歷次雙十一峰值考驗，每天數十億次的 RPC 調用，治理著超過千萬的服務實例。在長期的優化和實踐積累中，阿裡巴巴有了對下一代服務框架的設想與方案，在內部開始了快速演進，並快速的被貢獻到 Apache 社區，如同阿裡巴巴一樣，其他用戶的實踐訴求與痛點也在開源社區快速的積累，形成了一致的方向和技術方案，可以說 Dubbo3 的誕生就來自於超大基數的企業用戶積累，為了更好的滿足他們的實踐訴求。

Dubbo3 融合了阿裡巴巴 HSF2 及其他社區企業的大量服務治理經驗，當前 Dubbo3 已經被全面應用到生產實踐環境，用戶包括阿裡巴巴電商、餓了麽、釘釘、考拉、阿裡雲、小米、工商銀行、風火遞、平安健康等。社區與用戶的合作形成的良性迴圈極大的促進了 Dubbo3 的發展，阿裡巴巴已經以社區版 Dubbo3 完全取代了內部維護的 HSF2 框架，他們的實踐經驗一方面推動 Dubbo3 的穩定性，另一方面正夠源源不斷的將服務治理實踐經驗輸出到開源社區。

面向百萬集群實例，橫向可擴容

隨著微服務實踐經驗的積累，微服務被拆分成更細粒度，部署到越來越多的機器實例，以支撐不斷增長的業務規模。在眾多的 Dubbo2 企業用戶中，尤其是以金融保險、互聯網為代表的規模化企業開始遇到集群容量瓶頸問題（典型的請參照 工商銀行實踐案例 ）：

• 服務發現過程
  • 註冊中心數據存儲規模達到容量瓶頸
  • 數據註冊&推送效率嚴重下降
• Dubbo 進程
  • 侵占更多機器資源，導致業務資源利用率降低
  • 頻繁 GC 影響業務穩定性

Dubbo3 在設計上很好的解決了這些問題，通過全新設計實現的服務治理（服務發現）模型，可以實現服務發現鏈路上的數據傳輸、數據存儲量平均下降 90% 左右；同時 Dubbo3 自身在業務進程中變得更輕量、更穩定，實現提升資源利用率 50%。

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

如果將應用開發粗略劃分為業務開發、運維部署兩個層次，其中變化比較頻繁的因素包括服務（介面）、應用、機器實例。在 2.x 時代，所有這三個因素的增長都會影響微服務集群的總體容量，尤其是介面增減帶來的波動，對整體容量評估是非常不透明的。而在 3.0 中集群容量變化僅與應用名、機器實例兩個因素相關，而容量評估的對象往往都是應用與實例，因此整個集群變的更穩定透明。

雲原生

在雲原生時代，底層基礎設施的變革正深刻影響應用的部署、運維甚至開發過程，往上也影響了 Dubbo3 微服務技術方案的選型與部署模式。

下一代 RPC 協議

新一代的 Triple 協議基於 HTTP/2 作為傳輸層，具備更好的網關、代理穿透性，原生支持 Stream 通信語義，相容 gRPC 協議。

多語言友好

Dubbo3 從服務定義、RPC 協議、序列化、服務治理等多個方面都已經將多語言友好性作為重點考量因素，目前提供了 Java、Golang 穩定的多語言版本，更多語言版本的 3.0 實現如 Rust、Javascript、C/C++、C# 等在開發建設中。

Kubernetes

Dubbo3 開發的應用可以原生部署到 Kubernetes 平臺，Dubbo3 在地址、生命周期等已設計可與 Kubernetes 等容器調度平臺對齊；對於要進一步復用 Kubernetes 底層基礎設施能力的用戶來說，Dubbo3 也已對接到了原生的 Kubernetes Service 體系。

Service Mesh

Service Mesh 強調控制面在微服務治理中的作用，在一定程度上推動了控制面通信協議、職責範圍的擴展與標準化；傳統 Mesh 架構下的 Sidecar 模型強調旁路代理對於流量的統一管控，以實現透明升級、多語言無感、無業務侵入等特性。

Dubbo3 提供了基於自身思考的 Dubbo Mesh 解決方案，強調了控制面對微服務集群的統一管控，而在部署架構上，同時支持 sicecar 與無 sidecar 的 proxyless 部署架構，使用 Dubbo Mesh 的用戶基於自身的業務特點將有更多的部署架構選擇。

異構體系互通

我們正看到越來越多的異構微服務體系互通的訴求，典型如 Dubbo、Spring Cloud、gRPC 等。有些是因為技術棧遷移，有些是組織合併後需要實現業務互調，Dubbo3 藉助於新的服務發現模型以及可靈活擴展的 RPC 協議，可以成為 Dubbo3 未來的發展目標。

原文首於 Dubbo 官網：https://cn.dubbo.apache.org/zh/overview/what/dubbo3/

歡迎在 https://github.com/apache/dubbo 給 Dubbo Star。
搜索關註官方微信公眾號：Apache Dubbo，瞭解更多業界最新動態，掌握大廠面試必備 Dubbo 技能