上篇文章如果有人問你 Dubbo 中註冊中心工作原理，就把這篇文章給他大致瞭解了註冊中心作用以及 Dubbo Registry 模組原始碼，這篇文章將深入 Dubbo ZooKeeper 模組，去了解如何實現服務動態的發現。

ps: 以下將 ZooKeeper 縮寫為 zk。

一、dubbo zk 資料結構

在 ZooKeeper 基本概念分享一文講道，ZK 內部是一種樹形層次結構，節點存在多種型別。而 Dubbo 只會建立持久節點和臨時節點。

若服務提供者服務介面為 com.service.FooService，將會在 ZK 中建立建立如下路徑 /dubbo/com.service.FooService/providers/providerURL

。

服務路徑分為四層，根節點預設為 dubbo，可以在 dubbo-registry 設定 group 屬性改變該值。

ps: 若無註冊中心隔離需求，不要隨便修改。

第二層節點為服務節點全名稱，如 com.service.FooService。

第三層節點為服務目錄，如 providers。另外還存在其他目錄節點，分別為 consumers（消費者目錄），configurators（配置目錄），routers（路由目錄）。下面服務訂閱主要針對這一層節點。

第四個節點為具體服務節點，節點名為具體的 URL 字串，如 dubbo://2.0.1.13:12345/com.dubbo.example.DemoService?xx=xx

，該節點預設為臨時節點。
dubbo ZK 樹形內部結構示例為：

ZK 內部服務具體示例如下：

二、RegistryFactory 實現

Dubbo 可以在配置檔案中指定使用註冊中心，可以使用 dubbo.registry.protocol 指定具體註冊中心型別，也可以設定 dubbo.registry.address 指定。註冊中心相關實現將會使用 RegistryFactory 工廠類建立。

RegistryFactory 介面原始碼如下:

@SPI("dubbo")
public interface RegistryFactory {
    @Adaptive({"protocol"})
    Registry getRegistry(URL url);
}
 

RegistryFactory 介面方法使用 @Adaptive 註解，這裡將會使用 Dubbo SPI 機制，自動生成程式碼的一些實現邏輯。這裡將會根據 URL 中 protocol 屬性，去呼叫最終實現子類。

RegistryFactory 實現子類如圖所示：

AbstractRegistryFactory 將會實現介面的 getRegistry 方法，主要完成加鎖，並呼叫抽象模板方法 createRegistry 建立具體註冊中心實現類，並將其快取在記憶體中。

AbstractRegistryFactory#getRegistry 原始碼如下所示：

    public Registry getRegistry(URL url) {
        url = URLBuilder.from(url)
                .setPath(RegistryService.class.getName())
                .addParameter(Constants.INTERFACE_KEY, RegistryService.class.getName())
                .removeParameters(Constants.EXPORT_KEY, Constants.REFER_KEY)
                .build();
        String key = url.toServiceStringWithoutResolving();
        // 加鎖，防止併發
        LOCK.lock();
        try {
        // 先從快取中取
            Registry registry = REGISTRIES.get(key);
            if (registry != null) {
                return registry;
            }
            //使用 Dubbo SPI 進位制建立
            registry = createRegistry(url);
            if (registry == null) {
                throw new IllegalStateException("Can not create registry " + url);
            }
        // 放入快取
            REGISTRIES.put(key, registry);
            return registry;
        } finally {
            // Release the lock
            LOCK.unlock();
        }
    }

註冊中心例項將會通過具體工廠類建立，這裡我們看下 ZookeeperRegistryFactory 原始碼：

public class ZookeeperRegistryFactory extends AbstractRegistryFactory {

    private ZookeeperTransporter zookeeperTransporter;

    /**
     * 通過 Dubbo SPI 進位制注入
     * @param zookeeperTransporter
     */
    public void setZookeeperTransporter(ZookeeperTransporter zookeeperTransporter) {
        this.zookeeperTransporter = zookeeperTransporter;
    }

    @Override
    public Registry createRegistry(URL url) {
        return new ZookeeperRegistry(url, zookeeperTransporter);
    }

}

ps：Dubbo SPI 機制還具有 IOC 特性，這裡的ZookeeperTransporter 注入可以參考：Dubbo 擴充套件點載入

三、zk 模組原始碼解析

講完註冊中心例項建立過程，下面深入 ZookeeperRegistry 實現原始碼。

ZookeeperRegistry 繼承 FailbackRegistry抽象類，所以其需要實現其父類抽象模板方法，下面主要了解 doRegister 與 doSubscribe原始碼 。

3.1 doRegister

服務提供者需要將服務註冊到註冊中心，註冊的目的是為了讓消費者感知到服務的存在，從而發起遠端呼叫，另一方面也讓服務治理中心感知新的服務提供者上線。zk 模組服務註冊程式碼比較簡單，直接使用 zk 客戶端在註冊中心建立節點。

ZookeeperRegistry#doRegister 實現原始碼如下：

    public void doRegister(URL url) {
        try {
            zkClient.create(toUrlPath(url), url.getParameter(Constants.DYNAMIC_KEY, true));
        } catch (Throwable e) {
            throw new RpcException("Failed to register " + url + " to zookeeper " + getUrl() + ", cause: " + e.getMessage(), e);
        }
    }

zkClient.create 方法需要傳入兩個引數。

void create(String path, boolean ephemeral);

第一個引數為節點路徑，將會通過 toUrlPath 將 URL 例項轉化成 ZK 中路徑格式，轉化結果如下：

## 轉化前 URL 如下：

dubbo://10.20.82.31:12345/com.dubbo.example.DemoService

## 呼叫  `toUrlPath`  轉換之後
/dubbo/com.dubbo.example.DemoService/providers/dubbo%3A%2F%2F10.20.82.31%3A12345%2Fcom.dubbo.example.DemoService

第二個引數主要決定 ZK 節點型別主要取自 URL 例項物件中 dynamic 引數值，若不存在，預設為 true，也就是預設將會建立臨時節點。

zkClient.create 方法裡將會遞迴呼叫，首先父節點是否存在，不存在就會建立，直到最後一個節點跳出遞迴方法。

    public void create(String path, boolean ephemeral) {
    // 建立永久節點之前需要判斷是否已存在
        if (!ephemeral) {
            if (checkExists(path)) {
                return;
            }
        }
    // 判斷是否存在父節點
        int i = path.lastIndexOf('/');
        if (i > 0) {
       // 遞迴建立父節點
            create(path.substring(0, i), false);
        }
        if (ephemeral) {
        // 建立臨時節點
            createEphemeral(path);
        } else {
       // 建立永久節點
            createPersistent(path);
        }
    }

最後 createEphemeral 與 createPersistent 實際建立節點操作將會交給 ZK 客戶端類，這裡實現比較簡單，可以自行參考原始碼。

ps: dubbo 在 2.6.1 起將 zk 客戶端預設使用 Curator，之前版本使用 zkclient。dubbo 2.7.1 開始去除 zkclient 實現，也就是說只能使用 Curator 。

3.2 為何 dubbo 服務提供者節點使用 zk 臨時節點

zk 臨時節點將會在 zk 客戶端斷開後，自動刪除。dubbo 服務提供者正常下線，其會主動刪除 zk 服務節點。

如果服務異常宕機，zk 服務節點就不能正常刪除，這就導致失效的服務一直存在 ZK 上，消費者還會呼叫該失效節點，導致消費者報錯。通過 zk 臨時節點特性，讓 zk 服務端主動刪除失效節點，從而下線失效服務。

四、doSubscribe: 服務動態發現的原理

4.1 訂閱基本原理

服務訂閱通常有 pull 和 push 兩種方式。pull 模式需要客戶端定時向註冊中心拉取配置，而 push 模式採用註冊中心主動推送資料給客戶端。

dubbo zk 註冊中心採用是事件通知與客戶端拉取方式。服務第一次訂閱的時候將會拉取對應目錄下全量資料，然後在訂閱的節點註冊一個 watcher。一旦目錄節點下發生任何資料變化，zk 將會通過 watcher 通知客戶端。客戶端接到通知，將會重新拉取該目錄下全量資料，並重新註冊 watcher。利用這個模式，dubbo 服務就可以就做到服務的動態發現。

4.2 原始碼解析

講完訂閱的基本原理，接著深入原始碼。

doSubscribe 方法需要傳入兩個引數，一個為 URL 例項，另一個為 NotifyListener，變更事件的監聽器。 方法內部會根據 URL 介面型別分成兩部分邏輯，全量訂閱服務與部分類別訂閱服務。

doSubscribe 方法整體原始碼邏輯：

    public void doSubscribe(final URL url, final NotifyListener listener) {
        if (Constants.ANY_VALUE.equals(url.getServiceInterface())) {
        // 全量訂閱邏輯
        } else {
        // 部分類別訂閱邏輯
        }
    }

服務治理中心(dubbo-admin)，需要訂閱 service 全量介面，用以感知每個服務的狀態，所以訂閱之前將會把 service 設定成 *，處理所有service。

服務消費者或服務提供者將會走部分類別訂閱服務，下面我們以消費者視角，深入後續原始碼。

文章剛開頭講道了 zk 目錄節點存在四種類型，這裡將會根據 根據 URL 中 category值，決定訂閱節點路徑。

服務提供者 URL 中 category值預設為 configurators，而消費者 URL 中category值預設為 providers,configurators,routers。如果 category類別值為 *，將會訂閱四種類別路徑，否則將會只訂閱 providers型別的路徑。

toCategoriesPath 原始碼如下：

    private String[] toCategoriesPath(URL url) {
        String[] categories;
    // 如果類別為 *，訂閱四種類型的全量資料
        if (Constants.ANY_VALUE.equals(url.getParameter(Constants.CATEGORY_KEY))) {
            categories = new String[]{Constants.PROVIDERS_CATEGORY, Constants.CONSUMERS_CATEGORY,
                    Constants.ROUTERS_CATEGORY, Constants.CONFIGURATORS_CATEGORY};
        } else {
            categories = url.getParameter(Constants.CATEGORY_KEY, new String[]{Constants.DEFAULT_CATEGORY});
        }
    // 返回路徑陣列
        String[] paths = new String[categories.length];
        for (int i = 0; i < categories.length; i++) {
            paths[i] = toServicePath(url) + Constants.PATH_SEPARATOR + categories[i];
        }
        return paths;
    }

接著迴圈路徑陣列，迴圈內將會快取節點監聽器，用以提高效能。

    // 迴圈路徑陣列
    for (String path : toCategoriesPath(url)) {
        ConcurrentMap<NotifyListener, ChildListener> listeners = zkListeners.get(url);
        // listeners  快取為空，建立快取
        if (listeners == null) {
            zkListeners.putIfAbsent(url, new ConcurrentHashMap<>());
            listeners = zkListeners.get(url);
        }
        ChildListener zkListener = listeners.get(listener);
        // zkListener  快取為空則建立快取
        if (zkListener == null) {
            listeners.putIfAbsent(listener, (parentPath, currentChilds) -> ZookeeperRegistry.this.notify(url, listener, toUrlsWithEmpty(url, parentPath, currentChilds)));
            zkListener = listeners.get(listener);
        }
        // 建立訂閱節點
        zkClient.create(path, false);
        // 使用 ZK 客戶端訂閱節點
        List<String> children = zkClient.addChildListener(path, zkListener);
        if (children != null) {
            // 儲存全量需要通知的 URL
            urls.addAll(toUrlsWithEmpty(url, path, children));
        }
    }
    // 回撥 NotifyListener
    notify(url, listener, urls);

最終將會使用 CuratorClient.getChildren().usingWatcher(listener).forPath(path) 在 ZK 節點註冊 watcher，並獲取目錄節點下所有子節點資料。

這裡 watcher 使用 Curator 介面 CuratorWatcher，一旦 ZK 節點發生會變化，將會回撥 CuratorWatcher#process 方法。

CuratorWatcher#process 方法原始碼如下：

        public void process(WatchedEvent event) throws Exception {
            if (childListener != null) {
                String path = event.getPath() == null ? "" : event.getPath();
                childListener.childChanged(path,
                       // 重新設定 watcher，並獲取節點下所有子節點
                        StringUtils.isNotEmpty(path)
                                ? client.getChildren().usingWatcher(this).forPath(path)
                                : Collections.<String>emptyList());
            }
        }

消費者訂閱時序圖如下：

4.3 listener 關係圖

訂閱方法中我們碰到了多個 listener類，剛開始理解時候可能有點亂。可以參考下面關係圖理清楚這其中的關係。

listener 關係圖如下：

回撥關係如圖所示：

4.4 ZK 模組訂閱存在問題

ZK 第一次訂閱將會獲得目錄節點下所有子節點，後續任意子節點變更，將會通過 watcher 進位制回撥通知。回撥通知將會再次全量拉取節點目錄下所有子節點。這樣全量拉取將會有個侷限，當服務節點較多時將會對網路造成很大的壓力。

Dubbo 2.7 之後版本引入元資料中心解決該問題，詳情可參考，阿里技術專家詳解 Dubbo 實踐，演進及未來規劃。

引用文中一種解決方案如下圖:

總結

本文主要介紹了 dubbo zk 的資料結構，其次深入研究 ZookeeperRegistry 相關實現原始碼。通過了解服務註冊以及訂閱原理，瞭解 Dubbo 服務動態發現實現方式。

相關推薦