解密 Dubbo 三大中心的部署架構

作者 | 華鐘明

01 部署架構

Dubbo 作為一個微服務架構，Dubbo SDK 與應用服務綁定在同一個程序内，它跟随着應用服務被部署在分布式叢集各個位置，為了在分布式環境下實作各個應用服務間的協作， Dubbo 定義了一些中心化元件，這包括：

• 注冊中心：協調 Consumer 與 Provider 之間的位址注冊與發現
• 配置中心：

• • 存儲 Dubbo 啟動階段的全局配置，保證配置的跨環境共享與全局一緻性
  • 負責服務治理規則（路由規則、動态配置等）的存儲與推送。

• 中繼資料中心。

• • 接收 Provider 上報的服務接口中繼資料，為 Admin 等控制台提供運維能力（如服務測試、接口文檔等）
  • 作為服務發現機制的補充，提供額外的接口/方法級别配置資訊的同步能力，相當于注冊中心的額外擴充

上圖完整的描述了 Dubbo 微服務元件與各個中心的互動過程。

但是以上三個中心并不是運作 Dubbo 的必要條件，使用者完全可以根據自身業務情況決定都不啟用，或者隻啟用其中一個，亦或者啟用多個，以達到簡化部署的目的。通常情況下，所有使用者都會以獨立的注冊中心 開始 Dubbo 服務開發，而配置中心、中繼資料中心則會在微服務演進的過程中逐漸的按需被引入進來。

1、注冊中心

注冊中心扮演着非常重要的角色，它承載着服務注冊和服務發現的職責。目前 Dubbo 支援以下兩種粒度的服務發現和服務注冊，分别是接口級别和應用級别，注冊中心可以按需進行部署：

• 在傳統的 Dubbo SDK 使用姿勢中，如果僅僅提供直連模式的 RPC 服務，不需要部署注冊中心。
• 無論是接口級别還是應用級别，如果需要 Dubbo SDK 自身來做服務注冊和服務發現，則可以選擇部署注冊中心，在 Dubbo 中內建對應的注冊中心。
• 在 Dubbo + Mesh 的場景下，随着 Dubbo 服務注冊能力的弱化，Dubbo 内的注冊中心也不再是必選項，其職責開始被控制面取代，如果采用了 Dubbo + Mesh 的部署方式，無論是 ThinSDK的mesh 方式還是 Proxyless的mesh 方式，都不再需要獨立部署注冊中心。

而注冊中心并不依賴于配置中心和中繼資料中心，如下圖所示：

該圖中沒有部署配置中心和中繼資料中中心，在 Dubbo 中會預設将注冊中心的執行個體同時作為配置中心和中繼資料中心，這是 Dubbo 的預設行為，如果确實不需要配置中心或者中繼資料中心的能力，可在配置中關閉，在注冊中心的配置中有兩個配置分别為 use-as-config-center 和 use-as-metadata-center，将配置置為 false 即可。

2、中繼資料中心

中繼資料中心在2.7.x版本開始支援，随着應用級别的服務注冊和服務發現在Dubbo中落地，中繼資料中心也變的越來越重要。在以下幾種情況下會需要部署中繼資料中心：

1. 對于一個原先采用老版本Dubbo搭建的應用服務，在遷移到Dubbo 3時，Dubbo 3 會需要一個中繼資料中心來維護RPC服務與應用的映射關系（即接口與應用的映射關系），因為如果采用了應用級别的服務發現和服務注冊，在注冊中心中将采用“應用 ——  執行個體清單”結構的資料組織形式，不再是以往的“接口 —— 執行個體清單”結構的資料組織形式，而以往用接口級别的服務注冊和服務發現的應用服務在遷移到應用級别時，得不到接口與應用之間的對應關系，進而無法從注冊中心得到執行個體清單資訊，是以Dubbo為了相容這種場景，在Provider端啟動時，會往中繼資料中心存儲接口與應用的映射關系。
2. 為了讓注冊中心更加聚焦與位址的發現和推送能力，減輕注冊中心的負擔，中繼資料中心承載了所有的服務中繼資料、大量接口/方法級别配置資訊等，無論是接口粒度還是應用粒度的服務發現和注冊，中繼資料中心都起到了重要的作用。

如果有以上兩種需求，都可以選擇部署中繼資料中心，并通過Dubbo的配置來內建該中繼資料中心。

中繼資料中心并不依賴于注冊中心和配置中心，使用者可以自由選擇是否內建和部署中繼資料中心，如下圖所示：

該圖中不配備配置中心，意味着可以不需要全局管理配置的能力。該圖中不配備注冊中心，意味着可能采用了 Dubbo mesh 的方案，也可能不需要進行服務注冊，僅僅接收直連模式的服務調用。

3、配置中心

配置中心與其他兩大中心不同，它無關于接口級還是應用級，它與接口并沒有對應關系，它僅僅與配置資料有關，即時沒有部署注冊中心和中繼資料中心，配置中心也能直接被接入到 Dubbo 應用服務中。在整個部署架構中，整個叢集内的執行個體（無論是 Provider 還是 Consumer）都将會共享該配置中心叢集中的配置，如下圖所示：

該圖中不配備注冊中心，意味着可能采用了 Dubbo mesh 的方案，也可能不需要進行服務注冊，僅僅接收直連模式的服務調用。

該圖中不配備中繼資料中心，意味着 Consumer 可以從 Provider 暴露的 MetadataService 擷取服務中繼資料，進而實作 RPC 調用。

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

雖然三大中心已不再是 Dubbo 應用服務所必須的，但是在真實的生産環境中，一旦已經內建并且部署了該三大中心，三大中心還是會面臨可用性問題，Dubbo 需要支援三大中心的高可用方案。在 Dubbo 中就支援多注冊中心、多中繼資料中心、多配置中心，來滿足同城多活、兩地三中心、異地多活等部署架構模式的需求。

Dubbo SDK 對三大中心都支援了 Multiple 模式。

• 多注冊中心：Dubbo 支援多注冊中心，即一個接口或者一個應用可以被注冊到多個注冊中心中，比如可以注冊到ZK叢集和Nacos叢集中，Consumer 也能夠從多個注冊中心中進行訂閱相關服務的位址資訊，進而進行服務發現。通過支援多注冊中心的方式來保證其中一個注冊中心叢集出現不可用時能夠切換到另一個注冊中心叢集，保證能夠正常提供服務以及發起服務調用。這也能夠滿足注冊中心在部署上适應各類高可用的部署架構模式。
• 多配置中心：Dubbo 支援多配置中心，來保證其中一個配置中心叢集出現不可用時能夠切換到另一個配置中心叢集，保證能夠正常從配置中心擷取全局的配置、路由規則等資訊。這也能夠滿足配置中心在部署上适應各類高可用的部署架構模式。
• 多中繼資料中心：Dubbo 支援多中繼資料中心：用于應對容災等情況導緻某個中繼資料中心叢集不可用，此時可以切換到另一個中繼資料中心叢集，保證中繼資料中心能夠正常提供有關服務中繼資料的管理能力。

拿注冊中心舉例，下面是一個多活場景的部署架構示意圖：

03 目前存在的問題

• 中繼資料中心的配置可以綁定某個注冊中心，通過 registry 配置，但是配置存在問題，待修複
• 之前提到的隻會采用一個中繼資料中心進行中繼資料的 Pub、Sub：

作者簡介：

華鐘明：Apache Dubbo Committer，《深入了解RPC原理與實作》書籍作者。該書更深入地介紹了 Dubbo 的核心架構及三大中心的重要性，感興趣的讀者可以閱讀書籍了解更多内容。也歡迎積極參與到 Dubbo 開源社群中，與作者一起共建 Dubbo。