前言
瞭解微服務的小夥伴都應該知道ZooKeeper，它是一個分佈式的,開源的分佈式應用程序協調服務。現在比較流行的微服務框架Dubbo、Spring Cloud都可以使用ZooKeeper作爲服務發現與組冊中心。但是，爲什麼ZooKeeper就能實現服務發現與註冊呢？
ZooKeeper的特性
我們先來了解一下ZooKeeper的特性吧，因爲它的特性決定了它的使用場景。
1.樹狀目錄結構
如上圖，ZooKeeper是一個樹狀的文件目錄結構，有點像應用系統中的文件系統的概念。每個子目錄（如App）被稱爲znode，我們可以對每個znode進行增刪改查。
2.持久節點
客戶端與ZooKeeper服務端斷開連接後，該節點仍然存在。
3.持久有序節點
在持久節點基礎上，由zookeeper給該節點名稱進行有序編號，如0000001，0000002。
4.臨時節點
客戶端與zookeeper服務端斷開連接後，該節點被刪除。臨時節點下，不存在子節點。
5.臨時有序節點
在臨時節點基礎上，由zookeeper給該節點名稱進行有序編號，如0000001，0000002。
6.節點監聽
客戶端2註冊監聽它關心的臨時節點SubApp1的變化，當臨時節點SubApp1發生變化時（如圖中被刪除的時候），zookeeper會通知客戶端2。該機制是zookeeper實現分佈式協調的重要特性。我們可以通過get，exists，getchildren三種方式對某個節點進行監聽。但是該事件只會通知一次。
微服務中應用場景
1.分佈式鎖
分佈式鎖主要解決不同進程中的資源同步問題。大家可以聯想一下單進程中的多線程共享資源的情況，線程需要訪問共享資源，首先要獲得鎖，操作完共享資源後便釋放鎖。分佈式中，上述的鎖就變成了分佈式鎖了。那這個分佈式鎖又是如何實現呢？
步驟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）推送給服務消費方，這就是服務動態發現的原理。