了解微服務的小伙伴都應該知道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.分布式鎖

分布式鎖主要解決不同進程中的資源同步問題。大家可以聯想一下單進程中的多線程共享資源的情況，線程需要訪問共享資源，首先要獲得鎖，操作完共享資源后便釋放鎖。Zookeeper怎么實現分布式鎖？這篇推薦大家閱讀。

分布式中，上述的鎖就變成了分布式鎖了。那這個分布式鎖又是如何實現呢？

步驟1: 如圖，根據Zookeeper有序臨時節點的特性，每個進程對應連接一個有序臨時節點（進程1對應節點/znode/00000001，進程2對應節點/znode/00000002…如此類推）。

每個進程監聽對應的上一個節點的變化。編號最小的節點對應的進程獲得鎖，可以操作資源。

步驟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持久節點。

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

2.3服務動態發現原理

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

作者：Marvin Mai

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

總結

以上是生活随笔為你收集整理的微服务为什么一定要Zookeeper？的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。