隨著單體應用的拆分，我們面臨的首要問題就是采用哪種方式實現服務間的調用，像之前單體應用可能直接在配置或數據庫保存調用方的域名 IP 信息等。

但拆分后服務實例信息眾多，且隨著服務動態擴縮容，服務運行時信息一直變化，那么我們就需引入注冊中心幫助我們解決這類問題了。

今天我們來聊一聊微服務架構中的服務注冊與發現有哪些？Zookeeper、Eureka、Nacos、Consul都有什么區別，他們的實現原理是什么？

引入注冊中心后

在微服務架構中，服務注冊與發現是一個至關重要的功能。它確保了分布式系統中各個微服務之間能夠動態地相互定位和通信。常見的服務注冊中心有 Eureka、Zookeeper、Consul 和 Nacos

我們來看下實際項目中要如何選擇合適的注冊中心呢？

Eureka

Eureka 是由 Netflix 提供的服務注冊與發現框架，通常用于大規模的微服務系統。它的架構分為兩部分：Eureka Server 和 Eureka Client，這是 Eureka 的架構圖。

• Eureka Server：負責提供注冊中心的服務，所有微服務實例都注冊到 Eureka Server 中，其他微服務通過 Eureka Client 來發現服務。
• Eureka Client：微服務實例作為客戶端，定期向 Eureka Server 注冊自己并更新健康狀態。這里包含了 Application Service（服務提供者）和 Application Client（服務消費者）。

“那么，Eureka 是如何保證 AP 的呢？

• 集群：由上圖可看出 Eureka Server 多個實例之間都是對等的，每個都是其它節點的副本，是一種去中心化的架構。
• 心跳：Client 通過發送心跳到 Server 以維持和更新注冊表中服務實例元數據的有效性。當在一定時長內（默認 90s），Server 沒有收到 Client 的心跳信息，會把服務實例的信息從注冊表中刪除。
• 自我保護機制：當 Eureka Server 節點在短時間內丟失過多的心跳時（15 分鐘超過 85%節點沒有正常返回心跳），那么這個節點就會進入自我保護模式。

“什么是 Eureka 的自我保護機制？

• Eureka 不再剔除沒有正常返回心跳的服務。
• Eureka 仍可以接受新服務注冊請求，但是不會同步到其它 Server 節點。
• 當網絡恢復穩定時，之前新注冊的信息會再次同步到其它節點上。

所以 Eureka 遵循的是 AP（Availability + Partition tolerance）。它犧牲了數據一致性，尤其是在網絡分區發生時。Eureka 實現了 "最終一致性" 的策略，允許系統在出現故障時繼續提供可用的服務。

Zookeeper

“Zookeeper 是如何實現注冊中心的呢？

Zookeeper 的數據模型基于一種叫做 ZNode（Zookeeper 節點）的概念，在 Zookeeper 中，服務注冊和發現的核心思想是利用臨時節點來存儲服務實例的信息。具體過程如下：

• 創建臨時節點：當一個服務啟動時，它會向 Zookeeper 注冊自己。通常，服務會在某個目錄（如 /services）下創建一個臨時節點。每個服務實例會被注冊為一個獨特的臨時節點。

存儲路徑示例：

/services/payment-service/instance-1
/services/payment-service/instance-2

//payment-service：支付服務名稱
//instance-1：實例唯一標識符，Ip端口信息。

• watch 機制：Zookeeper 支持客戶端對節點的監視機制（Watch）。當服務上線時，Zookeeper 會通知客戶端，客戶端會更新可用服務列表。當某個服務實例斷開與 Zookeeper 的連接時，Zookeeper 會刪除該臨時節點，并通知客戶端，客戶端可以去掉失效的服務實例。

ZooKeeper 是基于 CP 來設計的，即任何時刻對 ZooKeeper 的訪問請求能得到一致的數據結果，同時系統對網絡分割具備容錯性，但是它不能保證每次服務請求的可用性。

從實際情況來分析，在使用 ZooKeeper 獲取服務列表時，如果 zookeeper 正在選主，或者 ZooKeeper 集群中半數以上機器不可用，那么將無法獲得數據。所以說，ZooKeeper 不能保證服務可用性。

Nacos

Nacos 的關鍵特性：

• 服務發現和服務健康監測：Nacos 支持基于 DNS 和基于 RPC 的服務發現。提供對服務的實時的健康檢查，支持傳輸層(PING 或 TCP)和應用層 (如 HTTP、MySQL、用戶自定義）的健康檢查。
• 動態配置服務：Nacos 支持的動態配置，提供了配置版本跟蹤、金絲雀發布、一鍵回滾配置以及客戶端配置更新狀態跟蹤在內的一系列開箱即用的配置管理特性。
• 動態 DNS 服務：Nacos 提供了動態 DNS 服務，支持權重路由，使得中間層負載均衡、更靈活的路由策略、流量控制以及數據中心內網的簡單 DNS 解析服務。
• 服務及其元數據管理：Nacos 可以幫助微服務平臺建設的視角管理數據中心的所有服務及元數據。

Nacos 生態圖

如 Nacos 全景圖所示，Nacos 無縫支持一些主流的開源生態。

Nacos 作為注冊中心架構圖：

Nacos 作為注冊中心，它是支持戶根據需求選擇 一致性優先（CP） 或 可用性優先（AP） 模式的。

• CP 模式：Nacos 集群通過使用 Raft 協議確保一致性，通過 Raft 協議確保集群內的大部分節點在某一時刻保持一致的數據副保持本。如果發生網絡分區時，為了保證數據一致性，Nacos 可能會將某些請求拒絕。
• AP 模式：Nacos 集群可以容忍部分節點的失效或者網絡分區，并繼續提供服務。AP 模式下，Client 會從不同節點獲取到不同的數據副本，這種模式主要為了提供系統的可用性。

可以通過更改 Nacos 的配置文件 conf/application.properties 切換 AP 或 CP 模式：

nacos.core.protocol.distro.data.sync.mode
Raft表示CP模式，Async表示AP模式

默認情況下，Nacos 會采用 AP 模式，因為大多情況下作為注冊中心，微服務架構更看重它對服務注冊發現高可用的要求。

Consul

Consul 是 HashiCorp 公司推出的開源工具，Consul 由 Go 語言開發，部署起來非常容易，只需要極少的可執行程序和配置文件，具有綠色、輕量級的特點。

Consul 的特點：

• 服務發現:Consul 提供了 HTTP 或 DNS 的方式來注冊、發現服務。
• 健康檢查：Consul Client 可以提供任意數量的健康檢查，可以根據返回結果比如“200”或者與本地負載(“內存占用是否低于 90%”)，來判斷服務是否處于健康狀態。
• key/Value 存儲：Consul 數據采用 key/value 結構存儲，非常靈活方便。
• 安全服務通信：Consul 可以為服務生成和分發 TLS 證書，以建立相互的 TLS 連接。
• 多數據中心：Consul 天然支持多數據中心。

**Consul 架構圖 **

由上圖可看出，Consul 分為 Client 和 Server 兩種節點（所有的節點也被稱為 Agent）：

• Server 節點保存數據，Server 節點有一個 Leader 和多個 Follower，Leader 節點會將數據同步到 Follower，Server 的數量推薦是 3 個或者 5 個，在 Leader 掛掉的時候會啟動選舉機制產生一個新的 Leader。
• Client 負責健康檢查及轉發數據請求到 Server。

Consul 采用的 Raft 協議來保證集群內多個節點的數據一致性，所以是采用的 CP 模式。

最后

最后，我們來看下各注冊中心的對比：