大家好，我是樓仔呀。

這篇文章對 Zookeeper 的注冊中心原理再深入研究一下，主要學習它的設計思想。

直接上文章目錄：

1. 基本概念

1.1 什么是注冊中心？

注冊中心主要有三種角色：

• 服務提供者（RPC Server）：在啟動時，向 Registry 注冊自身服務，并向 Registry 定期發送心跳匯報存活狀態。
• 服務消費者（RPC Client）：在啟動時，向 Registry 訂閱服務，把 Registry 返回的服務節點列表緩存在本地內存中，并與 RPC Sever 建立連接。
• 服務注冊中心（Registry）：用于保存 RPC Server 的注冊信息，當 RPC Server 節點發生變更時，Registry 會同步變更，RPC Client 感知后會刷新本地 內存中緩存的服務節點列表。

最后，RPC Client 從本地緩存的服務節點列表中，基于負載均衡算法選擇一臺 RPC Sever 發起調用。

1.2 注冊中心需要實現功能

根據注冊中心原理的描述，注冊中心必須實現以下功能，偷個懶，直接貼幅圖：

2. ZK 注冊中心原理

Zookeeper 可以充當一個服務注冊表（Service Registry），讓多個服務提供者形成一個集群，讓服務消費者通過服務注冊表獲取具體的服務訪問地址（Ip + 端口）去訪問具體的服務提供者。

2.1 ZK 注冊流程

每當一個服務提供者部署后都要將自己的服務注冊到 Zookeeper 的某一路徑上: /{service}/{version}/{ip:port} 。

比如我們的 HelloWorldService 部署到兩臺機器，那么 Zookeeper 上就會創建兩條目錄：

• /HelloWorldService/1.0.0/100.19.20.01:16888
• /HelloWorldService/1.0.0/100.19.20.02:16888

在 Zookeeper 中，進行服務注冊，實際上就是在 Zookeeper 中創建了一個 znode 節點，該節點存儲了該服務的 IP、端口、調用方式(協議、序列化方式)等。

該節點承擔著最重要的職責，它由服務提供者(發布服務時)創建，以供服務消費者獲取節點中的信息，從而定位到服務提供者真正網絡拓撲位置以及得知如何調用。

RPC 服務注冊/發現過程簡述如下：

服務提供者啟動時，會將其服務名稱，IP 地址注冊到配置中心。

服務消費者在第一次調用服務時，會通過注冊中心找到相應的服務的 IP地址列表，并緩存到本地，以供后續使用。當消費者調用服務時，不會再去請求注冊中心，而是直接通過負載均衡算法從 IP 列表中取一個服務提供者的服務器調用服務。

當服務提供者的某臺服務器宕機或下線時，相應的 IP 會從服務提供者 IP 列表中移除。同時，注冊中心會將新的服務 IP 地址列表發送給服務消費者機器，緩存在消費者本機。

當某個服務的所有服務器都下線了，那么這個服務也就下線了。

同樣，當服務提供者的某臺服務器上線時，注冊中心會將新的服務 IP 地址列表發送給服務消費者機器，緩存在消費者本機。

服務提供方可以根據服務消費者的數量來作為服務下線的依據。

2.2 ZK 的心跳檢測

問題：第 3 步中“當服務提供者的某臺服務器宕機或下線時”，Zookeeper 如何感知到呢？

Zookeeper 提供了“心跳檢測”功能，它會定時向各個服務提供者發送一個請求（實際上建立的是一個 socket 長連接），如果長期沒有響應，服務中心就認為該服務提供者已經“掛了”，并將其剔除。

比如 100.100.0.237 這臺機器如果宕機了，那么 Zookeeper 上的路徑就會只剩 /HelloWorldService/1.0.0/100.100.0.238:16888。

2.3 ZK 的 Watch 機制

問題：第 3 步和第 5 步中“注冊中心會將新的服務 IP 地址列表發送給服務消費者機器”，這步是如何實現的呢？

這個問題也是經典的生產者-消費者問題，解決的方式有兩種：

• 主動拉取策略：服務的消費者定期調用注冊中心提供的服務獲取接口獲取最新的服務列表并更新本地緩存，經典案例就是 Eureka。

• 發布-訂閱模式：服務消費者能夠實時監控服務更新狀態，通常采用監聽器以及回調機制。

Zookeeper 使用的是“發布-訂閱模式”，這里就要提到 Zookeeper 的 Watch 機制，整體流程如下：

• 客戶端先向 ZooKeeper 服務端成功注冊想要監聽的節點狀態，同時客戶端本地會存儲該監聽器相關的信息在 WatchManager 中；
• 當 ZooKeeper 服務端監聽的數據狀態發生變化時，ZooKeeper 就會主動通知發送相應事件信息給相關會話客戶端，客戶端就會在本地響應式的回調相關 Watcher 的 Handler。

上面講的有點抽象，大白話解讀一下，Zookeeper 的 Watch 機制其實就是一種推拉結合的模式：

• 服務消費者會去監聽相應路徑（/HelloWorldService/1.0.0），一旦路徑上的數據有任務變化（增加或減少），Zookeeper 只會發送一個事件類型和節點信息給關注的客戶端，而不會包括具體的變更內容，所以事件本身是輕量級的，這就是推的部分。
• 收到變更通知的客戶端需要自己去拉變更的數據，這就是拉的部分。

3. ZK 是否適合作為注冊中心

探討這個問題前，我們一定需要知道什么是 CAP 理論。

3.1 CAP 理論

CAP 理論是分布式架構中重要理論：

• 一致性(Consistency)：所有節點在同一時間具有相同的數據；
• 可用性(Availability) ：保證每個請求不管成功或者失敗都有響應；
• 分隔容忍(Partition tolerance) ：系統中任意信息的丟失或失敗不會影響系統的繼續運作。

關于 P 的理解，我覺得是在整個系統中某個部分，掛掉了，或者宕機了，并不影響整個系統的運作或者說使用，而可用性是，某個系統的某個節點掛了，但是并不影響系統的接受或者發出請求。

CAP 不可能都取，只能取其中 2 個的原因如下：

如果 C 是第一需求的話，那么會影響A的性能，因為要數據同步，不然請求結果會有差異，但是數據同步會消耗時間，期間可用性就會降低。

如果 A 是第一需求，那么只要有一個服務在，就能正常接受請求，但是對與返回結果變不能保證，原因是，在分布式部署的時候，數據一致的過程不可能想切線路那么快。

再如果，同時滿足一致性和可用性，那么分區容錯就很難保證了，也就是單點，也是分布式的基本核心。

3.2 ZK 作為注冊中心探討

作為一個分布式協同服務，ZooKeeper 非常好，但是對于 Service 發現服務來說就不合適了，因為對于 Service 發現服務來說就算是返回了包含不實的信息的結果也比什么都不返回要好。

所以當向注冊中心查詢服務列表時，我們可以容忍注冊中心返回的是幾分鐘以前的注冊信息，但不能接受服務直接 down 掉不可用。

但是 zk 會出現這樣一種情況，當 master 節點因為網絡故障與其他節點失去聯系時，剩余節點會重新進行 leader 選舉。問題在于，選舉 leader 的時間太長，30 ~ 120s，且選舉期間整個zk集群都是不可用的，這就導致在選舉期間注冊服務癱瘓。

在云部署的環境下，因網絡問題使得 zk 集群失去 master 節點是較大概率會發生的事，雖然服務能夠最終恢復，但是漫長的選舉時間導致的注冊長期不可用是不能容忍的。

所以說，作為注冊中心，可用性的要求要高于一致性！

在 CAP 模型中，Zookeepe 整體遵循一致性（CP）原則，即在任何時候對 Zookeeper 的訪問請求能得到一致的數據結果，但是當機器下線或者宕機時，不能保證服務可用性。

那為什么 Zookeeper 不使用最終一致性（AP）模型呢？因為這個依賴 Zookeeper 的核心算法是 ZAB，所有設計都是為了強一致性。這個對于分布式協調系統，完全沒沒有毛病，但是你如果將 Zookeeper為分布式協調服務所做的一致性保障，用在注冊中心，或者說服務發現場景，這個其實就不合適。

4. 小節

我們對 Zookeeper 的注冊中心總結如下：

Zookeeper 的心跳檢測，可以自動探測服務提供者機器的宕機或下線；

Zookeeper 的 Watch 機制，可以將變更的注冊列表推給服務消費者；

Zookeeper 是 CP 模型，不太適合作為注冊中心。

不過網上也有說，Zookeeper 目前已經支持 AP，準確說是 AP + Base 最終一致性，可以和我一起討論哈。