Dubbo3 應(yīng)用級地址發(fā)現(xiàn)遷移指南

本文檔專門針對使用 2.x 版本的老用戶，詳細闡述了升級到 3.x 后的默認地址注冊與發(fā)現(xiàn)行為、如何平滑的遷移到新版本的地址模型。

總體上來說，在地址注冊與發(fā)現(xiàn)環(huán)節(jié)，3.x 是完全兼容 2.x 版本的，這意味著，用戶可以選擇將集群內(nèi)任意數(shù)量的應(yīng)用或機器升級到 3.x，同時在這個過程中保持與 2.x 版本的互操作性。

1 快速升級步驟

簡單的修改 pom.xml 到最新版本就可以完成升級，如果要遷移到應(yīng)用級地址，只需要調(diào)整開關(guān)控制 3.x 版本的默認行為。

1. 升級 Provider 應(yīng)用到最新 3.x 版本依賴，配置雙注冊開關(guān)?dubbo.application.register-mode=all?（建議通過全局配置中心設(shè)置，默認已自動開啟），完成應(yīng)用發(fā)布。
2. 升級 Consumer 應(yīng)用到最新 3.x 版本依賴，配置雙訂閱開關(guān)?dubbo.application.service-discovery.migration=APPLICATION_FIRST?（建議通過全局配置中心設(shè)置，默認已自動開啟），完成應(yīng)用發(fā)布。
3. 在確認 Provider 的上有 Consumer 全部完成應(yīng)用級地址遷移后，Provider 切到應(yīng)用級地址單注冊。完成升級

以下是關(guān)于遷移流程的詳細描述。

2 Provider 端升級過程詳解

在不改變?nèi)魏?Dubbo 配置的情況下，可以將一個應(yīng)用或?qū)嵗壍?3.x 版本，升級后的 Dubbo 實例會默保保證與 2.x 版本的兼容性，即會正常注冊 2.x 格式的地址到注冊中心，因此升級后的實例仍會對整個集群仍保持可見狀態(tài)。

同時新的地址發(fā)現(xiàn)模型（注冊應(yīng)用級別的地址）也將會自動注冊。

通過 -D 參數(shù)，可以指定 provider 啟動時的注冊行為

-Ddubbo.application.register-mode=all
# 可選值 interface、instance、all，默認是 all，即接口級地址、應(yīng)用級地址都注冊

另外，可以在配置中心修改全局默認行為，來控制所有 3.x 實例注冊行為。其中，全局性開關(guān)的優(yōu)先級低于 -D 參數(shù)。

為了保證平滑遷移，即升級到 3.x 的實例能同時被 2.x 與 3.x 的消費者實例發(fā)現(xiàn)，3.x 實例需要開啟雙注冊；當所有上游的消費端都遷移到 3.x 的地址模型后，提供端就可以切換到 instance 模式（只注冊應(yīng)用級地址）。對于如何升級消費端到 3.x 請參見下一小節(jié)。

2.1 雙注冊帶來的資源消耗

雙注冊不可避免的會帶來額外的注冊中心存儲壓力，但考慮到應(yīng)用級地址發(fā)現(xiàn)模型的數(shù)據(jù)量在存儲方面的極大優(yōu)勢，即使對于一些超大規(guī)模集群的用戶而言，新增的數(shù)據(jù)量也并不會帶來存儲問題?？傮w來說，對于一個普通集群而言，數(shù)據(jù)增長可控制在之前數(shù)據(jù)總量的 1/100 ~ 1/1000

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

? 假設(shè)每個接口級 URL 地址平均大小為 5kb，每個應(yīng)用級 URL 平均大小為 0.5kb

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

? 新的應(yīng)用級地址量：2000 * 50 * 0.5kb ≈ 48M

? 雙注冊后僅僅增加了 48M 的數(shù)據(jù)量。

3 Consumer 端升級過程

對于 2.x 的消費者實例，它們看到的自然都是 2.x 版本的提供者地址列表；

對于 3.x 的消費者，它具備同時發(fā)現(xiàn) 2.x 與 3.x 提供者地址列表的能力。在默認情況下，如果集群中存在可以消費的 3.x 的地址，將自動消費 3.x 的地址，如果不存在新地址則自動消費 2.x 的地址。Dubbo3 提供了開關(guān)來控制這個行為：

dubbo.application.service-discovery.migration=APPLICATION_FIRST
# 可選值 
# FORCE_INTERFACE，只消費接口級地址，如無地址則報錯，單訂閱 2.x 地址
# APPLICATION_FIRST，智能決策接口級/應(yīng)用級地址，雙訂閱
# FORCE_APPLICATION，只消費應(yīng)用級地址，如無地址則報錯，單訂閱 3.x 地址

?dubbo.application.service-discovery.migration? 支持通過 -D 以及 全局配置中心 兩種方式進行配置。

接下來，我們就具體看一下，如何通過雙訂閱模式（APPLICATION_FIRST）讓升級到 3.x 的消費端遷移到應(yīng)用級別的地址。在具體展開之前，先明確一條消費端的選址行為：對于雙訂閱的場景，消費端雖然可同時持有 2.x 地址與 3.x 地址，但選址過程中兩份地址是完全隔離的：要么用 2.x 地址，要么用 3.x 地址，不存在兩份地址混合調(diào)用的情況，這個決策過程是在收到第一次地址通知后就完成了的。

下面，我們看一個APPLICATION_FIRST策略的具體操作過程。

首先，提前在全局配置中心 Nacos 配置一條配置項（所有消費端都將默認執(zhí)行這個選址策略）：

緊接著，升級消費端到 3.x 版本并啟動，這時消費端讀取到APPLICATION_FIRST配置后，執(zhí)行雙訂閱邏輯（訂閱 2.x 接口級地址與 3.x 應(yīng)用級地址）

至此，升級操作就完成了，剩下的就是框架內(nèi)部的執(zhí)行了。在調(diào)用發(fā)生前，框架在消費端會有一個“選址過程”，注意這里的選址和之前 2.x 版本是有區(qū)別的，選址過程包含了兩層篩選：

• 先進行地址列表（ClusterInvoker）篩選（接口級地址 or 應(yīng)用級地址）
• 再進行實際的 provider 地址（Invoker）篩選。

ClusterInvoker 篩選的依據(jù)，可以通過 MigrationAddressComparator SPI 自行定義，目前官方提供了一個簡單的地址數(shù)量比對策略，即當 應(yīng)用級地址數(shù)量 == 接口級地址數(shù)量 滿足時則進行遷移。

其實 FORCE_INTERFACE、APPLICATION_FIRST、FORCE_APPLICATION 控制的都是這里的 ClusterInvoker 類型的篩選策略

3.1 雙訂閱帶來的資源消耗

雙訂閱不可避免的會增加消費端的內(nèi)存消耗，但由于應(yīng)用級地址發(fā)現(xiàn)在地址總量方面的優(yōu)勢，這個過程通常是可接受的，我們從兩個方面進行分析：

1. 雙訂閱帶來的地址推送數(shù)據(jù)量增長。這點我們在 ”雙注冊資源消耗“ 一節(jié)中做過介紹，應(yīng)用級服務(wù)發(fā)現(xiàn)帶來的注冊中心數(shù)據(jù)量增長非常有限。
2. 雙訂閱帶來的消費端內(nèi)存增長。要注意雙訂閱只存在于啟動瞬態(tài)，在ClusterInvoker選址決策之后其中一份地址就會被完全銷毀；對單個服務(wù)來說，啟動階段雙訂閱帶來的內(nèi)存增長大概能控制在原內(nèi)存量的 30% ~ 40%，隨后就會下降到單訂閱水平，如果切到應(yīng)用級地址，能實現(xiàn)內(nèi)存 50% 的下降。

3.2 消費端更細粒度的控制

除了全局的遷移策略之外，Dubbo 在消費端提供了更細粒度的遷移策略支持?？刂茊挝豢梢允悄骋粋€消費者應(yīng)用，它消費的服務(wù)A、服務(wù)B可以有各自獨立的遷移策略，具體是用方式是在消費端配置遷移規(guī)則：

key: demo-consumer
step: APPLICATION_FIRST
applications:
 - name: demo-provider
   step: FORCE_APPLICATION
services:
 - serviceKey: org.apache.dubbo.config.api.DemoService:1.0.0
   step: FORCE_INTERFACE

使用這種方式能做到比較精細遷移控制，但是當下及后續(xù)的改造成本會比較高，除了一些特別場景，我們不太推薦啟用這種配置方式。 (遷移指南) 官方推薦使用的全局的開關(guān)式的遷移策略，讓消費端實例在啟動階段自行決策使用哪份可用的地址列表。

4 遷移狀態(tài)的收斂

為了同時兼容 2.x 版本，升級到 3.x 版本的應(yīng)用在一段時間內(nèi)要么處在雙注冊狀態(tài)，要么處在雙訂閱狀態(tài)。

解決這個問題，我們還是從 Provider 視角來看，當所有的 Provider 都切換到應(yīng)用級地址注冊之后，也就不存在雙訂閱的問題了。

4.1 不同的升級策略影響很大

毫無疑問越早越徹底的升級，就能盡快擺脫這個局面。設(shè)想，如果可以將組織內(nèi)所有的應(yīng)用都升級到 3.x 版本，則版本收斂就變的非常簡單：升級過程中 Provider 始終保持雙注冊，當所有的應(yīng)用都升級到 3.x 之后，就可以調(diào)整全局默認行為，讓 Provider 都變成應(yīng)用級地址單注冊了，這個過程并不會給 Consumer 應(yīng)用帶來困擾，因為它們已經(jīng)是可以識別應(yīng)用級地址的 3.x 版本了。

如果沒有辦法做到應(yīng)用的全量升級，甚至在相當長的時間內(nèi)只能升級一部分應(yīng)用，則不可避免的遷移狀態(tài)要持續(xù)比較長的時間。 在這種情況下，我們追求的只能是盡量保持已升級應(yīng)用的上下游實現(xiàn)版本及功能收斂。推動某些 Provider 的上游消費者都升級到 Dubbo3，這樣就可以解除這部分 Provider 的雙注冊，要做到這一點，可能需要一些輔助統(tǒng)計工具的支持。

1. 要能分析出應(yīng)用間的依賴關(guān)系，比如一個 Provdier 應(yīng)用被哪些消費端應(yīng)用消費，這可以通過 Dubbo 提供的服務(wù)元數(shù)據(jù)上報能力來實現(xiàn)。
2. 要能知道每個應(yīng)用當前使用的 dubbo 版本，可以通過掃描或者主動上報手段。