靈感乍現！造了個與眾不同的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來試試，當然代碼和想法都有改進的地方，如果你有更好的想法也可以和我交流，

最后，這應該是勞動節前的最后一篇文章，寫文不易，來點正向反饋，點贊+在看+分享，我會寫得更有勁~我們下期再見，

搜索關注微信公眾號"捉蟲大師"，后端技術分享，架構設計、性能優化、原始碼閱讀、問題排查、踩坑實踐，

轉載請註明出處，本文鏈接：https://www.uj5u.com/houduan/466940.html

標籤：Java

上一篇：windows電腦上安裝maven的方法分享

下一篇：Spring5