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

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

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

引入注冊中心后

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

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

Eureka

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

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

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

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

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

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

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

Zookeeper

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

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

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

存儲路徑示例：

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

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

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

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

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

Nacos

Nacos 的關鍵特性：

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

Nacos 生態(tài)圖

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

Nacos 作為注冊中心架構圖：

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

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

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

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

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

Consul

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

Consul 的特點：

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

**Consul 架構圖 **

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

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

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

最后

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