架構

RPC 通訊

Dubbo3 的 Triple 協議構建於 HTTP/2 協議之上，因此具有更好的穿透性和通用性。Triple 協議兼容 gRPC，提供 Request Response、Request Streaming、Response Streaming、Bi-directional Streaming 等通訊模型；從 Triple 協議開始，Dubbo 也支援基於 IDL 的服務定義。

除此之外，Dubbo 還整合了業界大部分主流的協議，用戶可以在 Dubbo 框架內使用這些通訊協議，Dubbo 為用戶提供了統一的編程模型和服務治理模型，這些協議包括 rest、hessian2、jsonrpc、thrift 等，需要注意的是不同語言 SDK 實現支援的範圍會有所差異。

詳情可查看

服務發現

服務發現，即消費者自動發現服務地址列表的能力，是微服務框架需要具備的關鍵能力，藉助自動化的服務發現，微服務之間可以在無需感知對方部署位置和 IP 位址的情況下進行通訊。

實現服務發現的方式有很多種，Dubbo 提供了基於客戶端的服務發現機制，通常需要部署額外的第三方註冊中心组件來協調服務發現過程，例如常用的 [Nacos](https://nacos.io/)、Consul、Zookeeper 等，Dubbo 本身也提供了對接各種註冊中心組件的能力，用戶可以靈活選擇。

Dubbo 基於消費者端的自動服務發現能力，其基本工作原理如下

architecture

在傳統部署架構下，服務發現涉及三個參與角色：提供者、消費者和註冊中心。其中，提供者將 URL 地址註冊到註冊中心，註冊中心負責匯總數據，消費者從註冊中心訂閱 URL 地址並進行續期。在雲原生背景下，例如當應用部署在 Kubernetes 等平台上時，由於平台自身維護了應用/服務與實例之間的映射關係，註冊中心以及註冊動作在一定程度上被下沉到了基礎設施層，此時框架自身提供的註冊動作有時並非必須。

Dubbo3 提供了一種全新的應用級服務發現模型，它在設計和實現上不同於 Dubbo2 的介面級服務發現模型。可以查看這裡

  • [應用級服務發現](/zh-tw/docs3-v2/java-sdk/concepts-and-architecture/service-discovery/#應用級服務發現簡介)

流量管理

從 Dubbo2 開始，Dubbo 就提供了豐富的服務治理規則，包括路由規則、動態配置等。

Dubbo3 一方面通過對接 xDS 來打通 Istio 等主流 Mesh 產品中使用的 VirtualService、DestinationRule 等為代表的治理規則；另一方面，Dubbo 也在謀求設計一套自有的規則，用於實現流量治理，以及靈活的治理能力。

Dubbo Mesh

Dubbo Mesh 的目標是提供一套適配 Dubbo 體系的完整 Mesh 解決方案，包括定製化的控制平面（Control Plane）和定製化的數據平面解決方案。Dubbo 控制平面基於業界主流的 Istio 擴展，支持更豐富的流量治理規則、Dubbo 應用級服務發現模型等。Dubbo 數據平面可以使用 Envoy Sidecar，實現 Dubbo SDK + Envoy 的部署方案，也可以使用 Dubbo Proxyless 模式，直接實現 Dubbo 與控制平面的通信。Dubbo Mesh 處於快速演進中，我們會盡力保持文檔內容的更新。

mix-mesh

查看這裡以了解 Dubbo Mesh 設計詳情

部署架構

本節主要介紹 Dubbo 在傳統模式下的部署架構。在雲原生背景下，部署架構會發生變化，主要體現在基礎設施（Kubernetes、Service Mesh 等）會承擔更多職責，註冊中心、元數據中心、配置中心等中心化組件的職責被整合，運維變得更加簡單，但通過強調這些中心化組件，更有利於我們理解 Dubbo 的工作原理。

Dubbo sdk 作為微服務框架，伴隨著微服務組件部署在分散式集群的各個位置。為了實現分散式環境下各個微服務組件之間的協作，Dubbo 定義了一些中心化的組件，包括

  • 註冊中心。協調 Consumer 與 Provider 之間的地址註冊與發現
  • 配置中心。
    • 存放 Dubbo 啟動階段的全局配置，保證配置的跨環境共享與全局一致性
    • 負責服務治理規則（路由規則、動態配置等）的存儲與推送。
  • 元數據中心。
    • 接收 Provider 上報的服務介面元數據，為 Admin 等控制台提供運維能力（例如：服務測試、介面文檔等）
    • 作為服務發現機制的一項補充，它提供了額外介面/方法級配置資訊的同步能力，相當於註冊中心的額外擴展。

threecenters

上圖完整地描述了 Dubbo 微服務組件與各個中心之間的交互流程。

以上三個中心並不是運行 Dubbo 的必要條件，用戶可以根據自身的業務情況決定只啟用其中一個或多個來簡化部署。通常情況下，所有用戶都會註冊一個獨立的註冊中心以啟動 Dubbo 服務開發，而配置中心和元數據中心則會在微服務演進過程中按需逐步引入。

註冊中心

註冊中心扮演著非常重要的角色，它承載著服務註冊與服務發現的職責。目前 Dubbo 支援以下兩種粒度的服務發現和服務註冊，即介面級和應用級，註冊中心可以按需部署。

  • 在傳統的 Dubbo SDK 使用姿勢下，如果只提供直連模式的 RPC 服務，則無需部署註冊中心。

  • 無論是介面級還是應用級，如果需要 Dubbo SDK 本身進行服務註冊與服務發現，則可以選擇部署一個註冊中心，並在 Dubbo 中集成相應的註冊中心。

  • 在 Dubbo + Mesh 場景下，隨著 Dubbo 服務註冊能力的弱化，Dubbo 中的註冊中心不再是必須的，其職責開始被控制平面所取代。如果採用 Dubbo + Mesh 的部署方式，無論是 ThinSDK 的 Mesh 方式還是 Proxyless 的 Mesh 方式都不再需要獨立部署註冊中心。

註冊中心不依賴於配置中心和元數據中心，如下圖所示

centers-registry

圖中未部署配置中心和元數據中心。在 Dubbo 中，預設情況下會將註冊中心的實例同時作為配置中心和元數據中心使用，這是 Dubbo 的預設行為。如果真的不需要配置中心或元數據中心的能力，可以在配置中關閉。在註冊中心的配置中有兩個配置，分別是 use-as-config-center 和 use-as-metadata-center，只需將配置設為 false 即可。

元數據中心

在 2.7.x 版本中開始支援元數據中心。隨著應用級服務註冊與服務發現的落地，元數據中心變得越來越重要。以下情況下將需要部署元數據中心

  1. 對於一個原本使用舊版本 Dubbo 構建的應用服務，在遷移到 Dubbo 3 時，Dubbo 3 將需要一個元數據中心來維護 RPC 服務與應用之間的映射關係（即介面與應用之間的映射關係），因為如果採用應用級服務發現與服務註冊，在註冊中心中將會採用「應用-實例列表」結構的數據組織形式，不再是之前的「介面-實例列表」結構的數據組織形式。當使用介面級服務註冊與服務發現的應用服務遷移到應用級時，無法獲取介面與應用之間的對應關係，從而無法從註冊中心獲取實例列表資訊。因此，為了相容這種場景，Dubbo 在 Provider 端啟動時，會將介面與應用的映射關係存儲在元數據中心中。
  2. 為了讓註冊中心更專注於地址發現和推送能力，並減輕註冊中心的負擔，元數據中心承載了所有服務元數據、大量的介面/方法級配置信息等，無論是介面粒度還是應用粒度的服務發現和註冊，元數據中心都發揮著重要的作用。

如果您有以上兩個需求，則可以選擇部署元數據中心，並通過 Dubbo 配置整合元數據中心。

元數據中心不依賴於註冊中心和配置中心，用戶可以自由選擇是否整合和部署元數據中心，如下圖所示

centers-metadata

圖中沒有配置中心，意味著可能不需要全局管理配置的能力。圖中沒有註冊中心，意味著可能會採用 Dubbo 網格方案，或者不需要服務註冊，只接受直連模式的服務調用。

配置中心

配置中心與其他兩個中心不同，它與介面級別或應用級別無關，與介面沒有對應關係，只與配置數據有關。即使不部署註冊中心和元數據中心，配置中心也可以直接被 Dubbo 應用服務訪問。在整個部署架構中，整個集群中的實例（無論是提供者還是消費者）都將共享配置中心集群中的配置，如下圖所示

centers-config

圖中沒有註冊中心，意味著可能會採用 Dubbo 網格方案，或者不需要服務註冊，只接受直連模式的服務調用。

圖中沒有元數據中心，意味著消費者可以從提供者暴露的 MetadataService 獲取服務元數據，從而實現 RPC 調用

保障三大中心的高可用部署架構

雖然三大中心對於 Dubbo 應用服務來說已經不再是必須的，但在真實的生產環境中，一旦整合部署了三大中心，三大中心依然會面臨可用性問題。Dubbo 需要支持三大中心的高可用解決方案。Dubbo 支持多註冊中心、多數據中心、多配置中心，滿足同城多活、兩地三中心、異地多活等部署架構模式的需求。

Dubbo SDK 支持三大中心的多種模式。

  • 多註冊中心：Dubbo 支持多個註冊中心，即一個介面或一個應用可以註冊到多個註冊中心，例如 ZK 集群和 Nacos 集群，消費者也可以從多個註冊中心訂閱服務地址信息，以進行服務發現。通過支持多註冊中心，可以保證在其中一個註冊中心集群不可用時，可以切換到另一個註冊中心集群，從而保證服務能夠正常提供，服務調用能夠正常發起。這也能夠滿足註冊中心在部署上適應各種高可用部署架構模式。

  • 多配置中心：Dubbo 支持多個配置中心，保證在一個配置中心集群不可用時，可以切換到另一個配置中心集群，保證全局配置、路由規則等信息能夠從配置中心正常獲取。這也能夠滿足配置中心在部署上適應各種高可用部署架構模式。

  • 多數據中心：Dubbo 支持多數據中心部署，用於應對災難恢復等元數據中心集羣不可用的情況，此時可切換到另一個元數據中心集羣，以保證元數據中心可以正常提供相關服務元數據管理能力。

以註冊中心為例，下圖是多活部署架構示意圖

multiple-registry-deployment-architecture


上次修改時間：2023 年 1 月 2 日：增強英文文件 (#1798) (95a9f4f6c1c)