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

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

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

1 快速升級(jí)步驟

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

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

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

2 Provider 端升級(jí)過程詳解

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

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

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

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

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

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

2.1 雙注冊帶來的資源消耗

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

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

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

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

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

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

3 Consumer 端升級(jí)過程

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

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

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

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

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

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

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

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

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

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

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

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

3.1 雙訂閱帶來的資源消耗

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

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

3.2 消費(fèi)端更細(xì)粒度的控制

除了全局的遷移策略之外，Dubbo 在消費(fèi)端提供了更細(xì)粒度的遷移策略支持?？刂茊挝豢梢允悄骋粋€(gè)消費(fèi)者應(yīng)用，它消費(fèi)的服務(wù)A、服務(wù)B可以有各自獨(dú)立的遷移策略，具體是用方式是在消費(fèi)端配置遷移規(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ì)遷移控制，但是當(dāng)下及后續(xù)的改造成本會(huì)比較高，除了一些特別場景，我們不太推薦啟用這種配置方式。 (遷移指南) 官方推薦使用的全局的開關(guān)式的遷移策略，讓消費(fèi)端實(shí)例在啟動(dòng)階段自行決策使用哪份可用的地址列表。

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

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

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

4.1 不同的升級(jí)策略影響很大

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

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

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