hello大家好呀，我是小樓。

作為一名基礎(chǔ)組件開發(fā)，服務(wù)好每一位業(yè)務(wù)開發(fā)同學(xué)是我們的義務(wù)(KPI)。

客服群里經(jīng)常有業(yè)務(wù)開發(fā)同學(xué)丟來一段代碼、一個報錯，而我們，當(dāng)然要微笑服務(wù)，耐心解答。

有的問題，憑借多年踩坑經(jīng)驗，一眼就能看出，有的問題，看一眼代碼也能知道原因，但有的問題，還真就光憑看是看不出來的，這時，只能下載代碼，本地跑跑看了。

熟悉我的朋友都知道，我從事dubbo相關(guān)開(客)發(fā)(服)工作多年，所以我就來講一個dubbo問題排查過程中的有趣的事。

通常遇到看不能解決的問題時，先git拉取代碼，再導(dǎo)入IDEA，找到main方法點擊啟動，一頓操作下來，不出意外，肯定會有點小錯誤，比如這條：

Socket error occurred: localhost/127.0.0.1:2181: Connection refused

看到2181端口就知道這是本地沒有裝zookeeper(下文簡稱zk)，問題不大，docker直接拉一個zk鏡像，起個容器就完事。

隨著這樣的習(xí)慣日積月累，低配的Mac上相繼跑了etcd、redis、mysql等等容器，重要的是還打開了N個IDEA窗口。

每當(dāng)啟動一個新的項目時，風(fēng)扇呼呼地直接將IDEA卡死。

這時，我陷入了思考，能不能少跑點程序?

etcd、redis、mysql暫時搞不定，但dubbo的注冊中心我熟啊!柿子當(dāng)然要挑軟的捏。

需求梳理

在開干之前，得先梳理一下需求，于是我腦子閃現(xiàn)出無數(shù)個在本地測試時遇到的與dubbo注冊中心有關(guān)問題的瞬間，但仔細(xì)一捋，無外乎兩種：

• 作為provider：最最最主要的就是不要阻斷應(yīng)用啟動。
• 作為consumer：

不要阻斷應(yīng)用啟動。

可以發(fā)現(xiàn)并調(diào)用本地的provider。

可以調(diào)用遠(yuǎn)程的provider。

可以手動指定調(diào)用任意provider。

除了這兩個功能上的需求，還得解決我們最初的問題：「不要依賴第三方服務(wù)」(如zk)。

調(diào)研

由于一開始就想到了利用dubbo注冊中心擴(kuò)展來實現(xiàn)這個功能，為了不重復(fù)造輪子，翻了一下dubbo源碼，看看是否已經(jīng)有相應(yīng)的實現(xiàn)：

發(fā)現(xiàn)除了dubbo-registry-multicast之外都是依賴了第三方服務(wù)，所以這個multicast是啥呢?dubbo官方文檔說的很清楚：

乍一看很符合我們的需求，但仔細(xì)一想，還是有幾點不滿足：

• 不一定能發(fā)現(xiàn)遠(yuǎn)程的provider，如果大家代碼都是用的zk，而你把代碼拉下來注冊中心改成multicast是沒法發(fā)現(xiàn)遠(yuǎn)程的服務(wù)的;
• 沒法手動指定調(diào)用任意provider。

產(chǎn)品設(shè)計

服務(wù)發(fā)現(xiàn)得有個載體，要么通過第三方組件、要么通過網(wǎng)絡(luò)。但我們忽略了，在本地，磁盤也可以作為一個載體。

provider注冊向磁盤文件寫入，consumer訂閱即讀取磁盤文件，當(dāng)磁盤文件有變更時通知consumer，大概是這么個樣子：

這樣設(shè)計有什么好處呢?

• 不依賴其他服務(wù)，只是文件的讀寫，不會阻塞應(yīng)用啟動。
• consumer和provider都在本地時，可以像其他注冊中心(如zk、nacos等)一樣工作，對開發(fā)者完全透明。
• 可以手動修改、指定調(diào)用任意provider。

唯一的缺點是，無法發(fā)現(xiàn)遠(yuǎn)程的provider，但我們可以手動指定，也算是沒有大礙。

我們以dubbo 2.7.x版本的接口級服務(wù)發(fā)現(xiàn)來設(shè)計我們的產(chǎn)品，因為這個版本使用的最多。

首先要考慮的是如何去組織服務(wù)發(fā)現(xiàn)文件，由于是接口級服務(wù)發(fā)現(xiàn)，我們就按服務(wù)名來作為文件名，每個服務(wù)一個文件：

其次每個文件的內(nèi)容怎么組織?最簡單的就是將dubbo注冊的URL直接寫入文件，每行一個URL，就像這樣：

但你可能發(fā)現(xiàn)了問題，這dubbo的URL有點長啊~如果讓我手動指定，豈不是很難做到?

這個問題好解決，我們實現(xiàn)一個簡寫版本的URL，比如有一行這樣簡寫，就將它還原為一個可用的URL。

127.0.0.1:20880

代碼實現(xiàn)

在實現(xiàn)之前首先要了解的是dubbo注冊中心擴(kuò)展是如何編寫的，這塊直接看官方文檔：

https://dubbo.apache.org/zh/docs/v2.7/dev/impls/registry/

雖然我覺得看完了文檔你也不一定能實現(xiàn)一個dubbo注冊中心擴(kuò)展，但別慌，先往下看，說不定看完了本文你也能自己寫一個。

先看一下代碼結(jié)構(gòu)：

• 項目命名為：dubbo-registry-mock，和dubbo源碼中的命名風(fēng)格保持一致。
• MockRegistry是注冊中心的核心實現(xiàn)。
• MockRegistryFactory是mock registry的工廠，dubbo會通過這個類來創(chuàng)建MockRegistry。
• org.apache.dubbo.registry.RegistryFactory這個文件是指定MockRegistryFactory該如何加載，即dubbo的SPI發(fā)現(xiàn)文件。

dubbo的注冊中心配置只需要改成：

dubbo.registry.address=mock://127.0.0.1:2181

這里起作用的只有mock，ip、port并不重要，只是占個位置。

當(dāng)dubbo應(yīng)用啟動時，讀取到配置的mock，會查找resources/META-INF.dubbo下的org.apache.dubbo.registry.RegistryFactory文件，這里它的內(nèi)容為：

mock=org.newboo.MockRegistryFactory

于是去new出一個MockRegistryFactory。

注：newboo.org是我曾經(jīng)注冊的一個域名，用來放博客，不過后來沒有續(xù)費，現(xiàn)在我的測試代碼中經(jīng)常會出現(xiàn)這個包名。

MockRegistryFactory也很簡單，直接new一個MockRegistry：

public class MockRegistryFactory extends AbstractRegistryFactory {

    @Override
    protected Registry createRegistry(URL url) {
        return new MockRegistry(url);
    }
}

最后看核心的實現(xiàn)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);
}

這個構(gòu)造方法，做了3件事情：

• 獲取basePath，也就是服務(wù)發(fā)現(xiàn)的文件夾基礎(chǔ)路徑，有個默認(rèn)值，也可以根據(jù)url的參數(shù)進(jìn)行調(diào)整，如：

dubbo.registry.address=mock://127.0.0.1:2181?discovery_file=/tmp/mock-registry2

• new一個MockService，承載了核心的服務(wù)發(fā)現(xiàn)邏輯，后面再說。
• 啟動一個定時任務(wù)，每隔5秒去掃描一次文件，看文件是否有變化，如果有變化則通知consumer，詳細(xì)后面也會說。

MockRegistry繼承自FailbackRegistry，只需要實現(xiàn)它的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刪除，再把剩余內(nèi)容覆蓋寫回文件即可：

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(見上文)，文件是否有變更直接根據(jù)文件的最后更新時間來判斷，精確到毫秒，本地測試也夠用了：

 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只需要把已經(jīng)訂閱的接口拿出來，執(zhí)行一次doSubscribe即可：

public class SubscribeScan implements Runnable {
    @Override
    public void run() {
        try {
            // 已經(jīng)訂閱的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
        }
    }
}

看到這里可能有的同學(xué)問，為啥要輪詢，不用WatchService監(jiān)聽文件的變更呢?我寫的時候也查了一下，并且debug了一下，發(fā)現(xiàn)WatchService的真實實現(xiàn)是PollingWatchService，而且它也是采用輪詢來實現(xiàn)的，不信可以打開這個類看看。

感覺和自己寫沒啥差別，所以我就自己寫了。

完整代碼已經(jīng)上傳到了github：https://github.com/lkxiaolou/dubbo-registry-mock。

為了讓這個項目看起來更飽滿一點，還寫了一個README：

最后

如果你耐心看完了本文，且對dubbo有所了解，我相信你已經(jīng)能自己寫一個dubbo注冊中心擴(kuò)展。

如果你也經(jīng)常在本地做測試，也可以用我寫的這個mock registry來試試，當(dāng)然代碼和想法都有改進(jìn)的地方，如果你有更好的想法也可以和我交流。