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

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

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

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

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

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

Dubbo3 格式的 Provider 地址不能被 Dubbo2 的 Consumer 識(shí)別到，反之 Dubbo2 的消費(fèi)者也不能訂閱到 Dubbo3 Provider。

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

應(yīng)用級(jí)服務(wù)發(fā)現(xiàn)簡(jiǎ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ì)，通過引入應(yīng)用級(jí)服務(wù)發(fā)現(xiàn)模型，從本質(zhì)上解決了注冊(cè)中心地址數(shù)據(jù)的存儲(chǔ)與推送壓力，相應(yīng)的 Consumer 側(cè)的地址計(jì)算壓力也成數(shù)量級(jí)下降；集群規(guī)模也開始變得可預(yù)測(cè)、可評(píng)估（與 RPC 接口數(shù)量無(wú)關(guān)，只與實(shí)例部署規(guī)模相關(guān)）。

下圖是 Dubbo2 的服務(wù)發(fā)現(xiàn)模型：Provider 注冊(cè)服務(wù)地址，Consumer 經(jīng)過注冊(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)過程中，而這部分信息往往是和具體的業(yè)務(wù)定義密切相關(guān)的。

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

在這樣的場(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 中定義的新地址模型之上，通過框架內(nèi)的自有機(jī)制予以解決。

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

在架構(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 定義解耦開來(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)定性。