Dubbo3 服務(wù)發(fā)現(xiàn)

服務(wù)發(fā)現(xiàn)，即消費端自動發(fā)現(xiàn)服務(wù)地址列表的能力，是微服務(wù)框架需要具備的關(guān)鍵能力，借助于自動化的服務(wù)發(fā)現(xiàn)，微服務(wù)之間可以在無需感知對端部署位置與 IP 地址的情況下實現(xiàn)通信。

實現(xiàn)服務(wù)發(fā)現(xiàn)的方式有很多種，Dubbo 提供的是一種 Client-Based 的服務(wù)發(fā)現(xiàn)機(jī)制，通常還需要部署額外的第三方注冊中心組件來協(xié)調(diào)服務(wù)發(fā)現(xiàn)過程，如常用的 Nacos、Consul、Zookeeper 等，Dubbo 自身也提供了對多種注冊中心組件的對接，用戶可以靈活選擇。

Dubbo 基于消費端的自動服務(wù)發(fā)現(xiàn)能力，其基本工作原理如下圖：

服務(wù)發(fā)現(xiàn)的一個核心組件是注冊中心，Provider 注冊地址到注冊中心，Consumer 從注冊中心讀取和訂閱 Provider 地址列表。 因此，要啟用服務(wù)發(fā)現(xiàn)，需要為 Dubbo 增加注冊中心配置：

以 dubbo-spring-boot-starter 使用方式為例，增加 registry 配置

# application.properties
dubbo
 registry
  address: zookeeper://127.0.0.1:2181

What’s New in Dubbo3

就使用方式上而言，Dubbo3 與 Dubbo2 的服務(wù)發(fā)現(xiàn)配置是完全一致的，不需要改動什么內(nèi)容。但就實現(xiàn)原理上而言，Dubbo3 引入了全新的服務(wù)發(fā)現(xiàn)模型 - 應(yīng)用級服務(wù)發(fā)現(xiàn)， 在工作原理、數(shù)據(jù)格式上已完全不能兼容老版本服務(wù)發(fā)現(xiàn)。

• Dubbo3 應(yīng)用級服務(wù)發(fā)現(xiàn)，以應(yīng)用粒度組織地址數(shù)據(jù)
• Dubbo2 接口級服務(wù)發(fā)現(xiàn)，以接口粒度組織地址數(shù)據(jù)

Dubbo3 格式的 Provider 地址不能被 Dubbo2 的 Consumer 識別到，反之 Dubbo2 的消費者也不能訂閱到 Dubbo3 Provider。

• 對于新用戶，我們提倡直接啟用 Dubbo3 的默認(rèn)行為，即啟用應(yīng)用級服務(wù)發(fā)現(xiàn)，參見《應(yīng)用級服務(wù)發(fā)現(xiàn)》；
• 對于老用戶，要面臨如何平滑遷移到應(yīng)用級服務(wù)發(fā)現(xiàn)的問題，考慮到老用戶的規(guī)模如此之大，Dubbo3 默認(rèn)保持了接口級地址發(fā)現(xiàn)的行為，這保證了老用戶可以直接無感升級到 Dubbo3。 而如果要開啟應(yīng)用級服務(wù)發(fā)現(xiàn)，則需要通過配置顯示開啟（雙注冊、雙訂閱），具體開啟與平滑遷移過程，可參見《地址發(fā)現(xiàn)遷移指南》。

應(yīng)用級服務(wù)發(fā)現(xiàn)簡介

概括來說，Dubbo3 引入的應(yīng)用級服務(wù)發(fā)現(xiàn)主要有以下優(yōu)勢

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

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

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

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

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

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