RPC框架原理及從零實現系列博客(三):zookeeper註冊中心原理

時間 2019-12-04

標籤 rpc 框架原理實現系列博客 zookeeper 註冊中心欄目微服務简体版

原文原文鏈接

前面的文章中我用netty實現了一個簡單的一對一的RPCjava

11個類實現簡單java rpcnode

接下來的文章中我將使用zookeeper做爲rpc調用的分佈式註冊中心 從而實現多對多(多個調用者，多個提供者)的rpc調用，負載均衡及相應的分佈式協調功能linux

首先簡單介紹下zookeeper

zookeeper是hadoop中一個重要組件，其主要是做爲分佈式協調服務
zookeeper採用節點樹的數據模型，相似linux文件系統，/，/app1，/app2 比較簡單
git

每一個節點稱作一個ZNode。每一個ZNode均可以經過其路徑惟一標識，同時每一個節點還能夠存儲少許數據。
節點可分爲常規節點，臨時節點和順序節點
還有兩個比較重要的東西 session和watchergithub

session:

每一個zk客戶端與zk鏈接時會建立一個session，在設置的sessionTimeOut內，客戶端會與zk進行心跳包的定時發送，從而感知每一個客戶端是否宕機，若是建立某個臨時Znode的對應session銷燬時，相應的臨時節點也會被zk刪除。redis

watcher:

監聽機制，監聽某個Znode 當該znode發生變化時，會回調該watcher，可是這個watcher是一次性的，下次須要監聽時還得再註冊一次。segmentfault

固然這幾個只是zookeeper的各類特性之一，能實現註冊中心的也不止zookeeper(例如redis)，註冊中心也只是zk的功能之一，還有互斥鎖，樂觀鎖，命名服務等也是zk能實現的，本文只講述rpc框架須要的3個重要內容
臨時節點，session，watcher其他內容請讀者自行查閱網絡

這是dubbo框架的註冊中心數據模型

zookeeper註冊中心思路以下

(這是個人思路可能沒和dubbo框架如出一轍)session

服務名稱做爲次級znode，下層的znode爲對應的類型，調用者仍是提供者app

對應的類型下面是他們的URL 即對應機器的IP地址 URL這個znode爲臨時節點

提供者服務啓動後向zookeeper註冊他有的services，並將本身的ip地址和端口做爲路徑，建立對應的URL臨時節點
調用者調用相應服務時，找到對應的service節點，得到service全部的子節點，而且watch service節點,而後一樣註冊本身的znode節點
每一個調用端需明確提供者和調用者的數量以及提供者相應的IP地址
以後調用端得到 service/providers的全部子節點即得到全部的提供者的IP 使用對應負載均衡策略鏈接其中一個ip地址，進行rpc調度
當提供者或調用者出現宕機或者網絡故障時，對應session的臨時znode會被銷燬，即哪一個IP的機子宕機了，他對應的url節點在sessionTimeOut後，就會被銷燬，此時因爲service節點已發生了變化，全部可用調用者都會收到watcher的通知，此時從新得到全部的調用者提供者IP及其數量，並繼續監聽，從而悉知調用端和服務端的服務可用狀況。