Dubbo 3 快速概覽

本文將帶您快速了解 Dubbo3 的設計背景、整體架構和核心特性，以及它與阿里巴巴 HSF2 等典型用戶的關係。您也可以在以下章節中了解更多資訊。

背景

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

**首先，如何更好地滿足企業實務的需求。** 自從 2011 年阿里巴巴捐贈 Dubbo 以來，它一直是許多大型企業微服務實務的首選開源服務框架。在此期間，企業架構經歷了從 SOA 架構到微服務架構的變革，Dubbo 社群本身也在不斷更新迭代，以更好地滿足企業的需求。然而，Dubbo2 架構的局限性在實務中逐漸凸顯。

  • **協定方面**，Dubbo2 協定以其效能和簡潔性而聞名，但在雲原生時代，它在通用性和穿透性方面遇到越來越多的問題；
  • **擴充性方面**，Dubbo2 在擴充性方面仍然遠優於許多其他框架，但隨著微服務帶來更多的應用程式和實例，我們不得不思考如何應對更大規模叢集的實際戰鬥；
  • **服務治理易用性方面**，例如更豐富的流量治理、可觀測性、智慧負載平衡等。

**其次，適應雲原生技術棧的發展。** 微服務化使業務發展的演進更加靈活快速，但也帶來了一些特有的特性和要求：例如微服務化後組件數量增多，如何解決各個組件的穩定性、如何快速水平擴展等問題，以 Docker、Kubernetes、Service Mesh 為代表的雲原生基礎設施為解決這些問題帶來了一些新的選項。隨著越來越多的微服務組件和能力下沉到以 Kubernetes 為代表的基礎設施層，傳統的微服務開發框架應當剔除一些冗餘的機制，積極適應基礎設施層以實現能力複用。微服務框架的生命週期、服務治理等能力應當與 Kubernetes 的服務編排機制更好的融合；以 Service Mesh 為代表的微服務架構為微服務開發帶來了新的選項，Sidecar 帶來了多語言、透明升級、流量管控等優勢，但也帶來了運維複雜度提升、性能損耗等劣勢。因此，基於服務框架的傳統微服務體系依然會是主流，在很長一段時間內仍將佔據半壁江山，並將長期保持混合部署的狀態。

總體目標

Dubbo3 仍然維持 2.x 的經典架構。其主要職責是解決微服務進程間的通訊，並通過豐富的服務治理能力（例如地址發現、流量管理等）更好地管理和控制微服務集群；框架的升級是全面的，體現在 Dubbo 核心特性的幾乎方方面面，通過升級實現穩定性、性能、可擴展性、易用性等方面的全面提升。

architecture-1

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

面向企業生產實踐的痛點

Dubbo2 仍然是中國首選的開源服務框架。它廣泛應用於幾乎所有數位轉型企業，例如網際網路、金融保險、軟體公司和傳統企業，並已在大規模生產環境中得到驗證。以 Dubbo2 的貢獻者和典型用戶阿里巴巴為例，阿里巴巴內部基於 Dubbo2 維護的 HSF2 框架經歷了之前的雙十一峰值測試，每天進行數十億次 RPC 呼叫，管理超過千萬個服務實例。在長期優化和實踐積累中，阿里巴巴對下一代服務框架有了願景和規劃，並開始在內部快速演進，並迅速貢獻給 Apache 社群。如同阿里巴巴一樣，其他用戶的實際需求及痛點也在開源社群中快速累積，形成了一致的方向和技術解決方案。可以說，Dubbo3 的誕生源於廣大企業用戶的實踐積累，旨在更好地滿足他們的實際需求。

dubbo3-hsf

Dubbo3 整合了阿里巴巴 HSF2 和其他社群企業的大量服務治理經驗。目前，Dubbo3 已全面應用於生產實踐環境，例如銀行、烽火地、平安健康等。社群與用戶合作形成的良性循環極大地推動了 Dubbo3 的發展。阿里巴巴已將內部維護的 HSF2 框架完全替換為社群版本的 Dubbo3，他們的實踐經驗一方面促進了 Dubbo3 的穩定性，另一方面也積極地將服務治理的實踐經驗持續輸出到開源社群。

針對數百萬叢集實例，水平擴展性

隨著微服務實踐經驗的積累，微服務被拆分成更細的粒度，並部署到越來越多的機器實例上，以支援不斷增長的業務規模。在眾多 Dubbo2 企業用戶中，尤其是以金融、保險和網際網路為代表的大型企業，他們開始遇到叢集容量瓶頸（典型案例可參考工商銀行實踐案例）。

  • 服務發現流程
    • 註冊中心的資料儲存規模達到容量瓶頸
    • 資料註冊與推送效率嚴重降低
  • Dubbo 流程
    • 佔用更多機器資源，導致業務資源利用率降低
    • 頻繁的 GC 影響業務穩定性

Dubbo3 在設計上很好地解決了這些問題。透過全新設計實現的服務治理（服務發現）模型，可以實現服務發現環節上的資料傳輸和資料儲存平均減少約 90%；同時，Dubbo3 本身在業務流程中變得更輕量、更穩定，實現資源利用率提升 50%。

Dubbo3 更大的優勢在於提升了整體架構的穩定性。新的服務發現架構使得評估整個叢集的容量和擴展性變得更容易、更準確。

capacity

如果將應用程式開發大致分為業務開發和維運部署兩個層級，經常變化的因素包括服務（介面）、應用程式和機器實例。在 2.x 時代，這三個因素的增長都會影響微服務叢集的整體容量，尤其是介面增減造成的波動，對整體容量評估非常不透明。在 3.0 中，叢集容量的變化只與應用程式名稱和機器實例兩個因素相關，而容量評估的對象往往是應用程式和實例，因此整個叢集變得更穩定和透明。

雲原生

在雲原生時代，底層基礎設施的變化正在深刻影響應用程式部署、維運，甚至開發流程。它也影響著 Dubbo3 微服務技術方案的選擇和部署模式。

下一代 RPC 協定

新一代的三重協議（Triple protocol）基於 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）強調控制平面在微服務治理中的作用，這在一定程度上推動了控制平面通訊協議和職責範圍的擴展和標準化；傳統 Mesh 架構下的 Sidecar 模式強調通過旁路代理統一控制流量，以實現透明升級、多語言無感知、無業務侵入等特性。

Dubbo3 提供了基於自身思考的 Dubbo Mesh 解決方案，強調微服務叢集的統一管理和控制。在部署架構方面，它同時支援 sidecar 和無 sidecar 的 proxyless 部署架構。使用 Dubbo Mesh 的用戶可以根據自身業務特性選擇更合適的部署架構。

異構系統互通性

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


最後修改日期：2023 年 2 月 22 日：合併重構網站 (#2293) (4517e8c1c9c)