靈感乍現！造了個與眾不同的Dubbo注冊中心擴展輪子
hello大家好呀，我是小樓。
作為一名基礎組件開發，服務好每一位業務開發同學是我們的義務(KPI)。
客服群里經常有業務開發同學丟來一段代碼、一個報錯，而我們，當然要微笑服務，耐心解答。
有的問題，憑借多年踩坑經驗，一眼就能看出，有的問題，看一眼代碼也能知道原因，但有的問題，還真就光憑看是看不出來的，這時，只能下載代碼，本地跑跑看了。
熟悉我的朋友都知道，我從事dubbo相關開(客)發(服)工作多年，所以我就來講一個dubbo問題排查過程中的有趣的事。
通常遇到看不能解決的問題時，先git拉取代碼，再導入IDEA，找到main方法點擊啟動，一頓操作下來，不出意外，肯定會有點小錯誤，比如這條：
Socket error occurred: localhost/127.0.0.1:2181: Connection refused
看到2181端口就知道這是本地沒有裝zookeeper(下文簡稱zk)，問題不大，docker直接拉一個zk鏡像，起個容器就完事。
隨著這樣的習慣日積月累，低配的Mac上相繼跑了etcd、redis、mysql等等容器，重要的是還打開了N個IDEA窗口。
每當啟動一個新的項目時，風扇呼呼地直接將IDEA卡死。
這時，我陷入了思考，能不能少跑點程序?
etcd、redis、mysql暫時搞不定，但dubbo的注冊中心我熟啊!柿子當然要挑軟的捏。
需求梳理
在開干之前，得先梳理一下需求，于是我腦子閃現出無數個在本地測試時遇到的與dubbo注冊中心有關問題的瞬間，但仔細一捋，無外乎兩種：
- 作為provider：最最最主要的就是不要阻斷應用啟動。
- 作為consumer：
不要阻斷應用啟動。
可以發現并調用本地的provider。
可以調用遠程的provider。
可以手動指定調用任意provider。
除了這兩個功能上的需求，還得解決我們最初的問題：「不要依賴第三方服務」(如zk)。
調研
由于一開始就想到了利用dubbo注冊中心擴展來實現這個功能，為了不重復造輪子，翻了一下dubbo源碼，看看是否已經有相應的實現：
發現除了dubbo-registry-multicast之外都是依賴了第三方服務，所以這個multicast是啥呢?dubbo官方文檔說的很清楚：
乍一看很符合我們的需求，但仔細一想，還是有幾點不滿足：
- 不一定能發現遠程的provider，如果大家代碼都是用的zk，而你把代碼拉下來注冊中心改成multicast是沒法發現遠程的服務的;
- 沒法手動指定調用任意provider。
產品設計
服務發現得有個載體，要么通過第三方組件、要么通過網絡。但我們忽略了，在本地，磁盤也可以作為一個載體。
provider注冊向磁盤文件寫入，consumer訂閱即讀取磁盤文件，當磁盤文件有變更時通知consumer，大概是這么個樣子：
這樣設計有什么好處呢?
- 不依賴其他服務，只是文件的讀寫，不會阻塞應用啟動。
- consumer和provider都在本地時，可以像其他注冊中心(如zk、nacos等)一樣工作，對開發者完全透明。
- 可以手動修改、指定調用任意provider。
唯一的缺點是，無法發現遠程的provider，但我們可以手動指定，也算是沒有大礙。
我們以dubbo 2.7.x版本的接口級服務發現來設計我們的產品，因為這個版本使用的最多。
首先要考慮的是如何去組織服務發現文件，由于是接口級服務發現，我們就按服務名來作為文件名，每個服務一個文件：
其次每個文件的內容怎么組織?最簡單的就是將dubbo注冊的URL直接寫入文件，每行一個URL，就像這樣：
但你可能發現了問題，這dubbo的URL有點長啊~如果讓我手動指定，豈不是很難做到?
這個問題好解決，我們實現一個簡寫版本的URL，比如有一行這樣簡寫，就將它還原為一個可用的URL。
127.0.0.1:20880
代碼實現
在實現之前首先要了解的是dubbo注冊中心擴展是如何編寫的，這塊直接看官方文檔：
https://dubbo.apache.org/zh/docs/v2.7/dev/impls/registry/
雖然我覺得看完了文檔你也不一定能實現一個dubbo注冊中心擴展，但別慌，先往下看，說不定看完了本文你也能自己寫一個。
先看一下代碼結構：
- 項目命名為：dubbo-registry-mock，和dubbo源碼中的命名風格保持一致。
- MockRegistry是注冊中心的核心實現。
- MockRegistryFactory是mock registry的工廠，dubbo會通過這個類來創建MockRegistry。
- org.apache.dubbo.registry.RegistryFactory這個文件是指定MockRegistryFactory該如何加載，即dubbo的SPI發現文件。
dubbo的注冊中心配置只需要改成：
dubbo.registry.address=mock://127.0.0.1:2181
這里起作用的只有mock，ip、port并不重要，只是占個位置。
當dubbo應用啟動時，讀取到配置的mock，會查找resources/META-INF.dubbo下的org.apache.dubbo.registry.RegistryFactory文件，這里它的內容為：
mock=org.newboo.MockRegistryFactory
于是去new出一個MockRegistryFactory。
注：newboo.org是我曾經注冊的一個域名，用來放博客，不過后來沒有續費，現在我的測試代碼中經常會出現這個包名。
MockRegistryFactory也很簡單，直接new一個MockRegistry：
public class MockRegistryFactory extends AbstractRegistryFactory {
@Override
protected Registry createRegistry(URL url) {
return new MockRegistry(url);
}
}
最后看核心的實現MockRegistry類：
public MockRegistry(URL url) {
super(url);
String basePath = DISCOVERY_DEFAULT_DIR;
if (StringUtils.isNotEmpty(url.getParameter(DISCOVERY_FILE_DIR_KEY))) {
basePath = url.getParameter(DISCOVERY_FILE_DIR_KEY);
}
mockService = new MockService(basePath);
ScheduledExecutorService scheduledExecutorService = Executors.newScheduledThreadPool(1, new NamedThreadFactory("file_scan", true));
scheduledExecutorService.scheduleWithFixedDelay(new SubscribeScan(), 1000L, 5000, TimeUnit.MILLISECONDS);
}
這個構造方法，做了3件事情：
- 獲取basePath，也就是服務發現的文件夾基礎路徑，有個默認值，也可以根據url的參數進行調整，如：
dubbo.registry.address=mock://127.0.0.1:2181?discovery_file=/tmp/mock-registry2
- new一個MockService，承載了核心的服務發現邏輯，后面再說。
- 啟動一個定時任務，每隔5秒去掃描一次文件，看文件是否有變化，如果有變化則通知consumer，詳細后面也會說。
MockRegistry繼承自FailbackRegistry，只需要實現它的doRegister、doUnregister、doSubscribe、doUnsubscribe、isAvailable幾個方法即可。
其中isAvailable是判斷注冊中心是否可用，我們直接返回true即可。
doUnsubscribe是取消訂閱，這里也啥都不用干，剩下3個方法我們將邏輯封裝在MockService：
@Override
public void doRegister(URL url) {
try {
mockService.writeUrl(url);
} catch (Throwable e) {
throw new RpcException("Failed to register " + url, e);
}
}
@Override
public void doUnregister(URL url) {
try {
mockService.removeUrl(url);
} catch (Throwable e) {
throw new RpcException("Failed to unregister " + url, e);
}
}
@Override
public void doSubscribe(URL url, NotifyListener listener) {
try {
List<URL> urls = mockService.getUrls(url.getServiceInterface());
listener.notify(urls);
} catch (ServiceNotChangeException ignored) {
} catch (Throwable e) {
throw new RpcException("Failed to subscribe " + url, e);
}
}
writeUrl直接獲取到文件名，往文件中append新的一行URL即可：
public void writeUrl(URL url) throws IOException {
String fileName = pathCenter.getServicePath(url.getServiceInterface());
// 寫入文件
String line = url.toFullString();
FileUtil.appendLine(fileName, line);
}
removeUrl先讀取文件，把要注銷的URL刪除，再把剩余內容覆蓋寫回文件即可：
public void removeUrl(URL url) throws IOException {
String fileName = pathCenter.getServicePath(url.getServiceInterface());
String line = url.toFullString();
List<String> lines = FileUtil.readLines(fileName);
lines = LinesUtil.removeLine(lines, line);
FileUtil.writeLines(fileName, lines);
}
getUrls去掃描文件，如果文件有變更，就把讀取到的最新的URL格式化后返回，之所以要格式化是因為可能會有簡寫的URL(見上文)，文件是否有變更直接根據文件的最后更新時間來判斷，精確到毫秒，本地測試也夠用了：
public List<URL> getUrls(String service) throws Exception {
if (!scan(service)) {
throw new ServiceNotChangeException();
}
String fileName = pathCenter.getServicePath(service);
List<String> lines = FileUtil.readLines(fileName);
List<URL> urls = new ArrayList<>(lines.size());
for (String line : lines) {
if (!LinesUtil.isSkipLine(line)) {
urls.add(format(line));
}
}
return urls;
}
其中scan如果返回false，說明文件沒有變更，直接忽略本次掃描。
最后一個SubscribeScan只需要把已經訂閱的接口拿出來，執行一次doSubscribe即可：
public class SubscribeScan implements Runnable {
@Override
public void run() {
try {
// 已經訂閱的url
Map<URL, Set<NotifyListener>> subscribeds = getSubscribed();
if (subscribeds == null || subscribeds.isEmpty()) {
return;
}
for (Map.Entry<URL, Set<NotifyListener>> entry : subscribeds.entrySet()) {
for (NotifyListener listener : entry.getValue()) {
doSubscribe(entry.getKey(), listener);
}
}
} catch (Throwable t) {
// ignore
}
}
}
看到這里可能有的同學問，為啥要輪詢，不用WatchService監聽文件的變更呢?我寫的時候也查了一下，并且debug了一下，發現WatchService的真實實現是PollingWatchService，而且它也是采用輪詢來實現的，不信可以打開這個類看看。
感覺和自己寫沒啥差別，所以我就自己寫了。
完整代碼已經上傳到了github：https://github.com/lkxiaolou/dubbo-registry-mock。
為了讓這個項目看起來更飽滿一點，還寫了一個README：
最后
如果你耐心看完了本文，且對dubbo有所了解，我相信你已經能自己寫一個dubbo注冊中心擴展。
如果你也經常在本地做測試，也可以用我寫的這個mock registry來試試，當然代碼和想法都有改進的地方，如果你有更好的想法也可以和我交流。
