微服務為什麼使用 Zookeeper 做註冊中心？

• 2019 年 12 月 27 日
• 筆記

微服務中Zookeeper的應用及原理

一、背景

了解微服務的小夥伴都應該知道Zookeeper，Zookeeper是一個分散式的,開源的分散式應用程式協調服務。現在比較流行的微服務框架Dubbo、Spring Cloud都可以使用Zookeeper作為服務發現與組冊中心。但是，為什麼Zookeeper就能實現服務發現與組冊呢？

二、Zookeeper的特性

我們先來了解一下Zookeeper的特性吧，因為它的特性決定了它的使用場景。

1、樹狀目錄結構

如上圖，Zookeeper是一個樹狀的文件目錄結構，有點想應用系統中的文件系統的概念。每個子目錄（如App）被稱為znode，我們可以對每個znode進行增刪改查。

2、持久節點(Persistent)

客戶端與Zookeeper服務端斷開連接後，該節點仍然存在。

3、持久有序節點(Persistent_sequential)

在持久節點基礎上，由Zookeeper給該節點名稱進行有序編號，如0000001，0000002。

4、臨時節點(Ephemeral)

客戶端與Zookeeper服務端斷開連接後，該節點被刪除。臨時節點下，不存在子節點。

5、臨時有序節點(Ephemeral_sequential)

在臨時節點基礎上，由Zookeeper給該節點名稱進行有序編號，如0000001，0000002。

6、節點監聽(Wacher)

客戶端2註冊監聽它關心的臨時節點SubApp1的變化，當臨時節點SubApp1發生變化時（如圖中被刪除的時候），Zookeeper會通知客戶端2。該機制是Zookeeper實現分散式協調的重要特性。我們可以通過get，exists，getchildren三種方式對某個節點進行監聽。但是該事件只會通知一次。

三、微服務中應用場景

1.分散式鎖

分散式鎖主要解決不同進程中的資源同步問題。大家可以聯想一下單進程中的多執行緒共享資源的情況，執行緒需要訪問共享資源，首先要獲得鎖，操作完共享資源後便釋放鎖。分散式中，上述的鎖就變成了分散式鎖了。那這個分散式鎖又是如何實現呢？

步驟1:

如圖，根據Zookeeper有序臨時節點的特性，每個進程對應連接一個有序臨時節點（進程1對應節點/znode/00000001，進程2對應節點/znode/00000002…如此類推）。每個進程監聽對應的上一個節點的變化。編號最小的節點對應的進程獲得鎖，可以操作資源。整編：微信公眾號，搜雲庫技術團隊，ID：souyunku

步驟2:

當進程1完成業務後，刪除對應的子節點/znode/00000001，釋放鎖。此時，編號最小的鎖便獲得鎖（即/znode/00000002對應進程）。

重複以上步驟，保證了多個進程獲取的是同一個鎖，且只有一個進程能獲得鎖，就是Zookeeper分散式鎖的實現原理。

2.服務註冊與發現

2.1 背景

在微服務中，服務提供方把服務註冊到Zookeeper中心去如圖中的Member服務，但是每個應用可能拆分成多個服務對應不同的Ip地址，Zookeeper註冊中心可以動態感知到服務節點的變化。

服務消費方（Order 服務）需要調用提供方（Member 服務）提供的服務時，從Zookeeper中獲取提供方的調用地址列表，然後進行調用。這個過程稱為服務的訂閱。

2.2服務註冊原理

rpc框架會在Zookeeper的註冊目錄下，為每個應用創建一個持久節點，如order應用創建order持久節點，member應用創建member持久節點。整編：微信公眾號，搜雲庫技術團隊，ID：souyunku

然後在對應的持久節點下，為每個微服務創建一個臨時節點，記錄每個服務的URL等資訊。

2.3服務動態發現原理

由於服務消費方向Zookeeper訂閱了（監聽）服務提供方，一旦服務提供方有變動的時候（增加服務或者減少服務），Zookeeper就會把最新的服務提供方列表（member list）推送給服務消費方，這就是服務動態發現的原理。

作者：Marvin Mai

來源：https://dwz.cn/6ByfGykc