服務發現
服務發現，即消費者自動發現服務地址列表的能力，是微服務框架需要具備的關鍵能力。藉助自動化的服務發現，微服務可以無需知道對端部署位置與 IP 地址即可實現通訊。
實現方式
實現服務發現的方式有很多種，Dubbo 提供了基於客戶端的服務發現機制。通常需要額外部署第三方註冊中心元件來協調服務發現過程，例如常用的 Nacos、Consul、ZooKeeper 等。Dubbo 本身也提供了對接各種註冊中心元件的能力，使用者可以彈性選擇。
工作原理
Dubbo 基於消費者端的自動服務發現能力，其基本工作原理如下：
服務發現的核心元件是註冊中心，Provider 將地址註冊到註冊中心，Consumer 從註冊中心讀取並訂閱 Provider 的地址列表。因此，要啟用服務發現，需要在 Dubbo 中加入註冊中心的配置。
以 dubbo-spring-boot-starter 為例，加入註冊中心配置：
# application.properties
dubbo
registry
address: zookeeper://127.0.0.1:2181
應用級服務發現介紹
綜上所述，Dubbo3 引入的應用級服務發現主要有以下優勢：
- 適應雲原生微服務變革。雲原生時代的基礎設施能力不斷向上釋放， Kubernetes 等平台整合了微服務的概念抽象， Dubbo3 的應用級服務發現是適配各種微服務體系的通用模型。
- 提升效能與可擴展性。支援超大規模叢集的服務治理一直是 Dubbo 的優勢，引入應用級服務發現模型後，從根本上解決了註冊中心地址資料的儲存與推送壓力，消費者端的對應地址計算壓力也隨之降低數量級；叢集規模也變得可預期，可評估（與 RPC 介面數量無關，僅與執行個體部署規模相關）。
下圖展現了 Dubbo2 的服務發現模型： Provider 註冊服務地址， Consumer 與註冊中心協調並發現服務地址，之後發起對地址的通訊。這是大多數微服務框架採用的經典服務發現流程。 Dubbo2 的特殊之處在於，它還將“ RPC 介面” 的資訊整合到了地址發現流程之中，而這部分資訊往往與具體的業務定義強相關。
接入雲原生基礎設施後，基礎設施整合了微服務概念的抽象，容器化的微服務的編排、調度流程由基礎設施層面完成註冊。如圖所示，基礎設施不僅承擔了註冊中心職責，也一併完成了服務註冊動作，“ RPC 介面” 的資訊因為與具體業務相關，則不可能也不適合由基礎設施托管。
在這樣的場景下，對 Dubbo3 的服務註冊發現機制提出了兩點要求： Dubbo3 需要在原服務發現流程中抽象出一套通用的、與業務邏輯無關的地址對映模型，並保證這套模型足夠合理，能夠支援將註冊行為與地址的儲存託管於底層基礎設施 Dubbo3 特有的業務介面同步機制是 Dubbo3 需要保留的優勢，需要在 Dubbo3 定義的新的地址模型之上，通過自身機制在框架內解決。
如此設計的全新服務發現模型，為 Dubbo3 帶來架構相容性與可擴展性上的更大優勢。
在架構相容性方面，如上文所述， Dubbo3 有可能複用底層基礎設施的服務抽象能力；另一方面，業界其他的微服務解決方案如 Spring Cloud 也遵循此模型， Dubbo3 在地址發現模型拉通後，使用者探索使用 Dubbo 對接異構微服務體系成為可能。
Dubbo3 的服務發現模型更適合構建可擴展的服務系統。如何理解這一點？以下是一個簡單的例子，可以直觀地比較 Dubbo2 和 Dubbo3 在地址發現過程中的數據流變化：假設一個微服務應用定義了 100 個接口（Dubbo 中的服務），您需要在註冊中心註冊 100 個服務。如果這個應用部署在 100 台機器上，那麼這 100 個服務將會產生總共 100 * 100 = 10000 個虛擬節點；而同樣的應用，對於 Dubbo3 來說，新的註冊發現模型只需要 1 個服務（僅與應用相關，與接口無關），並且只向註冊中心註冊 1 * 100 = 100 個與機器實例數量相等的虛擬節點。在這個簡單的例子中，Dubbo 註冊的地址數量下降到了原來的 1/100，這極大地減輕了註冊中心和訂閱者的存儲壓力。更重要的是，地址發現能力與業務 RPC 定義完全解耦，整個集群的容量評估對於運維來說將更加透明：部署多少台機器就有多大的負載，不會像 Dubbo2 那樣，因為業務 RPC 重構而影響整個集群服務發現的穩定性。
