目標
- bootstrap zk客戶端啟動流程
- zk 如何接收數據變動
- 接收到數據變動之后的處理流程
- 總結
bootstrap端zk客戶端啟動流程
前面我們知道soul的各種插件啟動基本流程是通過自定義starter啟動,然后內部做一系列的依賴注入，zk Client 也不例外,下面就看看源碼吧。
image.png
ZookeeperSyncDataConfiguration實例化
- SyncDataService Bean注入
image.png
通過代碼我們可以看出來這里面也使用了Spring4.3新特性 ObjectProvider Bean依賴查找注入。確實經過debug 知道執行順序是先執行了syncDataService,發現在構造器方式注入時候zkClient還未初始化,緊接著就執行了下面的zkClient注入。這里也就是初始化一個zk客戶端。使用我們配置的zk客戶端url還有會話超時時間和連接超時時間。
image.png
ZookeeperSyncDataService初始化
image.png
這里面主要就是全量給需要關心的節點增加watch機制。這里有個巧妙設計地方。因為zk的watch 觸發完之后下次還要監聽必須要再次設置watch,soul這邊就每次觸發數據變動，就先watch 然后在處理事件。
zk 如何接收數據變動
private void watcherPlugin(final String pluginName) {
String pluginPath = ZkPathConstants.buildPluginPath(pluginName);
if (!zkClient.exists(pluginPath)) {
zkClient.createPersistent(pluginPath, true);
}
cachePluginData(zkClient.readData(pluginPath));
// 這里就是綁定watch事件觸發之后處理的方法
subscribePluginDataChanges(pluginPath, pluginName);
}
通過zk的watcher機制，先將需要關注的節點綁定watcher,并指定執行方法
接收到數據變動之后的處理流程
image.png
handleDataChange 就是當watch觸發時候 就會執行這里。前面分析過,websocket與subscribe綁定。所以這里面也一樣，到這步后面就與websocket處理流程一樣的了。
總結
到這里zk如何接收到數據同時如何保持watcher一直存在,并且如何更新對應關心數據的Plugin。我想經過兩個同步類型工具流程分析，大家都清楚了吧。我再來總結下，admin 主要通過ApplicationEvent 發送數據變動事件，然后通過具體通信插件將數據告知網關端，網關通過訂閱模式將信息告知對應關心數據的通信協議插件。
