Dubb3的應(yīng)用級(jí)服務(wù)發(fā)現(xiàn)

Dubbo3提供了全新的應(yīng)用級(jí)服務(wù)發(fā)現(xiàn)模型，該模型在設(shè)計(jì)與實(shí)現(xiàn)上區(qū)別于 Dubbo2 的接口級(jí)服務(wù)發(fā)現(xiàn)模型厂抽。

概括來(lái)說(shuō)需频，Dubbo3 引入的應(yīng)用級(jí)服務(wù)發(fā)現(xiàn)主要有以下優(yōu)勢(shì)

• 適配云原生微服務(wù)變革。云原生時(shí)代的基礎(chǔ)設(shè)施能力不斷向上釋放筷凤，像 Kubernetes 等平臺(tái)都集成了微服務(wù)概念抽象昭殉，Dubbo3 的應(yīng)用級(jí)服務(wù)發(fā)現(xiàn)是適配各種微服務(wù)體系的通用模型。
• 提升性能與可伸縮性藐守。支持超大規(guī)模集群的服務(wù)治理一直以來(lái)都是 Dubbo 的優(yōu)勢(shì)挪丢，通過(guò)引入應(yīng)用級(jí)服務(wù)發(fā)現(xiàn)模型，從本質(zhì)上解決了注冊(cè)中心地址數(shù)據(jù)的存儲(chǔ)與推送壓力卢厂，相應(yīng)的 Consumer 側(cè)的地址計(jì)算壓力也成數(shù)量級(jí)下降乾蓬；集群規(guī)模也開(kāi)始變得可預(yù)測(cè)、可評(píng)估（與 RPC 接口數(shù)量無(wú)關(guān)慎恒，只與實(shí)例部署規(guī)模相關(guān)）巢块。

下圖是 Dubbo2 的服務(wù)發(fā)現(xiàn)模型：Provider 注冊(cè)服務(wù)地址，Consumer 經(jīng)過(guò)注冊(cè)中心協(xié)調(diào)并發(fā)現(xiàn)服務(wù)地址巧号，進(jìn)而對(duì)地址發(fā)起通信，這是被絕大多數(shù)微服務(wù)框架的經(jīng)典服務(wù)發(fā)現(xiàn)流程姥闭。而 Dubbo2 的特殊之處在于丹鸿，它把 “RPC 接口”的信息也融合在了地址發(fā)現(xiàn)過(guò)程中，而這部分信息往往是和具體的業(yè)務(wù)定義密切相關(guān)的棚品。

image

而在接入云原生基礎(chǔ)設(shè)施后靠欢，基礎(chǔ)設(shè)施融入了微服務(wù)概念的抽象，容器化微服務(wù)被編排铜跑、調(diào)度的過(guò)程即完成了在基礎(chǔ)設(shè)施層面的注冊(cè)门怪。如下圖所示，基礎(chǔ)設(shè)施既承擔(dān)了注冊(cè)中心的職責(zé)锅纺，又完成了服務(wù)注冊(cè)的動(dòng)作掷空，而 “RPC 接口”這部分信息，由于與具體的業(yè)務(wù)相關(guān)，不可能也不適合被基礎(chǔ)設(shè)施托管坦弟。

image

在這樣的場(chǎng)景下护锤，對(duì) Dubbo3 的服務(wù)注冊(cè)發(fā)現(xiàn)機(jī)制提出了兩個(gè)要求： Dubbo3 需要在原有服務(wù)發(fā)現(xiàn)流程中抽象出通用的、與業(yè)務(wù)邏輯無(wú)關(guān)的地址映射模型酿傍，并確保這部分模型足夠合理烙懦，以支持將地址的注冊(cè)行為和存儲(chǔ)委托給下層基礎(chǔ)設(shè)施 Dubbo3 特有的業(yè)務(wù)接口同步機(jī)制，是 Dubbo3 需要保留的優(yōu)勢(shì)赤炒，需要在 Dubbo3 中定義的新地址模型之上血久，通過(guò)框架內(nèi)的自有機(jī)制予以解決。

這樣設(shè)計(jì)的全新的服務(wù)發(fā)現(xiàn)模型塔逃，在架構(gòu)兼容性密强、可伸縮性上都給 Dubbo3 帶來(lái)了更大的優(yōu)勢(shì)。

image

在架構(gòu)兼容性上癣朗，如上文所述拾因，Dubbo3 復(fù)用下層基礎(chǔ)設(shè)施的服務(wù)抽象能力成為了可能；另一方面旷余，如 Spring Cloud 等業(yè)界其它微服務(wù)解決方案也沿用這種模型绢记， 在打通了地址發(fā)現(xiàn)之后，使得用戶探索用 Dubbo 連接異構(gòu)的微服務(wù)體系成為了一種可能正卧。

Dubbo3 服務(wù)發(fā)現(xiàn)模型更適合構(gòu)建可伸縮的服務(wù)體系蠢熄，這點(diǎn)要如何理解？ 這里先舉個(gè)簡(jiǎn)單的例子炉旷，來(lái)直觀的對(duì)比 Dubbo2 與 Dubbo3 在地址發(fā)現(xiàn)流程上的數(shù)據(jù)流量變化：假設(shè)一個(gè)微服務(wù)應(yīng)用定義了 100 個(gè)接口（Dubbo 中的服務(wù)）签孔， 則需要往注冊(cè)中心中注冊(cè) 100 個(gè)服務(wù)，如果這個(gè)應(yīng)用被部署在了 100 臺(tái)機(jī)器上窘行，那這 100 個(gè)服務(wù)總共會(huì)產(chǎn)生 100 * 100 = 10000 個(gè)虛擬節(jié)點(diǎn)饥追；而同樣的應(yīng)用， 對(duì)于 Dubbo3 來(lái)說(shuō)罐盔，新的注冊(cè)發(fā)現(xiàn)模型只需要 1 個(gè)服務(wù)（只和應(yīng)用有關(guān)和接口無(wú)關(guān)）但绕， 只注冊(cè)和機(jī)器實(shí)例數(shù)相等的 1 * 100 = 100 個(gè)虛擬節(jié)點(diǎn)到注冊(cè)中心。 在這個(gè)簡(jiǎn)單的示例中惶看，Dubbo 所注冊(cè)的地址數(shù)量下降到了原來(lái)的 1 / 100捏顺，對(duì)于注冊(cè)中心、訂閱方的存儲(chǔ)壓力都是一個(gè)極大的釋放纬黎。更重要的是幅骄， 地址發(fā)現(xiàn)容量徹底與業(yè)務(wù) RPC 定義解耦開(kāi)來(lái)，整個(gè)集群的容量評(píng)估對(duì)運(yùn)維來(lái)說(shuō)將變得更加透明：部署多少臺(tái)機(jī)器就會(huì)有多大負(fù)載本今，不會(huì)像 Dubbo2 一樣拆座， 因?yàn)闃I(yè)務(wù) RPC 重構(gòu)就會(huì)影響到整個(gè)集群服務(wù)發(fā)現(xiàn)的穩(wěn)定性主巍。

Dubbo3部署架構(gòu)

本文主要側(cè)重介紹在云原生背景下的部署架構(gòu)，主要體現(xiàn)在基礎(chǔ)設(shè)施（Kubernetes懂拾、Service Mesh等）會(huì)承擔(dān)更多的職責(zé)煤禽，三中心化體系結(jié)構(gòu)，如：注冊(cè)中心岖赋、元數(shù)據(jù)中心檬果、配置中心等的職責(zé)被集成，促使架構(gòu)變得更加優(yōu)秀唐断、資源優(yōu)化的更加徹底选脊。通過(guò)分析這些中心化的組件能讓我們更容易理解Dubbo3對(duì)應(yīng)云原生模式下的工作原理。

image

從上面的圖中脸甘，我們可以看出來(lái)恳啥，整體的的Dubbo的Rpc框架中，除了對(duì)應(yīng)的Consumer消費(fèi)端丹诀、Provider服務(wù)提供端钝的，Registry注冊(cè)中心這些之前dubbo中已經(jīng)定義的中心化組件之外，還多出了config-center铆遭、metadata這兩個(gè)中心硝桩。

Dubbo3的三中心化體系

作為一個(gè)微服務(wù)框架，Dubbo SDK跟隨著微服務(wù)組件被部署在分布式集群各個(gè)位置枚荣，為了在分布式環(huán)境下實(shí)現(xiàn)各個(gè)微服務(wù)組件間的協(xié)作碗脊， Dubbo3擴(kuò)展了一些中心化組件，這包括：

• 注冊(cè)中心
  • 協(xié)調(diào)Consumer消費(fèi)者與Provider服務(wù)提供者之間的地址注冊(cè)與發(fā)現(xiàn)橄妆。
• 配置中心
  • 存儲(chǔ)Dubbo啟動(dòng)階段的全局配置衙伶，保證配置的跨環(huán)境共享與全局一致性
  • 負(fù)責(zé)服務(wù)治理規(guī)則（路由規(guī)則、動(dòng)態(tài)配置等）的存儲(chǔ)與推送害碾。
• 元數(shù)據(jù)中心
  • 接收Provider服務(wù)端上報(bào)的服務(wù)接口元數(shù)據(jù)矢劲，為Admin等控制臺(tái)提供運(yùn)維能力（如服務(wù)測(cè)試、接口文檔等）
  • 作為服務(wù)發(fā)現(xiàn)機(jī)制的補(bǔ)充慌随，提供額外的接口/方法級(jí)別配置信息的同步能力卧须，相當(dāng)于注冊(cè)中心的額外擴(kuò)展。

注意：以上三個(gè)中心體系并不是運(yùn)行Dubbo的必要條件儒陨，用戶完全可以根據(jù)自身業(yè)務(wù)情況決定只啟用其中一個(gè)或多個(gè)（甚至不需要任何中心，直連模式笋籽，當(dāng)然生產(chǎn)不推薦）蹦漠，以達(dá)到簡(jiǎn)化部署的目的。

接下來(lái)我們將會(huì)針對(duì)于這三個(gè)中心分別給大家去詳細(xì)講解說(shuō)明一下车海。

注冊(cè)中心

大多數(shù)情況下笛园，我們基本都會(huì)以獨(dú)立的注冊(cè)中心以開(kāi)始Dubbo服務(wù)開(kāi)發(fā)隘击，而配置中心、元數(shù)據(jù)中心則會(huì)在微服務(wù)演進(jìn)的過(guò)程中逐步的按需被引入進(jìn)來(lái)研铆。

image

注冊(cè)中心扮演著非常重要的角色埋同，它承載著服務(wù)注冊(cè)和服務(wù)發(fā)現(xiàn)的職責(zé)。目前Dubbo支持以下兩種粒度的服務(wù)發(fā)現(xiàn)和服務(wù)注冊(cè)棵红，分別是接口級(jí)別和應(yīng)用級(jí)別凶赁，注冊(cè)中心可以按需進(jìn)行部署：

直連模式

在最初的Dubbo SDK使用過(guò)程中，如果僅僅提供直連模式的RPC服務(wù)逆甜，不需要部署注冊(cè)中心虱肄。

注冊(cè)模式

無(wú)論是接口級(jí)別還是應(yīng)用級(jí)別，如果需要Dubbo SDK自身來(lái)做服務(wù)注冊(cè)和服務(wù)發(fā)現(xiàn)交煞，則可以選擇部署注冊(cè)中心咏窿，在Dubbo中集成對(duì)應(yīng)的注冊(cè)中心。

Mesh模式

在Dubbo + Mesh 的場(chǎng)景下素征，隨著Dubbo服務(wù)注冊(cè)能力的弱化集嵌，Dubbo內(nèi)的注冊(cè)中心也不再是必選項(xiàng)，其職責(zé)開(kāi)始被控制面取代御毅，如果采用了Dubbo + Mesh的部署方式根欧，無(wú)論是ThinSDK的mesh方式還是Proxyless的mesh方式，都不再需要獨(dú)立部署注冊(cè)中心亚享。

注冊(cè)中心不依賴于配置中心和元數(shù)據(jù)中心

對(duì)于組成而言注冊(cè)中心不完全依賴于配置中心和元數(shù)據(jù)中心咽块，如下圖所示。

image

沒(méi)有部署配置中心和元數(shù)據(jù)中心欺税，在Dubbo中會(huì)默認(rèn)將注冊(cè)中心的實(shí)例同時(shí)作為配置中心和元數(shù)據(jù)中心侈沪，這是Dubbo的默認(rèn)行為，如果確實(shí)不需要配置中心或者元數(shù)據(jù)中心的能力晚凿，可在配置中關(guān)閉亭罪，在注冊(cè)中心的配置中有兩個(gè)配置分別為use-as-config-center和use-as-metadata-center，將配置置為false即可歼秽。

元數(shù)據(jù)中心

元數(shù)據(jù)中心并不是在Dubbo3才推出的应役，而是在2.7.x版本就開(kāi)始支持，隨著應(yīng)用級(jí)別的服務(wù)注冊(cè)和服務(wù)發(fā)現(xiàn)在Dubbo中落地燥筷，元數(shù)據(jù)中心也變的越來(lái)越重要箩祥，如下圖所示。

image

上面圖中不配備配置中心肆氓，意味著可以不需要全局管理配置的能力袍祖。該圖中不配備注冊(cè)中心，意味著可能采用了Dubbo mesh的方案谢揪，也可能不需要進(jìn)行服務(wù)注冊(cè)蕉陋，僅僅接收直連模式的服務(wù)調(diào)用捐凭。在以下幾種情況下會(huì)需要部署元數(shù)據(jù)中心：

（場(chǎng)景1）老版本Dubbo遷移到新版本Dubbo3的場(chǎng)景

對(duì)于一個(gè)原先采用老版本Dubbo搭建的應(yīng)用服務(wù)，在遷移到Dubbo3時(shí)凳鬓，Dubbo3會(huì)需要一個(gè)元數(shù)據(jù)中心來(lái)維護(hù)RPC服務(wù)與應(yīng)用的映射關(guān)系（即接口與應(yīng)用的映射關(guān)系）茁肠。

應(yīng)用級(jí)別的服務(wù)發(fā)現(xiàn)和服務(wù)注冊(cè)

以往的“接口 —— 實(shí)例列表”結(jié)構(gòu)的數(shù)據(jù)組織形式，如下圖所示缩举。

image

如果采用了應(yīng)用級(jí)別的服務(wù)發(fā)現(xiàn)和服務(wù)注冊(cè)垦梆，在注冊(cè)中心中將采用”應(yīng)用 —— 實(shí)例列表”結(jié)構(gòu)的數(shù)據(jù)組織形式，如下圖所示蚁孔。

image

以往用接口級(jí)別的服務(wù)注冊(cè)和服務(wù)發(fā)現(xiàn)的應(yīng)用服務(wù)在遷移到應(yīng)用級(jí)別時(shí)奶赔，得不到接口與應(yīng)用之間的對(duì)應(yīng)關(guān)系，從而無(wú)法從注冊(cè)中心得到實(shí)例列表信息杠氢，所以Dubbo為了兼容這種場(chǎng)景站刑，在Provider端啟動(dòng)時(shí)，會(huì)往元數(shù)據(jù)中心存儲(chǔ)接口與應(yīng)用的映射關(guān)系鼻百。

（場(chǎng)景2）讓注冊(cè)中心更加聚焦于地址的發(fā)現(xiàn)和推送能力

為了讓注冊(cè)中心更加聚焦于地址的發(fā)現(xiàn)和推送能力绞旅，減輕注冊(cè)中心的負(fù)擔(dān)，元數(shù)據(jù)中心承載了所有的服務(wù)元數(shù)據(jù)温艇、大量接口/方法級(jí)別配置信息等因悲，無(wú)論是接口粒度還是應(yīng)用粒度的服務(wù)發(fā)現(xiàn)和注冊(cè)，元數(shù)據(jù)中心都起到了重要的作用勺爱。

如果有以上兩種需求晃琳，都可以選擇部署元數(shù)據(jù)中心，并通過(guò)Dubbo的配置來(lái)集成該元數(shù)據(jù)中心琐鲁。元數(shù)據(jù)中心并不依賴于注冊(cè)中心和配置中心卫旱，用戶可以自由選擇是否集成和部署元數(shù)據(jù)中心，如下圖所示：

image

可以看到消費(fèi)者會(huì)元數(shù)據(jù)中心拉取到接口和應(yīng)用服務(wù)的關(guān)系围段。配合著注冊(cè)中心拉取到應(yīng)用與服務(wù)實(shí)例之間的關(guān)系顾翼，兩者組成了更加優(yōu)雅地格式和優(yōu)化了存儲(chǔ)空間。

image

• 注冊(cè)中心-存儲(chǔ)：應(yīng)用名稱->接口服務(wù)實(shí)例地址
• 元數(shù)據(jù)中心-存儲(chǔ)：應(yīng)用名稱->接口信息+參數(shù)信息

兩者可以直接整合為應(yīng)用名稱->接口服務(wù)實(shí)例地址->接口信息

配置中心

配置中心與其他兩大中心不同奈泪，它無(wú)關(guān)于接口級(jí)還是應(yīng)用級(jí)适贸，它與接口并沒(méi)有對(duì)應(yīng)關(guān)系，它僅僅與配置數(shù)據(jù)有關(guān)涝桅，即使沒(méi)有部署注冊(cè)中心和元數(shù)據(jù)中心拜姿，配置中心也能直接被接入到Dubbo應(yīng)用服務(wù)中。

在整個(gè)部署架構(gòu)中冯遂，整個(gè)集群內(nèi)的實(shí)例（無(wú)論是Provider還是Consumer）都將會(huì)共享該配置中心集群中的配置砾隅，如下圖所示

image

• 該圖中不配備注冊(cè)中心，意味著可能采用了Dubbo mesh的方案债蜜，也可能不需要進(jìn)行服務(wù)注冊(cè)晴埂，僅僅接收直連模式的服務(wù)調(diào)用。

• 該圖中不配備元數(shù)據(jù)中心寻定，意味著Consumer可以從Provider暴露的MetadataService獲取服務(wù)元數(shù)據(jù)儒洛，從而實(shí)現(xiàn)RPC調(diào)用。

保證三大中心高可用的部署架構(gòu)

雖然三大中心已不再是Dubbo應(yīng)用服務(wù)所必須的狼速，但是在真實(shí)的生產(chǎn)環(huán)境中琅锻，一旦已經(jīng)集成并且部署了該三大中心，三大中心還是會(huì)面臨可用性問(wèn)題向胡，Dubbo需要支持三大中心的高可用方案恼蓬。在Dubbo中就支持多注冊(cè)中心、多元數(shù)據(jù)中心僵芹、多配置中心处硬，來(lái)滿足同城多活、兩地三中心拇派、異地多活等部署架構(gòu)模式的需求荷辕。

Dubbo SDK對(duì)三大中心都支持了Multiple模式。

• 多注冊(cè)中心：Dubbo 支持多注冊(cè)中心件豌，即一個(gè)接口或者一個(gè)應(yīng)用可以被注冊(cè)到多個(gè)注冊(cè)中心中疮方，比如可以注冊(cè)到ZK集群和Nacos集群中，Consumer也能夠從多個(gè)注冊(cè)中心中進(jìn)行訂閱相關(guān)服務(wù)的地址信息茧彤，從而進(jìn)行服務(wù)發(fā)現(xiàn)骡显。通過(guò)支持多注冊(cè)中心的方式來(lái)保證其中一個(gè)注冊(cè)中心集群出現(xiàn)不可用時(shí)能夠切換到另一個(gè)注冊(cè)中心集群，保證能夠正常提供服務(wù)以及發(fā)起服務(wù)調(diào)用曾掂。這也能夠滿足注冊(cè)中心在部署上適應(yīng)各類(lèi)高可用的部署架構(gòu)模式惫谤。

• 多配置中心：Dubbo支持多配置中心，來(lái)保證其中一個(gè)配置中心集群出現(xiàn)不可用時(shí)能夠切換到另一個(gè)配置中心集群遭殉，保證能夠正常從配置中心獲取全局的配置石挂、路由規(guī)則等信息。這也能夠滿足配置中心在部署上適應(yīng)各類(lèi)高可用的部署架構(gòu)模式险污。

• 多元數(shù)據(jù)中心：Dubbo 支持多元數(shù)據(jù)中心：用于應(yīng)對(duì)容災(zāi)等情況導(dǎo)致某個(gè)元數(shù)據(jù)中心集群不可用痹愚，此時(shí)可以切換到另一個(gè)元數(shù)據(jù)中心集群，保證元數(shù)據(jù)中心能夠正常提供有關(guān)服務(wù)元數(shù)據(jù)的管理能力蛔糯。

拿注冊(cè)中心舉例拯腮，下面是一個(gè)多活場(chǎng)景的部署架構(gòu)示意圖：

image

支持的組件與部署架構(gòu)

Dubbo 實(shí)現(xiàn)普遍支持以下產(chǎn)品或部署架構(gòu)，具體多語(yǔ)言 SDK 實(shí)現(xiàn)可能有差異蚁飒。

注冊(cè)中心

• Zookeeper
• Nacos
• Kubernetes

元數(shù)據(jù)中心

• Zookeeper
• Nacos
• Redis

配置中心

• Zookeeper
• Nacos
• Redis
• Apollo

Mesh

• 數(shù)據(jù)面 Envoy
• 控制面 Istio

接下來(lái)后面的文章會(huì)為大家實(shí)戰(zhàn)一下如何進(jìn)行配置和設(shè)置對(duì)應(yīng)的注冊(cè)中心动壤、配置中心和元數(shù)據(jù)中心。