Dubb3的應用級服務發現

Dubbo3提供了全新的應用級服務發現模型，該模型在設計與實現上區別于 Dubbo2 的接口級服務發現模型。

概括來說，Dubbo3 引入的應用級服務發現主要有以下優勢

適配云原生微服務變革。云原生時代的基礎設施能力不斷向上釋放，像 Kubernetes 等平臺都集成了微服務概念抽象，Dubbo3 的應用級服務發現是適配各種微服務體系的通用模型。提升性能與可伸縮性。支持超大規模集群的服務治理一直以來都是 Dubbo 的優勢，通過引入應用級服務發現模型，從本質上解決了注冊中心地址數據的存儲與推送壓力，相應的 Consumer 側的地址計算壓力也成數量級下降；集群規模也開始變得可預測、可評估（與 RPC 接口數量無關，只與實例部署規模相關）。

下圖是 Dubbo2 的服務發現模型：Provider 注冊服務地址，Consumer 經過注冊中心協調并發現服務地址，進而對地址發起通信，這是被絕大多數微服務框架的經典服務發現流程。而 Dubbo2 的特殊之處在于，它把 “RPC 接口”的信息也融合在了地址發現過程中，而這部分信息往往是和具體的業務定義密切相關的。

【資料圖】

而在接入云原生基礎設施后，基礎設施融入了微服務概念的抽象，容器化微服務被編排、調度的過程即完成了在基礎設施層面的注冊。如下圖所示，基礎設施既承擔了注冊中心的職責，又完成了服務注冊的動作，而 “RPC 接口”這部分信息，由于與具體的業務相關，不可能也不適合被基礎設施托管。

在這樣的場景下，對 Dubbo3 的服務注冊發現機制提出了兩個要求： Dubbo3 需要在原有服務發現流程中抽象出通用的、與業務邏輯無關的地址映射模型，并確保這部分模型足夠合理，以支持將地址的注冊行為和存儲委托給下層基礎設施 Dubbo3 特有的業務接口同步機制，是 Dubbo3 需要保留的優勢，需要在 Dubbo3 中定義的新地址模型之上，通過框架內的自有機制予以解決。

這樣設計的全新的服務發現模型，在架構兼容性、可伸縮性上都給 Dubbo3 帶來了更大的優勢。

在架構兼容性上，如上文所述，Dubbo3 復用下層基礎設施的服務抽象能力成為了可能；另一方面，如 Spring Cloud 等業界其它微服務解決方案也沿用這種模型， 在打通了地址發現之后，使得用戶探索用 Dubbo 連接異構的微服務體系成為了一種可能。

Dubbo3 服務發現模型更適合構建可伸縮的服務體系，這點要如何理解？ 這里先舉個簡單的例子，來直觀的對比 Dubbo2 與 Dubbo3 在地址發現流程上的數據流量變化：假設一個微服務應用定義了 100 個接口（Dubbo 中的服務）， 則需要往注冊中心中注冊 100 個服務，如果這個應用被部署在了 100 臺機器上，那這 100 個服務總共會產生 100 * 100 = 10000 個虛擬節點；而同樣的應用， 對于 Dubbo3 來說，新的注冊發現模型只需要 1 個服務（只和應用有關和接口無關）， 只注冊和機器實例數相等的 1 * 100 = 100 個虛擬節點到注冊中心。 在這個簡單的示例中，Dubbo 所注冊的地址數量下降到了原來的 1 / 100，對于注冊中心、訂閱方的存儲壓力都是一個極大的釋放。更重要的是， 地址發現容量徹底與業務 RPC 定義解耦開來，整個集群的容量評估對運維來說將變得更加透明：部署多少臺機器就會有多大負載，不會像 Dubbo2 一樣， 因為業務 RPC 重構就會影響到整個集群服務發現的穩定性。

Dubbo3部署架構

本文主要側重介紹在云原生背景下的部署架構，主要體現在基礎設施（Kubernetes、Service Mesh等）會承擔更多的職責，三中心化體系結構，如：注冊中心、元數據中心、配置中心等的職責被集成，促使架構變得更加優秀、資源優化的更加徹底。通過分析這些中心化的組件能讓我們更容易理解Dubbo3對應云原生模式下的工作原理。

從上面的圖中，我們可以看出來，整體的的Dubbo的Rpc框架中，除了對應的Consumer消費端、Provider服務提供端，Registry注冊中心這些之前dubbo中已經定義的中心化組件之外，還多出了config-center、metadata這兩個中心。

Dubbo3的三中心化體系

作為一個微服務框架，Dubbo SDK跟隨著微服務組件被部署在分布式集群各個位置，為了在分布式環境下實現各個微服務組件間的協作， Dubbo3擴展了一些中心化組件，這包括：

注冊中心協調Consumer消費者與Provider服務提供者之間的地址注冊與發現。配置中心存儲Dubbo啟動階段的全局配置，保證配置的跨環境共享與全局一致性負責服務治理規則（路由規則、動態配置等）的存儲與推送。元數據中心接收Provider服務端上報的服務接口元數據，為Admin等控制臺提供運維能力（如服務測試、接口文檔等）作為服務發現機制的補充，提供額外的接口/方法級別配置信息的同步能力，相當于注冊中心的額外擴展。

注意：以上三個中心體系并不是運行Dubbo的必要條件，用戶完全可以根據自身業務情況決定只啟用其中一個或多個（甚至不需要任何中心，直連模式，當然生產不推薦），以達到簡化部署的目的。

接下來我們將會針對于這三個中心分別給大家去詳細講解說明一下。

注冊中心

大多數情況下，我們基本都會以獨立的注冊中心以開始Dubbo服務開發，而配置中心、元數據中心則會在微服務演進的過程中逐步的按需被引入進來。

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

直連模式

在最初的Dubbo SDK使用過程中，如果僅僅提供直連模式的RPC服務，不需要部署注冊中心。

注冊模式

無論是接口級別還是應用級別，如果需要Dubbo SDK自身來做服務注冊和服務發現，則可以選擇部署注冊中心，在Dubbo中集成對應的注冊中心。

Mesh模式

在Dubbo + Mesh 的場景下，隨著Dubbo服務注冊能力的弱化，Dubbo內的注冊中心也不再是必選項，其職責開始被控制面取代，如果采用了Dubbo + Mesh的部署方式，無論是ThinSDK的mesh方式還是Proxyless的mesh方式，都不再需要獨立部署注冊中心。

注冊中心不依賴于配置中心和元數據中心

對于組成而言注冊中心不完全依賴于配置中心和元數據中心，如下圖所示。

沒有部署配置中心和元數據中心，在Dubbo中會默認將注冊中心的實例同時作為配置中心和元數據中心，這是Dubbo的默認行為，如果確實不需要配置中心或者元數據中心的能力，可在配置中關閉，在注冊中心的配置中有兩個配置分別為use-as-config-center和use-as-metadata-center，將配置置為false即可。

元數據中心

元數據中心并不是在Dubbo3才推出的，而是在2.7.x版本就開始支持，隨著應用級別的服務注冊和服務發現在Dubbo中落地，元數據中心也變的越來越重要，如下圖所示。

上面圖中不配備配置中心，意味著可以不需要全局管理配置的能力。該圖中不配備注冊中心，意味著可能采用了Dubbo mesh的方案，也可能不需要進行服務注冊，僅僅接收直連模式的服務調用。在以下幾種情況下會需要部署元數據中心：

（場景1）老版本Dubbo遷移到新版本Dubbo3的場景

對于一個原先采用老版本Dubbo搭建的應用服務，在遷移到Dubbo3時，Dubbo3會需要一個元數據中心來維護RPC服務與應用的映射關系（即接口與應用的映射關系）。

應用級別的服務發現和服務注冊

以往的“接口 —— 實例列表”結構的數據組織形式，如下圖所示。

如果采用了應用級別的服務發現和服務注冊，在注冊中心中將采用”應用 —— 實例列表”結構的數據組織形式，如下圖所示。

以往用接口級別的服務注冊和服務發現的應用服務在遷移到應用級別時，得不到接口與應用之間的對應關系，從而無法從注冊中心得到實例列表信息，所以Dubbo為了兼容這種場景，在Provider端啟動時，會往元數據中心存儲接口與應用的映射關系。

（場景2）讓注冊中心更加聚焦于地址的發現和推送能力

為了讓注冊中心更加聚焦于地址的發現和推送能力，減輕注冊中心的負擔，元數據中心承載了所有的服務元數據、大量接口/方法級別配置信息等，無論是接口粒度還是應用粒度的服務發現和注冊，元數據中心都起到了重要的作用。

如果有以上兩種需求，都可以選擇部署元數據中心，并通過Dubbo的配置來集成該元數據中心。元數據中心并不依賴于注冊中心和配置中心，用戶可以自由選擇是否集成和部署元數據中心，如下圖所示：

可以看到消費者會元數據中心拉取到接口和應用服務的關系。配合著注冊中心拉取到應用與服務實例之間的關系，兩者組成了更加優雅地格式和優化了存儲空間。

注冊中心-存儲：應用名稱->接口服務實例地址元數據中心-存儲：應用名稱->接口信息+參數信息

兩者可以直接整合為應用名稱->接口服務實例地址->接口信息

配置中心

配置中心與其他兩大中心不同，它無關于接口級還是應用級，它與接口并沒有對應關系，它僅僅與配置數據有關，即使沒有部署注冊中心和元數據中心，配置中心也能直接被接入到Dubbo應用服務中。

在整個部署架構中，整個集群內的實例（無論是Provider還是Consumer）都將會共享該配置中心集群中的配置，如下圖所示

該圖中不配備注冊中心，意味著可能采用了Dubbo mesh的方案，也可能不需要進行服務注冊，僅僅接收直連模式的服務調用。該圖中不配備元數據中心，意味著Consumer可以從Provider暴露的MetadataService獲取服務元數據，從而實現RPC調用。

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

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

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

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

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

支持的組件與部署架構

Dubbo 實現普遍支持以下產品或部署架構，具體多語言 SDK 實現可能有差異。

注冊中心

ZookeeperNacosKubernetes

元數據中心

ZookeeperNacosRedis

配置中心

ZookeeperNacosRedisApollo

Mesh

數據面 Envoy控制面 Istio

接下來后面的文章會為大家實戰一下如何進行配置和設置對應的注冊中心、配置中心和元數據中心。