Dubbo 簡介

Apache Dubbo 是一款 RPC 服務開發框架，用於解決微服務架構下的服務治理和通訊問題。官方提供了 Java、Golang 等多語言 SDK 實現。使用 Dubbo 開發的微服務原生具備相互之間的遠端地址發現與通訊能力， 利用 Dubbo 提供的豐富服務治理特性，可以實現諸如服務發現、負載均衡、流量排程等服務治理訴求。Dubbo 被設計為高度可擴展，用戶可以方便地實現流量攔截、選址的各種自定義邏輯。

Dubbo3 定位為雲原生導向的下一代 RPC 服務框架。3.0 在 Dubbo 2.x 的基礎上進行演進，在保持原有核心功能的同時，Dubbo3 在易用性、超大規模微服務實踐、雲原生基礎設施適配等方面進行了全面升級。幾個主要方向的全面升級，包括易用性、超大規模微服務實踐、雲原生基礎設施適配和安全性。

什麼是 Dubbo

Apache Dubbo 最初由阿里巴巴於 2008 年開源捐贈，並迅速成為國內開源服務框架選型的事實標準框架，被廣泛應用於各行各業。2017 年，Dubbo 正式捐贈給 Apache 軟件基金會，成為 Apache 頂級項目。目前，Dubbo3 已經是一個提供以下功能的一站式微服務解決方案

  • 基於 HTTP/2 的 Triple 協議 和代理 API 的程式設計體驗。
  • 強大的 [流量管理能力] (../../tasks/traffic-management)，例如地址發現、負載均衡、路由地址選擇、動態配置等。
  • 多語言 SDK 實現，涵蓋 Java、Golang、Javascript 等。更多語言實現將陸續發佈。
  • 靈活的適應和擴展能力，可以輕鬆地適應微服務系統的其他組件，如 Tracing 和 Transaction。
  • Dubbo Mesh 解決方案，同時支持 Sidecar 和 Proxyless 等靈活的 Mesh 部署方案。

Apache Dubbo 的整體架構可以很好地滿足企業大規模微服務實踐，因為它從一開始就被設計用於解決超大規模微服務集群的實際問題，無論是阿里巴巴、工商銀行、中國平安、攜程等社區用戶，都通過多年的大規模生產環境流量充分驗證了 Dubbo 的穩定性和性能。因此，Dubbo 在解決業務落地和大規模實踐方面具有無與倫比的優勢。

  • 開箱即用
    • 高度易用性，例如 Java 版本的面向接口的代理特性可以實現本地透明調用
    • 功能豐富，大部分微服務治理能力可以基於原生庫或輕量級擴展實現
  • 專為超大規模微服務集群設計
    • 極致性能，高性能 RPC 通信協議設計與實現
    • 水平擴展，輕鬆支持數百萬集群實例的地址發現和流量管理
  • 高度可擴展
    • 調用過程中流量和協議的攔截和擴展，例如 Filter、Router、LB 等
    • 微服務治理組件的擴展，例如 Registry、Config Center、Metadata Center 等
  • 企業級微服務治理能力
    • 國內公有雲廠商支持的事實標準服務框架
    • 多年企業實踐經驗檢驗

Dubbo 基本工作流程

dubbo-rpc

首先，Dubbo 是一個 RPC 框架，它定義了自己的 RPC 通信協議和編程方法。如上圖所示，使用 Dubbo 時，用戶首先需要定義 Dubbo 服務；其次，在 Dubbo 服務上線部署後，依託 Dubbo 的應用層通信協議實現數據交換，而 Dubbo 傳輸的數據必須序列化，並且這裡的序列化協議是完全可擴展的。使用 Dubbo 的第一步是定義 Dubbo 服務。Dubbo 中服務的定義是一組完成業務功能的方法，您可以選擇以綁定到某種語言的方式來定義它們。例如，在 Java 中，Dubbo 服務有一組方法的接口，也可以使用與語言無關的 Protobuf Buffers IDL 定義服務。服務定義完成後，服務器（Provider）需要提供服務的具體實現並將其聲明為 Dubbo 服務。從服務消費者（Consumer）的角度來看，通過調用 Dubbo 框架提供的 API 可以獲得一個服務代理（stub）對象，之後就可以像調用本地服務一樣調用服務方法了。消費者發起服務方法調用後，Dubbo 框架負責將請求發送到部署在遠程機器的服務提供者。服務提供者收到請求後，會調用服務的實現類，然後將處理結果返回給消費者。這樣就完成了一次完整的服務調用。圖中 Request 和 Response 的數據流動如圖所示。

需要注意的是，在 Dubbo 中，我們所說的服務，通常指的是提供特定業務增刪改查功能的 RPC 粒度的接口或方法，這與一些微服務概念書籍中普遍談到的服務概念並不相同。

在分散式系統中，特別是隨著微服務架構的發展，應用程式的部署、發布和擴展變得極其頻繁。作為一個 RPC 消費者，如何動態地發現服務提供者的地址成為 RPC 通訊的前提條件。Dubbo 提供了一種自動地址發現機制，來應對分散式場景下機器實例的動態遷移。如下圖所示，通過引入註冊中心來協調提供者和消費者的地址。提供者啟動後，會向註冊中心註冊自己的地址，消費者通過拉取或訂閱註冊中心特定節點的方式，動態感知提供者的地址列表變化。

arch-service-discovery

Dubbo 核心功能

高性能 RPC 通信協定

跨進程或主機的服務通信是 Dubbo 的基本能力。Dubbo RPC 以預先定義的協議編碼方式將請求數據（Request）發送給後端服務，並接收服務端返回的計算結果（Response）。RPC 通信對用戶完全透明，用戶無需關心請求是如何以及在哪裡發送的，每次調用只需要獲得正確的調用結果。除了同步模式下的 Request-Response 通信模型，Dubbo3 還提供了更豐富的通信模型選擇

  • 消費者端異步請求（Client Side Asynchronous Request-Response）
  • 提供者端異步執行（Server Side Asynchronous Request-Response）
  • 消費者請求流（Request Streaming）
  • 提供者響應流（Response Streaming）
  • 雙向串流

詳細請參考各語言 SDK 實現的可選協議列表或 Triple 協議

自動服務（地址）發現

Dubbo 的服務發現機制允許微服務組件獨立演進和任意部署，消費者無需知道對端的部署位置和 IP 地址即可完成通信。Dubbo 提供了基於客戶端的服務發現機制，用戶可以通過多種方式啟用服務發現

  • 使用獨立的註冊中心組件，例如 Nacos、Zookeeper、Consul、Etcd 等
  • 將服務的註冊與發現交給底層容器平台，例如 Kubernetes，可以理解為更加雲原生的用法

運行態流量管控

透明的地址發現讓 Dubbo 請求可以發往任何一個 IP 實例，流量在這個過程中被隨機分配。當需要對流量進行更豐富、更細粒度的控制時，就可以使用 Dubbo 的流量管控策略。Dubbo 提供了包括負載均衡、流量路由、請求超時、流量降級、重試等在內的策略，基於這些基礎能力你可以輕鬆實現更多場景化的路由方案，包括灰度發布、A/B 測試、權重路由、同區域優先等。更酷的是，Dubbo 支持流量管控策略在運行態動態生效，無需重新部署。詳細請參考

豐富的擴展組件和生態

Dubbo 強大的服務治理能力不僅體現在核心框架，還包括其優秀的擴展能力以及周邊配套設施的支持。通過 Filter、Router、Protocol 等幾乎存在於每個關鍵流程的擴展點定義，我們可以豐富 Dubbo 的功能或者實現與其他微服務配套系統的對接，包括事務、追蹤等。目前已經有通過 SPI 方式進行擴展的實現，詳細請參考 Dubbo 擴展性說明，你也可以在 apache/dubbo-spi-extensions 項目中找到更多擴展實現。詳細請參考

雲原生設計

Dubbo 在設計上完全遵循雲原生微服務的發展理念，這體現在很多方面。首先，它支援雲原生基礎設施和部署架構，包括容器、Kubernetes 等。Dubbo Mesh 的整體解決方案也在 3.1 版本正式發布；另一方面，Dubbo 的許多核心組件都針對雲原生進行了升級，包括 Triple 協議、統一路由規則以及多語言支援。

值得一提的是，未來也規劃了如何使用 Dubbo 支援 Serverless 等彈性伸縮服務，包括使用 Native Image 來提升 Dubbo 的啟動速度和資源消耗。

結合目前的版本，本節主要從以下兩點展開 Dubbo 的雲原生特性

Kubernetes

Dubbo 微服務要支援 Kubernetes 平台調度，最基本的是要實現 Dubbo 服務生命週期與容器生命週期的對齊，這包含 Dubbo 啟動、銷毀、服務註冊等生命週期事件。相比以往 Dubbo 自定義生命週期事件，並要求開發者在運維實踐中遵守約定，Kubernetes 底層基礎設施定義了嚴格的組件生命週期事件（探針），反過來要求 Dubbo 根據約定進行適配。

Kubernetes Service 是另一個層面的適配，體現了服務定義和註冊下沉到雲原生底層基礎設施的趨勢。在這種模式下，用戶不再需要搭建額外的註冊中心組件，Dubbo 消費者端節點可以自動連接到 Kubernetes（API-Server 或 DNS），並根據服務名稱（Kubernetes Service Name）查詢實例列表（Kubernetes Endpoints）。此時，服務通過標準的 Kubernetes Service API 定義，並被調度到各個節點。

Dubbo Mesh

服務網格（Service Mesh）在業界已經被廣泛傳播和認可，被認為是下一代微服務架構，主要原因是它解決了很多難題，包括透明升級、多語言、依賴衝突、流量管理等。服務網格的典型架構是通過部署獨立的 Sidecar 組件攔截所有出口和入口流量，並在 Sidecar 中集成負載均衡、路由等豐富的流量管理策略。此外，服務網格還需要一個控制平面（Control Plane）來實現對 Sidecar 流量的控制，即下發各種策略。我們這裡稱這種架構為經典網格（Classic Mesh）。

然而，沒有任何技術架構是完美的，經典網格在落地層面也面臨著成本高的問題

  1. 需要運維控制平面（Control Plane）
  2. 需要運維 Sidecar
  3. 需要考慮如何從原來的 SDK 遷移到 Sidecar
  4. 需要考慮引入 Sidecar 後整個鏈路的效能損耗

為了了解決 Sidecar 引入的相關成本問題，Dubbo 引入並實現了了一種新的 Proxyless Mesh 架構。顧名思義，Proxyless Mesh 指的是無 Sidecar 部署，Dubbo SDK 直接與控制平面互動。架構圖如下

dubbo-proxyless

可以想像，在不同的組織和不同的發展階段，使用 Dubbo 構建的微服務未來將允許三種部署架構：傳統 SDK、基於 Sidecar 的服務網格和無 Sidecar 的 Proxyless Mesh。基於 Sidecar 的服務網格，即經典網格架構，獨立的 Sidecar 運行時接管所有流量，與 Proxyless Mesh 隔離的 Sidecar，次要 SDK 通過 xDS 直接與控制平面通信。Dubbo 微服務允許部署在實體機器、容器和 Kubernetes 平台上，並且可以使用 Admin 作為控制平面，並使用統一的流量治理規則進行管理。


最後修改日期：2024 年 3 月 8 日：更新 overview.md (#2935) (23f1a3d9010)