背景
最近在做分散式相關的工作，由於人手不夠只能我一個人來懟；看著這段時間的加班表想想就是夠慘的。
不過其中也有遇到的不少有意思的事情今後再拿來分享，今天重點來討論服務的註冊與發現。
分散式帶來的問題
我的業務比較簡單，只是需要知道現在有哪些服務例項可供使用就可以了（並不是做遠端呼叫，只需要拿到資訊即可）。
要實現這一功能最簡單的方式可以在應用中配置所有的服務節點，這樣每次在使用時只需要通過某種演算法從配置列表中選擇一個就可以了。
但這樣會有一個非常嚴重的問題：
由於應用需要根據應用負載情況來靈活的調整服務節點的數量，這樣我的配置就不能寫死。
不然就會出現要麼新增的節點沒有訪問或者是已經 down 掉的節點卻有請求，這樣肯定是不行的。
往往要解決這類分散式問題都需要一個公共的區域來儲存這些資訊，比如是否可以利用 Redis？
每個節點啟動之後都向 Redis 註冊資訊，關閉時也刪除資料。
其實就是存放節點的 ip + port，然後在需要知道服務節點資訊時候只需要去 Redis 中獲取即可。
如下圖所示：
但這樣會導致每次使用時都需要頻繁的去查詢 Redis，為了避免這個問題我們可以在每次查詢之後在本地快取一份最新的資料。這樣優先從本地獲取確實可以提高效率。
但同樣又會出現新的問題，如果服務提供者的節點新增或者刪除消費者這邊根本就不知道情況。
要解決這個問題最先想到的應該就是利用定時任務定期去更新服務列表。
以上的方案肯定不完美，並且不優雅。主要有以下幾點：
- 基於定時任務會導致很多無效的更新。
- 定時任務存在週期性，沒法做到實時，這樣就可能存在請求異常。
- 如果服務被強行 kill，沒法及時清除 Redis，這樣這個看似可用的服務將永遠不可用！
所以我們需要一個更加靠譜的解決方案，這樣的場景其實和 Dubbo 非常類似。
用過的同學肯定對這張圖不陌生。
引用自 Dubbo 官網
其中有一塊非常核心的內容（紅框出）就是服務的註冊與發現。
通常來說消費者是需要知道服務提供者的網路地址(ip + port)才能發起遠端呼叫，這塊內容和我上面的需求其實非常類似。
而 Dubbo 則是利用 Zookeeper 來解決問題。
Zookeeper 能做什麼
在具體討論怎麼實現之前先看看 Zookeeper 的幾個重要特性。
Zookeeper 實現了一個類似於檔案系統的樹狀結構：
這些節點被稱為 znode(名字叫什麼不重要)，其中每個節點都可以存放一定的資料。
最主要的是 znode 有四種型別：
- 永久節點（除非手動刪除，節點永遠存在）
- 永久有序節點（按照建立順序會為每個節點末尾帶上一個序號如：
root-1） - 瞬時節點（建立客戶端與 Zookeeper 保持連線時節點存在，斷開時則刪除並會有相應的通知）
- 瞬時有序節點（在瞬時節點的基礎上加上了順序）
考慮下上文使用 Redis 最大的一個問題是什麼？
其實就是不能實時的更新服務提供者的資訊。
那利用 Zookeeper 是怎麼實現的？
主要看第三個特性：瞬時節點
Zookeeper 是一個典型的觀察者模式。
- 由於瞬時節點的特點，我們的消費者可以訂閱瞬時節點的父節點。
- 當新增、刪除節點時所有的瞬時節點也會自動更新。
- 更新時會給訂閱者發起通知告訴最新的節點資訊。
這樣我們就可以實時獲取服務節點的資訊，同時也只需要在第一次獲取列表時快取到本地；也不需要頻繁和 Zookeeper 產生互動，只用等待通知更新即可。
並且不管應用什麼原因節點 down 掉後也會在 Zookeeper 中刪除該資訊。
效果演示
這樣實現方式就變為這樣。
為此我新建了一個應用來進行演示：
就是一個簡單的 SpringBoot 應用，只是做了幾件事情。
- 應用啟動時新開一個執行緒用於向 Zookeeper 註冊服務。
- 同時監聽一個節點用於更新本地服務列表。
- 提供一個介面用於返回一個可有的服務節點。
我在本地啟動了兩個應用分別是：127.0.0.1:8083,127.0.0.1:8084。來看看效果圖。
兩個應用啟動完成：
當前 Zookeeper 的視覺化樹狀結構：
當想知道所有的服務節點資訊時：
想要獲取一個可用的服務節點時：
這裡只是採取了簡單的輪詢。
當 down 掉一個節點時：應用會收到通知更新本地快取。同時 Zookeeper 中的節點會自動刪除。
再次獲取最新節點時：
當節點恢復時自然也能獲取到最新資訊。本地快取也會及時更新。
編碼實現
實現起來倒也比較簡單，主要就是 ZKClient 的 api 使用。
貼幾段比較核心的吧。
註冊
啟動註冊 Zookeeper。
主要邏輯都在這個執行緒中。
- 首先建立父節點。如上圖的 Zookeeper 節點所示；需要先建立
/route根節點，建立的時候會判斷是否已經存在。 - 接著需要判斷是否需要將自己註冊到 Zookeeper 中，因為有些節點只是用於服務發現，他自身是不需要承擔業務功能（是我自己專案的需求）。
- 將當前應用的所在 ip 以及埠註冊上去，同時需要監聽根節點
/route，這樣才能在其他服務上下線時候獲得通知。
根據本地快取
監聽到服務變化
public void subscribeEvent(String path) {
zkClient.subscribeChildChanges(path, new IZkChildListener() {
@Override
public void handleChildChange(String parentPath, List<String> currentChilds) throws Exception {
logger.info("清除/更新本地快取 parentPath=【{}】,currentChilds=【{}】", parentPath,currentChilds.toString());
//更新所有快取/先刪除 再新增
serverCache.updateCache(currentChilds) ;
}
});
}
複製程式碼可以看到這裡是更新了本地快取，該快取採用了 Guava 提供的 Cache，感興趣的可以檢視之前的原始碼分析。
/**
* 更新所有快取/先刪除 再新增
*
* @param currentChilds
*/
public void updateCache(List<String> currentChilds) {
cache.invalidateAll();
for (String currentChild : currentChilds) {
String key = currentChild.split("-")[1];
addCache(key);
}
}
複製程式碼客戶端負載
同時在客戶端提供了一個負載演算法。
其實就是一個輪詢的實現：
/**
* 選取伺服器
*
* @return
*/
public String selectServer() {
List<String> all = getAll();
if (all.size() == 0) {
throw new RuntimeException("路由列表為空");
}
Long position = index.incrementAndGet() % all.size();
if (position < 0) {
position = 0L;
}
return all.get(position.intValue());
}
複製程式碼當然這裡可以擴充套件出更多的如權重、隨機、LRU 等演算法。
Zookeeper 其他優勢及問題
Zookeeper 自然是一個很棒的分散式協調工具，利用它的特性還可以有其他作用。
- 資料變更傳送通知這一特性可以實現統一配置中心，再也不需要在每個服務中單獨維護配置。
- 利用瞬時有序節點還可以實現分散式鎖。
在實現註冊、發現這一需求時，Zookeeper 其實並不是最優選。
由於 Zookeeper 在 CAP 理論中選擇了 CP（一致性、分割槽容錯性），當 Zookeeper 叢集有半數節點不可用時是不能獲取到任何資料的。
對於一致性來說自然沒啥問題，但在註冊、發現的場景下更加推薦 Eureka，已經在 SpringCloud 中得到驗證。具體就不在本文討論了。
但鑑於我的使用場景來說 Zookeeper 已經能夠勝任。
總結
本文所有完整程式碼都託管在 GitHub。
一個看似簡單的註冊、發現功能實現了，但分散式應用遠遠不止這些。
由於網路隔離之後帶來的一系列問題還需要我們用其他方式一一完善；後續會繼續更新分散式相關內容，感興趣的朋友不妨持續關注。
你的點贊與轉發是最大的支援。
