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註冊中心擴充套件是如何編寫的，這塊直接看官方文件：
雖然我覺得看完了文件你也不一定能實現一個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：
為了讓這個專案看起來更飽滿一點，還寫了一個README：
最後
如果你耐心看完了本文，且對dubbo有所瞭解，我相信你已經能自己寫一個dubbo註冊中心擴充套件。
如果你也經常在本地做測試，也可以用我寫的這個mock registry來試試，當然程式碼和想法都有改進的地方，如果你有更好的想法也可以和我交流。
最後，這應該是勞動節前的最後一篇文章，寫文不易，來點正向反饋，點贊+在看+分享，我會寫得更有勁~我們下期再見。
- 搜尋關注微信公眾號"捉蟲大師"，後端技術分享，架構設計、效能優化、原始碼閱讀、問題排查、踩坑實踐。