服務發現
Dubbo 提供基於客戶端的服務發現機制，依靠第三方註冊中心組件來協調服務發現過程。它支援常用的註冊中心，例如 Nacos、Consul 和 Zookeeper。
以下是 Dubbo 服務發現機制的基本工作流程圖
服務發現涉及三個角色：提供者、消費者和註冊中心。在此設定中，Dubbo 提供者實例將其 URL 位址註冊到註冊中心，註冊中心彙總這些數據。Dubbo 消費者從註冊中心讀取位址列表並訂閱變更。每當位址列表發生變更時，註冊中心都會通知所有訂閱的消費者實例。
百萬級叢集的服務發現
與許多其他微服務框架不同，Dubbo 3 的服務發現源自阿里巴巴的大規模電商微服務叢集。因此，它在效能、可擴展性和易用性方面明顯優於大多數主流開源產品。 它是企業構建面向未來的可擴展微服務叢集的最佳選擇。
- 首先，Dubbo 的註冊中心在應用程式粒度級別彙總實例數據，允許消費者根據其需求精確訂閱，從而避免了像 Istio 和 Spring Cloud 等大多數開源框架中全量訂閱造成的效能瓶頸。
- 其次，Dubbo SDK 對消費者端位址列表處理進行了大量優化，增加了非同步通知、快取、位圖和各種解析優化，以避免位址更新期間常見的資源波動。
- 最後，在功能豐富性和易用性方面，除了將 IP 和埠等基本端點資訊同步到消費者之外，Dubbo 還將伺服器 RPC/HTTP 服務的元數據資訊及其配置同步到消費者端，允許消費者和提供者之間進行更細粒度的協作。
高效的位址推送實現
從註冊中心的視角來看，它是基於應用名稱 (dubbo.application.name) 聚合整個叢集的實例地址。每個提供服務的實例都會將自身的應用名稱、實例 IP:port 地址資訊（通常還包含少量的實例元數據，例如機器的區域、環境等）註冊到註冊中心。
Dubbo2 的註冊中心是以服務粒度聚合實例地址，比應用粒度更細，意味著更多的數據傳輸。這導致在大規模叢集中出現了一些效能問題。針對 Dubbo2 和 Dubbo3 數據模型的不一致性，Dubbo3 提供了平滑的遷移方案，使用戶對模型的改變透明無感。
每個消費服務實例都從註冊中心訂閱實例地址列表。與一些將所有註冊中心數據（應用程式 + 實例地址）載入到本地進程的產品不同，Dubbo 實現了精確的按需地址訂閱。例如，如果一個消費應用程式依賴 app1 和 app2，它只會訂閱 app1 和 app2 的地址列表更新，顯著減少了冗餘數據推送和解析的負擔。
豐富的元數據配置
除了與註冊中心交互之外，Dubbo 3 完整的地址發現過程還有一個額外的元數據路徑，稱為元數據服務 (Metadata Service)。實例地址和元數據共同構成了消費者端的有效地址列表。
如上圖所示，完整的流程是：首先，消費者從註冊中心接收地址 (IP:port) 資訊，然後與提供者建立連線，並從元數據服務讀取元數據配置資訊。這兩部分資訊共同構成了 Dubbo 消費者端有效的、面向服務的地址列表。這兩個步驟都發生在實際的 RPC 服務調用之前。
關於 MetadataService 的定義以及服務發現過程的完整分析，請參考應用級服務發現詳解（英文）。
對於微服務服務發現模型中的數據同步，REST 定義了一個非常有趣的成熟度模型。有興趣的讀者可以參考此連結 https://martinfowler.dev.org.tw/articles/richardsonMaturityModel.html。根據文章的 4 級成熟度定義，Dubbo 目前基於介面粒度的模型對應最高級別 L4。
配置方法
Dubbo 服務發現擴展支持多種註冊中心組件，例如 Nacos、Zookeeper、Consul、Redis、Kubernetes 等。可以通過配置進行切換，並且也支持身份驗證和命名空間隔離配置。具體的配置方法請參考 SDK 文件。
Dubbo 也支持單個應用程式內多個註冊中心的場景，例如雙註冊、雙訂閱等。這對於實現不同叢集之間的數據交換和叢集遷移非常有用。我們將在未來的文件中添加「最佳實務」範例來說明這部分。
自定義擴展
註冊中心適配支持自定義擴展實現。詳情請參考Dubbo 擴展性（英文）。
