開啟服務注冊模式

Dubbo3 服務發現平滑遷移步驟與原理

https://cn.dubbo.apache.org/zh-cn/blog/2024/05/13/如果從接口級服務發現平滑遷移到應用級服務發現/

全局開關

應用配置（可以通過配置文件或者 -D 指定）dubbo.application.register-mode 為 instance（只注冊應用級）、all（接口級+應用級均注冊）開啟全局的注冊開關，配置此開關后，默認會向所有的注冊中心中注冊應用級的地址，供消費端服務發現使用。

可選值 interface、instance、all，默認是 all，即接口級地址、應用級地址都注冊

# 雙注冊
dubbo.application.register-mode=all

# 僅應用級注冊
dubbo.application.register-mode=instance

雙注冊帶來的資源消耗

雙注冊不可避免的會帶來額外的注冊中心存儲壓力，但考慮到應用級地址發現模型的數據量在存儲方面的極大優勢，即使對于一些超大規模集群的用戶而言，新增的數據量也并不會帶來存儲問題。總體來說，對于一個普通集群而言，數據增長可控制在之前數據總量的 1/100 ~ 1/1000

以一個中等規模的集群實例來說： 2000 實例、50個應用（500 個 Dubbo 接口，平均每個應用 10 個接口）。

? 假設每個接口級 URL 地址平均大小為 5kb，每個應用級 URL 平均大小為 0.5kb

? 老的接口級地址量：2000 * 500 * 5kb ≈ 4.8G

? 新的應用級地址量：2000 * 50 * 0.5kb ≈ 48M

? 雙注冊后僅僅增加了 48M 的數據量。

應用級服務發現工作原理

Dubbo3 應用級服務發現官方文檔

Dubbo3 應用級服務發現官方文檔

服務提供者啟動，首先解析應用定義的“普通服務”并依次注冊為 RPC 服務，緊接著注冊內建的 MetadataService 服務，最后打開 TCP 監聽端口。

啟動完成后，將實例信息注冊到注冊中心（僅限 ip、port 等實例相關數據），提供者啟動完成。

服務消費者啟動，首先依據其要“消費的 provider 應用名”到注冊中心查詢地址列表，并完成訂閱（以實現后續地址變更自動通知）。

消費端拿到地址列表后，緊接著對 MetadataService 發起調用，返回結果中包含了所有應用定義的“普通服務”及其相關配置信息。
至此，消費者可以接收外部流量，并對提供者發起 Dubbo RPC 調用
僅提供者上線后：

消費者上線后：

服務自省中的關鍵機制

元數據同步機制
Client 與 Server 間在收到地址推送后的配置同步是服務自省的關鍵環節，目前針對元數據同步有兩種具體的可選方案，分別是：

• 內建 MetadataService。（dubbo3）
• 獨立的元數據中心，通過中心化的元數據集群協調數據。(dubbo2)

1. 內建 MetadataService MetadataService 通過標準的 Dubbo 協議暴露，根據查詢條件，會將內存中符合條件的“普通服務”配置返回給消費者。這一步發生在消費端選址和調用前。

2. 元數據中心 復用 2.7 版本中引入的元數據中心，provider 實例啟動后，會嘗試將內部的 RPC 服務組織成元數據的格式同步到元數據中心，而 consumer 則在每次收到注冊中心推送更新后，主動查詢元數據中心。

注意 consumer 端查詢元數據中心的時機，是等到注冊中心的地址更新通知之后。也就是通過注冊中心下發的數據，我們能明確的知道何時某個實例的元數據被更新了，此時才需要去查元數據中心。

RPC 服務 < - > 應用映射關系

Dubbo 之所以選擇建立一套“接口-應用”的映射關系，主要是考慮到 service - app 映射關系的不確定性。一個典型的場景即是應用/服務拆分，如上面提到的配置<dubbo:reference interface="RPC Service 2" provided-by="provider-app-x" />，PC Service 2 是定義于 provider-app-x 中的一個服務，未來它隨時可能會被開發者分拆到另外一個新的應用如 provider-app-x-1 中，這個拆分要被所有的 PC Service 2 消費方感知到，并對應用進行修改升級，如改為<dubbo:reference interface="RPC Service 2" provided-by="provider-app-x-1" />，這樣的升級成本不可否認還是挺高的。 到底是 Dubbo 框架幫助開發者透明的解決這個問題，還是交由開發者自己去解決，當然這只是個策略選擇問題，并且 Dubbo 2.7.5+ 版本目前是都提供了的。其實我個人更傾向于交由業務開發者通過組織上的約束來做，這樣也可進一步降低 Dubbo 框架的復雜度，提升運行態的穩定性。