上篇文章若是有人問你 Dubbo 中註冊中心工做原理,就把這篇文章給他大體瞭解了註冊中心做用以及 Dubbo Registry 模塊源碼,這篇文章將深刻 Dubbo ZooKeeper 模塊,去了解如何實現服務動態的發現。html
ps: 如下將 ZooKeeper 縮寫爲 zk。
在 ZooKeeper 基本概念分享一文講道,ZK 內部是一種樹形層次結構,節點存在多種類型。而 Dubbo 只會建立持久節點和臨時節點。java
若服務提供者服務接口爲 com.service.FooService
,將會在 ZK 中建立建立以下路徑 /dubbo/com.service.FooService/providers/providerURL
。apache
服務路徑分爲四層,根節點默認爲 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 內部服務具體示例以下:併發
Dubbo 能夠在配置文件中指定使用註冊中心,可使用 dubbo.registry.protocol
指定具體註冊中心類型,也能夠設置 dubbo.registry.address
指定。註冊中心相關實現將會使用 RegistryFactory
工廠類建立。ide
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 擴展點加載
講完註冊中心實例建立過程,下面深刻 ZookeeperRegistry
實現源碼。
ZookeeperRegistry
繼承 FailbackRegistry
抽象類,因此其須要實現其父類抽象模板方法,下面主要了解 doRegister
與 doSubscribe
源碼 。
服務提供者須要將服務註冊到註冊中心,註冊的目的是爲了讓消費者感知到服務的存在,從而發起遠程調用,另外一方面也讓服務治理中心感知新的服務提供者上線。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 。
zk 臨時節點將會在 zk 客戶端斷開後,自動刪除。dubbo 服務提供者正常下線,其會主動刪除 zk 服務節點。
若是服務異常宕機,zk 服務節點就不能正常刪除,這就致使失效的服務一直存在 ZK 上,消費者還會調用該失效節點,致使消費者報錯。經過 zk 臨時節點特性,讓 zk 服務端主動刪除失效節點,從而下線失效服務。
服務訂閱一般有 pull 和 push 兩種方式。pull 模式須要客戶端定時向註冊中心拉取配置,而 push 模式採用註冊中心主動推送數據給客戶端。
dubbo zk 註冊中心採用是事件通知與客戶端拉取方式。服務第一次訂閱的時候將會拉取對應目錄下全量數據,而後在訂閱的節點註冊一個 watcher。一旦目錄節點下發生任何數據變化,zk 將會經過 watcher 通知客戶端。客戶端接到通知,將會從新拉取該目錄下全量數據,並從新註冊 watcher。利用這個模式,dubbo 服務就能夠就作到服務的動態發現。
講完訂閱的基本原理,接着深刻源碼。
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()); } }
消費者訂閱時序圖以下:
訂閱方法中咱們碰到了多個 listener
類,剛開始理解時候可能有點亂。能夠參考下面關係圖理清楚這其中的關係。
listener
關係圖以下:
回調關係如圖所示:
ZK 第一次訂閱將會得到目錄節點下全部子節點,後續任意子節點變動,將會經過 watcher 進制回調通知。回調通知將會再次全量拉取節點目錄下全部子節點。這樣全量拉取將會有個侷限,當服務節點較多時將會對網絡形成很大的壓力。
Dubbo 2.7 以後版本引入元數據中心解決該問題,詳情可參考,阿里技術專家詳解 Dubbo 實踐,演進及將來規劃。
引用文中一種解決方案以下圖:
本文主要介紹了 dubbo zk 的數據結構,其次深刻研究 ZookeeperRegistry
相關實現源碼。經過了解服務註冊以及訂閱原理,瞭解 Dubbo 服務動態發現實現方式。