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 實現可能有差異。
註冊中心
- Zookeeper
- Nacos
- Kubernetes
元數據中心
- Zookeeper
- Nacos
- Redis
配置中心
- Zookeeper
- Nacos
- Redis
- Apollo
Mesh
- 數據面 Envoy
- 控制面 Istio
接下來後面的文章會爲大家實戰一下如何進行配置和設置對應的註冊中心、配置中心和元數據中心。