對微服務稍有了解的小伙伴應該都聽說過 Zookeeper，我們來看看在官網(wǎng)上是如何介紹的：

Zookeeper 是一個分布式的、開源的分布式應用程序協(xié)調服務。

作為一個協(xié)調服務，常常用來配合其他中間件來用，比如：Dubbo + Zookeeper，Hadoop + Zookeeper等，Zookeeper可以實現(xiàn)：服務注冊發(fā)現(xiàn)、分布式鎖、配置中心等功能。

今天我們重點來學習一下 Zookeeper 是如何實現(xiàn)服務注冊發(fā)現(xiàn)的。

分布式帶來的問題

先正式介紹 Zookeeper 之前，我們先引入一個業(yè)務場景：訂單服務需要調用用戶服務的接口。

要實現(xiàn)這個功能非常簡單，我們只需要知道用戶服務的 ip 和 port 就可以了。

突然有一天，用戶數(shù)量激增，用戶服務扛不住了，這個時候只能進行擴容，多部署幾個實例，這個時候問題就來了，訂單服務該調用哪個用戶服務的實例?

最簡單的辦法就是在訂單服務中配置所有的用戶服務實例，然后使用某種算法(比如說輪詢)從配置列表中選擇一個就可以了。

看似問題解決了，其實隱患很大：

• 用戶服務的實例數(shù)會根據(jù)負載進行動態(tài)調整，每次調整完都要更新配置列表，非常麻煩，也容易出錯。
• 某些服務實例 down 掉了，如果沒來得及從配置列表中清除掉，就會造成調用者請求接口報錯。

如何解決呢?往往解決這類分布式問題都需要一塊公共的區(qū)域來保存這些信息。

用 Redis 解決

需要一塊公共的區(qū)域保存這些信息，那利用 Redis 是否可以實現(xiàn)?

每個服務實例啟動之后都向 Redis 注冊信息，停止時也從 Redis 中刪除數(shù)據(jù)。

存放在 Redis 中的信息簡單來說就是服務實例的 ip + port，訂單服務需要調用用戶服務時直接從 Redis 中獲取即可。

簡單流程如下圖所示：

每次調用的時候都去 Redis 查詢一次，頻繁的查詢可能會導致性能瓶頸，為了解決這個問題我們可以在查詢之后在本地緩存一份數(shù)據(jù)，這樣每次調用可以優(yōu)先從本地獲取數(shù)據(jù)。

但這樣又會出現(xiàn)新的問題，本地緩存如何刷新呢，如果服務提供者某些實例 down 掉了或者擴容新增了一批實例，那服務消費者如何才能快速感知到呢?

要想解決這個問題，最先想到的一個辦法就是讓服務消費者定時輪詢 Redis，發(fā)現(xiàn)有更新了就去更新本地緩存，看起來也能解決本地緩存刷新的問題，但是多久輪詢一次呢，1 秒或者10 秒?

輪詢時間太短依然有性能瓶頸問題，這樣本地緩存也沒有存在的必要了;輪詢時間太長，本地緩存來不及更新，就會存在 "臟" 數(shù)據(jù)。

以上的方案都不完美，并且不優(yōu)雅，主要有以下幾點：

基于定時任務會導致很多無效的查詢。

定時任務存在周期性，沒法做到實時，這樣就可能存在請求異常。

如果服務被強行 kill，沒法及時清除 Redis，這樣這個看似可用的服務將永遠不可用!

所以我們需要一個更加靠譜的解決方案。

用 Zookeeper 解決

用過 Dubbo 的小伙伴對這張圖肯定很熟悉，步驟 0 到 4 是服務注冊發(fā)現(xiàn)的核心流程。

這個流程與我們上面討論的不謀而合，那 Dubbo 是如何實現(xiàn)的呢?實際上 Dubbo 作為一個通用的框架提供了多種解決方案，如：Zookeeper、Nacos等。

不管是哪種方案，總結起來都是一種套路，基本流程如下：

• 每個服務實例啟動之后將自己的信息(ip+port)寫入公共區(qū)域;
• 調用者訂閱自己感興趣的服務實例，獲取服務實例信息列表后緩存在自己本地;
• 服務實例停止或者 down 調后將公共區(qū)域自己的信息清除掉;
• 公共區(qū)域通知調用者你感興趣的信息已經(jīng)發(fā)生變更，請更新一下本地的緩存。

Zookeeper的重點特性

(1)樹狀目錄結構

Zookeeper是一個樹狀的文件目錄結構，與 Unix 文件系統(tǒng)很類似。樹中每個節(jié)點可以稱作為一個ZNode，每一個ZNode都可以通過其路徑唯一標識，最重要的是我們可以對每個 ZNode 進行增刪改查。

(2)持久節(jié)點(Persistent)

客戶端與Zookeeper服務端斷開連接后，節(jié)點仍然存在不會被刪除，這樣的節(jié)點就叫做持久節(jié)點。

(3)持久有序節(jié)點(Persistent_sequential)

持久有序節(jié)點是在上面持久節(jié)點的特性上加上了有序性，有序性的意思是服務向Zookeeper注冊信息時，Zookeeper 根據(jù)注冊順序給每個節(jié)點編號。

(4)臨時節(jié)點(Ephemeral)

客戶端與Zookeeper服務端斷開連接后，該節(jié)點被刪除。

注意:臨時節(jié)點下不存在子節(jié)點;持久節(jié)點下可以存在臨時節(jié)點。

(5)臨時有序節(jié)點(Ephemeral_sequential)

臨時有序節(jié)點是在臨時節(jié)點的基礎上再加上有序性，跟持久有序節(jié)點類似。

(6)節(jié)點監(jiān)聽(Wacher)

節(jié)點監(jiān)聽是Zookeeper最重要的特性之一，客戶端可以監(jiān)聽任意節(jié)點，節(jié)點有任何變化 Zookeeper 可以通過回調的方式通知給客戶端，這樣客戶端不用輪詢就可以及時感知節(jié)點變化。

如下圖所示，客戶端(client)開始監(jiān)聽臨時節(jié)點 1，因某種原因臨時節(jié)點 1 被刪除了，Zookeeper 通過回調將變化通知給 client 了。

Zookeeper 實現(xiàn)服務注冊發(fā)現(xiàn)

了解了Zookeeper的一些重要特性，我們再來看下 Zookeeper 是如何實現(xiàn)服務注冊和發(fā)現(xiàn)的。還是以訂單服務、用戶服務的場景為例。

服務提供方(用戶服務)啟動成功后將服務信息注冊到Zookeeper，服務信息包括實例的 ip、端口等元信息。注冊成功 Zookeeper 還可以通過心跳監(jiān)測來動態(tài)感知實例變化，詳細的過程這里不展開。

服務消費方(訂單服務)需要調用用戶服務的接口，但因為不知道實例的 ip、端口等信息，只能從 Zookeeper 中獲取調用地址列表，然后進行調用，這個過程成為服務的訂閱。

訂閱成功后服務消費方可以將調用列表緩存在本地，這樣不用每次都去調用 Zookeeper 獲取。一旦 Zookeeper感知到用戶服務實例變化后就會通知給服務消費方，服務消費方拿到結果后就會更新本地緩存，這個過程稱之為通知。

服務注冊原理

服務啟動后會自動向 Zookeeper 注冊，注冊的規(guī)則如下：

每個服務會創(chuàng)建一個持久節(jié)點和若干個臨時節(jié)點。比如：用戶服務首先創(chuàng)建一個持久節(jié)點 user，然后每個服務實例會在持久節(jié)點下創(chuàng)建一個臨時有序節(jié)點。

服務動態(tài)發(fā)現(xiàn)原理

由于訂單服務需要調用用戶服務的接口，所以訂單服務會訂閱 user 節(jié)點，一旦用戶服務有變化(增加實例或者減少實例)，Zookeeper 都會將最新的列表信息推送給訂單服務，這個過程就是服務動態(tài)發(fā)現(xiàn)的基本原理。少用文字描述，大家直接看圖：

小結

文章首先引入訂單服務和用戶服務的例子，說明了分布式場景下可能存在的問題：服務提供者實例越多，維護的成本越高。

經(jīng)過分析，我們得出結論：需要使用一塊公共的區(qū)域存儲實例信息。

如何提供公共的區(qū)域?我們先想到了Redis。

經(jīng)過實踐發(fā)現(xiàn) Redis 確實可以解決服務注冊和服務發(fā)現(xiàn)的問題，但是同時又引入了其他問題：

• 基于定時任務會導致很多無效的查詢。
• 定時任務存在周期性，沒法做到實時，這樣就可能存在請求異常。
• 如果服務被強行 kill，沒法及時清除 Redis，這樣這個看似可用的服務將永遠不可用!

當我們一籌莫展的時候，我們發(fā)現(xiàn)強大的 Dubbo 框架使用了 Zookeeper 來實現(xiàn)服務注冊和發(fā)現(xiàn)的功能。為了更好的學習 Zookeeper 是如何實現(xiàn)服務注冊和發(fā)現(xiàn)功能的，我們了解到 Zookeeper 的一些重要特性：

• 樹狀目錄結構
• 持久節(jié)點
• 持久有序節(jié)點
• 臨時節(jié)點
• 臨時有序節(jié)點
• 節(jié)點監(jiān)控

這些重要的特性為最后實現(xiàn)服務注冊和動態(tài)發(fā)現(xiàn)打下了堅實的基礎。

文章的最后，我們再次以訂單服務和用戶服務為例通過兩張圖生動的詮釋了服務注冊和動態(tài)發(fā)現(xiàn)的流程和原理。