這個Dubbo注冊中心擴展，有點意思！
大家好~我是小樓。其實這篇文章早就寫好了，本來上班第一天就發出來，拖到了現在。
是因為我發燒躺了3天，今天好點上班了，晚上來打最后一瓶點滴。生病真的很痛苦，大家多休息，多鍛煉，保持好的抵抗力~
今天想和大家聊聊Dubbo源碼中實現的一個注冊中心擴展。它很特殊，也幫我解決了一個困擾已久的問題，剛剛在生產中用了，效果很好，迫不及待想分享給大家。
Dubbo的擴展性非常靈活，可以無侵入源碼加載自定義擴展。能擴展協議、序列化方式、注冊中心、線程池、過濾器、負載均衡策略、路由策略、動態代理等等，甚至「擴展本身」也可以擴展。
在介紹今天的這個注冊中心擴展之前，先拋出一個問題，大家思考一下。
如何低成本遷移注冊中心?
有時出于各種目的需要遷移Dubbo的注冊中心，或因為覺得Nacos比較香，想從Zookeeper遷移到Nacos，或因前段時間曝出Consul禁止在中國境內使用。
遷移注冊中心的方案大致有兩種：
- 方案一：使用Dubbo提供的多注冊中心能力，Provider先進行雙注冊，Consumer逐步遷移消費新注冊中心，最后下線老注冊中心。該方案的缺點是修改時有上下游依賴關系。
- 方案二：使用一個同步工具把老注冊中心的數據同步到新注冊中心，Consumer逐步遷移到新注冊中心，最后下線老注冊中心。同步工具有開源的Nacos-sync，我之前的文章《zookeeper到nacos的遷移實踐》就提到了這個方案。這個方案的缺點是架構變得復雜，需要解決同步數據的順序性、一致性、同步組件的高可用等問題。
Nacos-sync 參考 https://github.com/nacos-group/nacos-sync
我們從「業務方成本」和「基礎架構成本」兩個角度考慮一下這兩個方案：
業務方成本我們以每次業務方修改并上線代碼為1個單位，基礎架構成本以增加一個新服務端組件為2個單位，從復雜度上來說基礎架構成本遠遠高于業務方修改并上線代碼，但這里我們認為只是2倍關系，做過基礎組件開發的同學肯定感同身受，推動別人改代碼比自己埋頭寫代碼要難。
我們統計下上述方案中，遷移一對Consumer和Provider總共需要的成本是多少：
- 方案一：Provider雙注冊+1;Consumer消費新注冊中心+1;Provider下線舊注冊中心+1;總成本為3
- 方案二：同步組件+2;Consumer消費新注冊中心+1;Provider下線舊注冊中心+1;總成本為4
有沒有成本更低的方案?
首先我們不考慮引入同步組件，其次Provider和Consumer能否不修改就能解決?我覺得理論上肯定可以解決，因為Java的字節碼是可以動態修改的，肯定能達到這個目的，但這樣的復雜度和風險會非常高。
退一步能否每個應用只修改發布一次就完成遷移?
Dubbo配置多注冊中心可以參考這篇文章《幾個你不知道的dubbo注冊中心細節》，你會發現多注冊中心是通過配置文件配置的，如下
dubbo.registries.zk1.address=zookeeper://127.0.0.1:2181
dubbo.registries.zk2.address=zookeeper://127.0.0.1:2182
只修改一次代碼，就必須把這個配置變成動態的，有點難，但不是做不到，可在應用啟動時遠程加載配置，或者采取替換配置文件的方式來達到目的。
但這只解決了部分問題，還有兩個問題需要解決：
- Dubbo注冊、訂閱都發生在應用啟動時，應用啟動后就沒法修改了。也不是完全不能，如果采用了api的方式接入Dubbo可以通過改代碼來實現，但幾乎這種方式不會被采用;
- Dubbo消費沒法動態切換，多注冊中心消費時，Dubbo默認的行為是挑第一個可用的注冊中心進行調用，無法主動地進行切換;如果實現了主動切換還有個好處是穩定性提高了很多，萬一新注冊中心出現問題還可以及時切回去。
這里針對第二點的消費邏輯做一點簡單說明，老版本(<2.7.5)邏輯比較簡單粗暴，代碼位于RegistryAwareClusterInvoker：
- 挑選第一個可用的注冊中心進行調用
- 新版本(>=2.7.5)則稍微豐富一點，代碼位于ZoneAwareClusterInvoker：
- 挑選一個可用且帶preferred偏好配置的注冊中心進行調用，注意這個偏好配置不同版本key還不一樣，有點坑
- 如果都不符合1，則挑選同一個分區且可用的注冊中心進行調用，分區也是通過參數配置，這個主要是為了跨機房的就近訪問
如果1、2都不符合，通過一個負載均衡算法挑選出一個可用的注冊中心進行調用
如果1、2、3都不符合，則挑選一個可用的注冊中心
如果上述都不符合，則使用第一個注冊中心進行調用
可以看出新版本功能很豐富，但它是有版本要求的，而且控制的key也變來變去，甚至去搜一下也有Bug存在，所以如果是單一穩定的高版本是可以通過這個來做，但大部分還是達不到這個要求。
很長一段時間以來，我都沒有想到一個好的辦法來解決這個問題，甚至我們公司內部有直接修改Dubbo源碼來實現動態切換消費的能力，但這種入侵修改無法持續，直到有一天瀏覽Dubbo源碼時，無意間看到了MultipleRegistry，仿佛發現了新大陸，用醍醐灌頂來形容一點不為過。
MultipleRegistry，有點意思!
MultipleRegistry是Dubbo 2.7.2引入的一個注冊中心擴展，注冊中心擴展圈起來，要考!意味著這個擴展可以在任何>=2.7.0版本上運行，稍微改改也能在2.7以下的版本使用
這究竟是個什么注冊中心的擴展呢?
實際上這個擴展并不是一個實際的注冊中心的擴展，而是一個包裝，它本身不提供服務注冊發現的能力，它只是把其他注冊中心聚合起來的一個空殼。
為什么這個「空殼」這么厲害呢?下面我們就來分析分析源碼。
由于剛好手上有3.0.0版本的源碼，所以接下來的源碼分析基于Dubbo 3.0.0版本，也不用擔心版本問題，這個擴展自從2.7.2引入之后幾乎沒有大的改動，只有Bugfix，所以什么版本基本都差不多。只分析接口級服務發現，應用級的暫時不分析，原理類似。
不過在講源碼之前，還得說說Dubbo注冊中心插件的運行原理，否則源碼可能看不懂，我們以開發一個注冊中心擴展為例：
Dubbo注冊中心擴展需實現RegistryService和RegistryFactory接口
public interface RegistryService {
void register(URL url);
void unregister(URL url);
void subscribe(URL url, NotifyListener listener);
void unsubscribe(URL url, NotifyListener listener);
List<URL> lookup(URL url);
}
這里的五個接口分別是注冊、注銷、訂閱、取消訂閱、查詢，在Dubbo應用啟動時會調用這些接口。
都比較好理解，需要提一下subscribe接口。
subscribe傳入了一個NotifyListener參數，可以理解為一個回調，當監聽的的URL發生變化時，調用這個NotifyListener通知Dubbo。
public interface NotifyListener {
void notify(List<URL> urls);
}
NotifyListener也是個接口，只有一個notify方法，這個方法傳入的參數是所消費的URL的所有Provider列表。
@SPI("dubbo")
public interface RegistryFactory {
@Adaptive({"protocol"})
Registry getRegistry(URL url);
}
RegistryFactory是描述了如何創建Registry擴展的工廠類，URL就是配置中
zookeeper://127.0.0.1:2181
還需要遵守Dubbo SPI的加載規則擴展才能被正確加載
這些內容官方文檔中說的比較清楚，如果有疑問可以看看Dubbo的官方文檔說明。
簡單介紹到此結束，接下來重點介紹MultipleRegistry。
首先看初始化，代碼只挑出重點，在初始化MultipleRegistry時，分別對注冊和訂閱的注冊中心進行初始化，這些注冊中心來自MultipleRegistry的URL配置，URL上的key分別為service-registry、reference-registry，實際測試下來URL的參數中帶奇怪的字符會導致編譯不通過，不過這并不是重點，基本的還是可用，而且也不一定要采用這種配置。
public MultipleRegistry(URL url, boolean initServiceRegistry, boolean initReferenceRegistry) {
...
Map<String, Registry> registryMap = new HashMap<>();
// 初始化注冊的注冊中心
if (initServiceRegistry) {
initServiceRegistry(url, registryMap);
}
// 初始化訂閱的注冊中心
if (initReferenceRegistry) {
initReferenceRegistry(url, registryMap);
}
...
}
我們再看注冊和訂閱：
注冊比較簡單，只需要對剛剛初始化的serviceRegistries都進行注冊即可
public void register(URL url) {
super.register(url);
for (Registry registry : serviceRegistries.values()) {
registry.register(url);
}
}
訂閱時也是針對referenceRegistries的每個注冊中心都訂閱，但這里有個不同的點是NotifyListener的妙用。
public void subscribe(URL url, NotifyListener listener) {
MultipleNotifyListenerWrapper multipleNotifyListenerWrapper = new MultipleNotifyListenerWrapper(listener);
multipleNotifyListenerMap.put(listener, multipleNotifyListenerWrapper);
for (Registry registry : referenceRegistries.values()) {
SingleNotifyListener singleNotifyListener = new SingleNotifyListener(multipleNotifyListenerWrapper, registry);
multipleNotifyListenerWrapper.putRegistryMap(registry.getUrl(), singleNotifyListener);
registry.subscribe(url, singleNotifyListener);
}
super.subscribe(url, multipleNotifyListenerWrapper);
}
先用MultipleNotifyListenerWrapper把最原始的NotifyListener包裝起來，NotifyListener傳給每個被包裝的注冊中心。MultipleNotifyListenerWrapper和SingleNotifyListener分別是什么?
MultipleNotifyListenerWrapper將原始的NotifyListener進行包裝，且持有SingleNotifyListener的引用，它提供了一個方法notifySourceListener的方法，將持有的SingleNotifyListener中上次變更的URL列表進行merge后調用最原始的NotifyListener.notify()
protected class MultipleNotifyListenerWrapper implements NotifyListener {
Map<URL, SingleNotifyListener> registryMap = new ConcurrentHashMap<URL, SingleNotifyListener>(4);
NotifyListener sourceNotifyListener;
...
public synchronized void notifySourceListener() {
List<URL> notifyURLs = new ArrayList<URL>();
URL emptyURL = null;
for (SingleNotifyListener singleNotifyListener : registryMap.values()) {
List<URL> tmpUrls = singleNotifyListener.getUrlList();
if (CollectionUtils.isEmpty(tmpUrls)) {
continue;
}
// empty protocol
if (tmpUrls.size() == 1
&& tmpUrls.get(0) != null
&& EMPTY_PROTOCOL.equals(tmpUrls.get(0).getProtocol())) {
// if only one empty
if (emptyURL == null) {
emptyURL = tmpUrls.get(0);
}
continue;
}
notifyURLs.addAll(tmpUrls);
}
// if no notify URL, add empty protocol URL
if (emptyURL != null && notifyURLs.isEmpty()) {
notifyURLs.add(emptyURL);
}
this.notify(notifyURLs);
}
...
}
再看SingleNotifyListener，它的notify去調用MultipleNotifyListenerWrapper的notifySourceListener
class SingleNotifyListener implements NotifyListener {
MultipleNotifyListenerWrapper multipleNotifyListenerWrapper;
Registry registry;
volatile List<URL> urlList;
@Override
public synchronized void notify(List<URL> urls) {
this.urlList = urls;
if (multipleNotifyListenerWrapper != null) {
this.multipleNotifyListenerWrapper.notifySourceListener();
}
}
...
}
仔細思考我們發現：
- MultipleNotifyListenerWrapper是個注冊中心擴展的包裝，它本身是沒有通知能力的，只能借助的真實注冊中心擴展的通知能力
- SingleNotifyListener是真實的注冊中心的通知回調，由它去調用MultipleNotifyListenerWrapper的notifySourceListener，調用前可將數據進行merge
如果你仔細讀完上面的文章你會發現，這不就是包裝了一下注冊中心擴展嗎?就這?哪里醍醐灌頂了?
不著急，我們先扒一扒作者為什么寫這樣一個擴展，他的初衷是想解決什么問題?
參考這個issue：https://github.com/apache/dubbo/issues/3932
作者說：我們可以在程序運行時下線(注銷)服務，如果有個Dubbo服務同時注冊了Zookeeper和Nacos，而我只想注銷其中一個注冊中心，MultipleRegistry就可以解決這種場景。
作者的初衷很簡單，但當我看到這個實現時，靈光乍現，感覺這個實現如果稍微改一改，簡直就是一個Dubbo多注冊中心遷移神器。
Dubbo多注冊中心遷移神器
Dubbo多注冊中心遷移神器具有什么樣的特性?
- 可以動態(遠程配置)地注冊到一個或多個注冊中心，且在程序不重啟的情況下可以動態調整
- 可以動態(遠程配置)地消費某一個或多個注冊中心，同樣可以在程序不重啟的情況下可以動態調整
- 消費有兜底邏輯，比如配置了消費Zookeeper，但Zookeeper上可能只有A服務，B服務不存在，那么調用B服務時可以用其他注冊中心的Provider來兜底，這就保證了注冊中心遷移過程中沒用上下游的依賴
如果上面說的能夠領會到，這些需求實現起來就很簡單：
- 啟動時，Provider和Consumer都分別監聽對應的配置項，按需注冊和消費，目前MultipleRegistry已經實現
- Dubbo應用運行中，配置項變更事件驅動
- Provider：觸發一個重新注冊、注銷的事件，根據最新的配置項將需要注冊的注冊中心再注冊一遍，需要注銷的注冊中心注銷
- Consumer：觸發重新進行訂閱和取消訂閱，
- 消費兜底邏輯，將MultipleNotifyListenerWrapper中的notifySourceListener的merge邏輯進行重寫，可以實現有線消費、無對應Provider兜底消費。當然如果配置變更也需要觸發一次notify
按照這個思路，我已經實現了一個版本在線上跑了起來!不過耦合了公司內部的配置中心。
如果想不耦合，可以采用Dubbo SPI擴展的方式來擴展「讀取監聽配置變更部分」，擴展中的擴展，有點騷~
這篇文章有點長，最后來回顧一下講了啥：
首先文章從一個Dubbo注冊中心遷移成本的問題講起，現有的方案成本都是比較高，一直苦苦找尋更低成本、兼容性更強的方案。終于在一次瀏覽Dubbo源碼過程中發現了MultipleRegistry源碼，經過研究發現只需要經過稍微的修改就能符合我們對完美動態注冊中心的定義。
在我寫這篇文章的時候，又試圖搜索了一下Dubbo動態注冊中心，發現了「Kirito的技術分享」的一篇文章《平滑遷移 Dubbo 服務的思考》提到了阿里云的一個產品的實現和上文提到的方案類似。
如果剛好你也有這個需求，可以用上文的思路實現看看，并不復雜，是不是感覺賺了一個億。
