hello大家好呀，我是小樓。

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

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

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

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

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

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

看到2181端口就知道這是本地沒(méi)有裝zookeeper(下文簡(jiǎn)稱(chēng)zk)，問(wèn)題不大，docker直接拉一個(gè)zk鏡像，起個(gè)容器就完事。

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

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

這時(shí)，我陷入了思考，能不能少跑點(diǎn)程序?

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

需求梳理

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

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

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

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

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

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

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

調(diào)研

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

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

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

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

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

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

provider注冊(cè)向磁盤(pán)文件寫(xiě)入，consumer訂閱即讀取磁盤(pán)文件，當(dāng)磁盤(pán)文件有變更時(shí)通知consumer，大概是這么個(gè)樣子：

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

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

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

我們以dubbo 2.7.x版本的接口級(jí)服務(wù)發(fā)現(xiàn)來(lái)設(shè)計(jì)我們的產(chǎn)品，因?yàn)檫@個(gè)版本使用的最多。

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

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

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

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

127.0.0.1:20880

代碼實(shí)現(xiàn)

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

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

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

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

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

dubbo的注冊(cè)中心配置只需要改成：

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

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

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

mock=org.newboo.MockRegistryFactory

于是去new出一個(gè)MockRegistryFactory。

注：newboo.org是我曾經(jīng)注冊(cè)的一個(gè)域名，用來(lái)放博客，不過(guò)后來(lái)沒(méi)有續(xù)費(fèi)，現(xiàn)在我的測(cè)試代碼中經(jīng)常會(huì)出現(xiàn)這個(gè)包名。

MockRegistryFactory也很簡(jiǎn)單，直接new一個(gè)MockRegistry：

public class MockRegistryFactory extends AbstractRegistryFactory {

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

最后看核心的實(shí)現(xiàn)MockRegistry類(lèi)：

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è)構(gòu)造方法，做了3件事情：

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

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

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

MockRegistry繼承自FailbackRegistry，只需要實(shí)現(xiàn)它的doRegister、doUnregister、doSubscribe、doUnsubscribe、isAvailable幾個(gè)方法即可。

其中isAvailable是判斷注冊(cè)中心是否可用，我們直接返回true即可。

doUnsubscribe是取消訂閱，這里也啥都不用干，剩下3個(gè)方法我們將邏輯封裝在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());

    // 寫(xiě)入文件
    String line = url.toFullString();
    FileUtil.appendLine(fileName, line);
}

removeUrl先讀取文件，把要注銷(xiāo)的URL刪除，再把剩余內(nèi)容覆蓋寫(xiě)回文件即可：

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格式化后返回，之所以要格式化是因?yàn)榭赡軙?huì)有簡(jiǎn)寫(xiě)的URL(見(jiàn)上文)，文件是否有變更直接根據(jù)文件的最后更新時(shí)間來(lái)判斷，精確到毫秒，本地測(cè)試也夠用了：

 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，說(shuō)明文件沒(méi)有變更，直接忽略本次掃描。

最后一個(gè)SubscribeScan只需要把已經(jīng)訂閱的接口拿出來(lái)，執(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é)問(wèn)，為啥要輪詢(xún)，不用WatchService監(jiān)聽(tīng)文件的變更呢?我寫(xiě)的時(shí)候也查了一下，并且debug了一下，發(fā)現(xiàn)WatchService的真實(shí)實(shí)現(xiàn)是PollingWatchService，而且它也是采用輪詢(xún)來(lái)實(shí)現(xiàn)的，不信可以打開(kāi)這個(gè)類(lèi)看看。

感覺(jué)和自己寫(xiě)沒(méi)啥差別，所以我就自己寫(xiě)了。

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

為了讓這個(gè)項(xiàng)目看起來(lái)更飽滿(mǎn)一點(diǎn)，還寫(xiě)了一個(gè)README：

最后

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

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