註冊中心選型篇-四款註冊中心特色超全總結

在實際的項目選型中，該如何考慮選擇合適的註冊中心呢？

我在網上找了不少資料，但都基本不是最新的，好比說幾乎全部的資料都還在說只有Eureka支持Spring Cloud的集成，其餘註冊中心均不支持Spring Cloud。所以，就想要本身寫一篇 最新最全 的註冊中心的特色比較的文章，來幫助本身以及親愛的粉絲們從新梳理他們的特色，以保證以更全方位的考慮來進行項目選型

序號	比較項	Eureka	zookeeper	Nacos	Consul
1	集羣結構	平級	主從	支持平級和主從	主從
2	集羣角色	主人	Leader、follower observer	leader、follower、candidate	server-leader、server以及client
3	是否能夠及時知道服務狀態變化	不能及時知道	會及時知道	不能及時知道	不能及時知道
4	一致性協議（CAP）	注重可用性（AP）	注重一致性(CP)	支持CP和AP-如何實現	注重一致性(CP)
5	雪崩保護	有	沒有	有	沒有
6	社區是否活躍	Eureka2.0再也不維護了	持續維護	持續維護	持續維護
7	管理端	有現成的eureka管理端	沒有現成的管理端	有現成的管理端	有現成的管理端
8	負載均衡策略	使用ribbon實現	通常能夠直接採用RPC的負載均衡	權重/metadata/Selector	Fabio
9	權限控制	無	使用ACL實現節點權限控制	RBAC-用戶、角色、權限	ACL
10	Spring Cloud集成	支持	支持	支持	支持
11	健康檢查	Client Beat	Keep Alive	TCP/HTTP/MYSQL/Client Beat	TCP/HTTP/gRPC/Cmd
12	自動註銷實例	支持	支持	支持	不支持
13	訪問協議	HTTP	TCP	HTTP/DNS	HTTP/DNS
14	是否可用做配置中心	否	是	是	是
15	多數據中心	不支持	不支持	不支持	支持
16	跨註冊中心同步	不支持	不支持	支持	支持
17	Dubbo集成	不支持	支持	支持	不支持
18	K8S集成	支持	支持	支持	支持

1 集羣結構

Eureka的集羣架構自己就是平級結構

zookeeper和consul則均爲主從結構

Nacos則支持平級關係和主從這兩種集羣架構，經常使用的是後者

具體架構是怎樣的，能夠繼續往下看~

2 集羣角色

我發現，集羣架構和角色每每是一個註冊中心的核心功能，搞清楚這兩點，基本上對於這個註冊中心已經掌握了一半了。來分別看看四個註冊中心的集羣角色吧~

1） Eureka ：集羣各節點都是分庭抗禮的關係，數據是相互複製的，所以各個節點都是主人角色

如圖，服務端 Eureka-server 會存儲服務實例信息，經過 複製 實現服務實例信息在各個節點同步，並按期去檢查服務實例信息狀態；

各個客戶端也會經過健康檢查等機制進行自我狀態檢查，要是信息有了變化，均會向服務Eureka-server發起請求

Eureka-server則會分別處理這些 狀態變化 ，來保持實例信息的更新

2）zookeeper：集羣角色包含leader、follower以及observer三類

具體來講是一主多從結構，就是有一個leader，多個follower，以及只負責讀操做、不參與選舉的observer

下面是關於三個角色之間的關係圖

a）首先圖上是有client和server兩大角色。client經過TCP與其中一個server創建鏈接。其中server分爲leader、follower，以及observer三個角色

leader:負責投票的發起和決議

follower:同步leader的狀態，參與leader選舉。將寫操做轉發給leader,並參與「過半寫成功」策略

observer:同步leader的狀態，將寫操做轉發給Leader。不參加投票選舉過程，也不參加寫操做的「過半寫成功」策略

b）當leader由於網絡或者其餘緣由掛掉以後，會從新在follower裏面選擇一個新的leader。

c）observer 機器能夠在不影響寫性能的狀況下提高集羣的讀性能。

3）cosul：集羣角色包含server-leader、server以及client

    

這三個角色實際上能夠分別對應zookeeper中的 leader , follower 以及 observer 。對了，這塊第三種角色- client ，千萬要注意，它仍是屬於consul的服務端的一個節點角色，而不是consul的客戶端哦

來，看一下這張圖，來梳理一下他們各自的功能

client : consul的client模式的節點。接收到consul的客戶端請求之後，不作處理，會轉發到server-leader，也不會持久化信息

server: consul的server模式的節點，功能和client都同樣。惟一不一樣的是，它會把全部的信息持久化到本地，這樣遇到故障，信息是能夠被保留的

server-leader: 名字就已經說明，這個server是全部服務端接節點的老大了,那麼它天然負責的工做就多啦~ 它除了和普通的server模式的節點同樣，須要進行信息持久化之外，還額外須要負責同步註冊的信息給其它的server，同時也要負責各個節點的健康監測

4）Nacos： 包含 leader 、follower、candidate三類

Leader：負責Client交互和log複製，同一時刻系統中最多存在1個

Follower：被動響應請求 RPC ，從不主動發起請求RPC。接收到請求，會 轉發 給leader處理

Candidate：一種臨時的角色，只存在於leader的選舉階段

某個節點想要變成leader，那麼就發起投票請求，同時本身變成candidate，若是選舉成功，則變爲candidate，不然退回爲follower

具體流程以下圖所示：

a  集羣啓動後，初始節點狀態都是  Follower  狀態

b 某個follower想要被選舉成爲leader,因而變成 candidate (候選人)狀態，向本身投票，並向其餘follower發起投票請求

c 收到其餘節點的投票響應之後，若 超過半數的follower 都投了本身，則投票成功，本身的狀態變爲 leader

d  若是並無收到大多數的選票，則進行新一輪的投票

3 是否能夠及時知道服務狀態變化

因爲zooKeeper具備watcher機制，所以能夠及時知道數據目錄的狀態變化，那麼也就能夠及時知道服務器節點以及所註冊的實例的變化。咱們能夠經過這種監聽機制，可以實時獲取到某個服務器的故障或者咱們比較關心的節點數據的更改（zookeeper的節點znode包含服務器節點和數據節點）

其餘三個註冊中心沒有這樣的機制，只是能夠經過管理端進行主動查看服務狀態，並不能實時感知服務狀態的變化

4 一致性協議（CAP）

首先，咱們再複習一下CAP原理（參考維基百科）

在理論計算機科學中，CAP定理，又被稱做布魯爾定理，它指出對於一個分佈式計算系統來講，不可能同時知足如下三點：

1） 一致性 （Consistency）註冊中心的集羣各個節點的數據信息徹底一致

2） 可用性 （Availability）每次請求都能獲取到 非錯的響應 ——可是不保證獲取的數據爲最新數據

3） 分區容錯性 （Partition tolerance）以實際效果而言，分區至關於對 通訊的時限 要求。系統若是不能在時限內達成數據一致性，就意味着發生了分區的狀況，必須就當前操做在C和A之間作出選擇

根據定理，分佈式系統 只能知足三項中的兩項， 而不可能知足所有三項

理解CAP理論的最簡單方式是 想象兩個節點分處分區兩側 。容許至少一個節點更新狀態會致使數據不一致，即喪失了C性質。若是爲了保證數據一致性，將分區一側的節點設置爲不可用，那麼又喪失了A性質。除非兩個節點能夠互 相通訊，才能既保證C又保證A，這又會致使喪失P性質

而四個註冊中心，對一致性協議的支持狀況以下：

          

Eureka ：支持AP，即保障可用性和分區容錯性

Zookeeper ：支持CP,即保障一致性和分區容錯性

consul ：支持CP,即保障一致性和分區容錯性
nacos ：支持AP和CP兩種模式。能夠分別支持AP和CP兩種場景



　C是全部節點在同一時間看到的數據是一致的；A是全部的請求都會收到響應。一個保證一致性，一個保證可用性。那麼， 對於Nacos,如何選擇使用哪一種模式呢？　


　　1）通常來講，若是 不須要存儲 服務級別的信息，且服務實例是經過Nacos-client註冊，並可以保持心跳上報，那麼就能夠選擇AP模式。AP模式爲了服務的可用性而減弱了一致性，所以AP模式下只能註冊 臨時實例


　　2）若是須要在服務級別 編輯或存儲 配置信息，那麼CP是必須，K8S服務和DNS服務則適用於CP服務，CP模式下則支持註冊持久化實例，此時則是以Raft協議爲集羣運行模式，該模式下注冊實例以前必須先註冊服務，若是服務不存在，則會返回錯誤


那麼該如何 切換 這兩種模式呢？



1）執行以下命令：


curl -X PUT `$NACOS_SERVER:8848/nacos/v1/ns/operator/switches?entry=serverMode&value=CP'



2）同時微服務的bootstrap.properties 需配置以下選項指明註冊爲臨時/永久實例


#false-註冊永久實例，true-註冊爲臨時實例
spring.cloud.nacos.discovery.ephemeral=false






5 自動註銷實例


除了 consul不支持自動註銷 實例之外，其餘三個註冊中心均支持 自動註銷 實例


1）Eureka ：默認狀況下，若是Eureka Server在90秒內沒有接收到某個微服務實例的心跳，Eureka Server將會註銷該實例（時間間隔能夠配置）


2）zookeeper :使用臨時節點，依託於Session超時時間來實現 TTL 功能來實現自動註銷。能夠給每個鍵或目錄指定一個存活時限TTL，當指定的秒數過去之後，若是相應的鍵或目錄沒有獲得更新，就會被自動從Etcd記錄中移除


3）Nacos ：從 0.5.0 版本開始，用戶經過客戶端SDK註冊的實例，將默認開啓TTL功能，實例會默認每5秒向服務端發送一次心跳，若是Nacos服務端15秒內沒有收到實例的心跳，則會將實例置爲不健康，若是30秒沒有收到心跳，則會將直接將實例刪除


Tips：
TTL, 是 Time To Live的簡稱，意思爲一條域名解析記錄在DNS服務器中的存留時間


6 雪崩保護


1）Eureka :有雪崩保護。咱們知道，當網絡分區故障發生時，微服務與Eureka Server之間忽然沒法正常通訊了，根據心跳機制，微服務將會被註銷。那麼這種心跳機制是否是就變得不太友好了？由於這種狀況下微服務自己實際上是健康的，本不該該註銷這個微服務，所以Eureka就提供了一個自我保護機制，也就是雪崩保護機制；



a）條件：



當Eureka Server節點在短期內丟失過多客戶端（可能發生了網絡分區故障），默認是15分鐘內收到的續約低於原來的85%時，這個節點就會進入自我保護模式


b）動做：


一旦進入該模式，Eureka Server仍能接收新服務的註冊和查詢請求，可是不會同步到其餘節點上；同時也會保護服務註冊表中的信息，再也不移除註冊列表中由於長時間沒收到心跳而應該過時的服務。當網絡故障恢復後，該Eureka Server節點會自動退出自我保護模式


這樣獲取的數據的確有可能不是最新的，但Eureka的這種自我保護機制，極大地保證了Eureka的高可用特性


2）Zookeeper： 沒有雪崩保護



3）consul： 沒有雪崩保護


4）nacos： 有雪崩保護。爲了防止因過多實例 (Instance) 不健康致使流量所有流向健康實例 (Instance) ，繼而形成流量壓力把健康實例 (Instance) 壓垮並造成雪崩效應，應將健康保護閾值定義爲一個 0 到 1 之間的浮點數


當域名 健康實例 佔 總服務實例 的比例小於該值時，不管實例是否健康，都會將這個實例返回給客戶端。這樣作雖然損失了一部分流量，可是保證了集羣的剩餘健康實例 (Instance) 能正常工做


7 社區是否活躍


Eureka2.0再也不維護了，而其餘三個註冊中心依舊在持續維護中，其中 Nacos 和 Consul 的社區應該說活躍度是最高的。從代碼更新速度來說，也是如此。分別看了一下eureka、zookeeper、nacos以及consul的代碼更新記錄


1）eureka





2）zookeeper









3）nacos 





4）consul




會發現， Eureka 的更新頻率相對來講，明顯比較低， Zookeeper 逐漸趨於成熟化，所以代碼更新頻率也很低，只是稍好於 Eureka 。而 Nacos 和 Consul 的更新頻率明顯很高，所以社區活躍度來講， Nacos 和 Consul 仍是頗有優點的，所以對於將來的微服務項目的註冊中心選型，更建議考慮這兩種，更有保障一些



8 是否有管理端


Eureka 、 Consul 和 Nacos 都有現成的管理端


zookeeper沒有現成的管理端，但客戶端也能夠根據提供的API，很容易本身實現一個也控制檯，好比zkui就是其中一個比較好用的zookeeper管理端


9 負載均衡策略


Eureka :使用ribbon實現


Zookeeper :通常能夠直接採用RPC的負載均衡


Nacos :採用權重/metadata/Selector


Consul :使用Fabio


關於負載均衡策略，這塊就不作過多介紹了，感興趣的能夠在網上找找~


10 權限控制


Eureka 自己沒有權限控制的機制，所以它須要與Spring Cloud Security來實現它的權限控制；


zookeeper :使用ACL實現節點權限控制
nacos ：使用RBAC實現節點權限控制-用戶、角色、權限


consul ：使用ACL實現節點權限控制


11 Spring Cloud集成


四個註冊中心，現 均已支持Spring Cloud的集成


12 健康檢查


Eureka ： Eureka Server 與 Eureka Client 之間使用 心 跳機制 來肯定Eureka Client 的狀態，默認狀況下，服務器端與客戶端的心跳保持正常，應用程序就會始終保持 UP 狀態




Zookeeper： 自己沒有健康檢查機制，須要消費者本身實現服務提供者的健康檢查動做
Nacos ： Nacos 支持傳輸層（PIND 或 TCP）和應用層（如 HTTP、MySQL 以及用戶自定義）的監控檢查，同時還支持相似於Eureka的心跳機制的健康檢查
Consul：TCP/HTTP/gRPC/Cmd
健康檢查，不得不說，是Consul的一個亮點特性了！Consul支持如下幾種類型的健康檢查：


1）腳本檢查機制：經過執行程序外的腳本
2）HTTP檢查機制：經過向指定的URL發起GET請求，服務的狀態依賴HTTP請求的狀態碼：


2xx - passing
429 - Too ManyRequests is a warning
other - failure


與使用Curl或是外部進程檢查的健康檢查機制相比，HTTP檢查機制應該是首選的


3）TCP檢查機制
經過與指定的IP/hostname + 端口監理TCP鏈接


4）TTL檢查機制


保留了給定的TTL（生命週期）的最新的狀態，這些狀態必須經過HTTP接口定時進行更新，須要服務週期性彙報健康狀態


5）Docker檢查機制


依賴觸發一同被打包進容器的外部應用程序


13 訪問協議


Eureka採用HTTP協議進行訪問


Zookeeper採用TCP進行訪問


而Nacos和Consul除了支持HTTP協議訪問之外，還支持DNS協議


14 是否可用做配置中心


除了eureka不能夠做爲配置中心之外，其餘三個註冊中心都可以做爲配置中心


15 多數據中心


只有consul支持多數據中心，但其餘註冊中心都有方案部署爲多數據中心


16 跨註冊中心同步


nacos 和 consul 支持跨註冊中心同步


17 Dubbo集成


zookeeper 和 Nacos 支持Dubbo集成，Eureka和consul則暫不支持



18 K8S集成


四個註冊中心 均支持k8s集成



三 總結

好了，今天呢，咱們主要經過18個方面，對四個註冊中心作了分析比較，從新梳理比較了4個註冊中心的核心特色。總得來講， 四個註冊中心各有優點
consul 和新晉的 nacos 的社區活躍度比較高， nacos 能夠同時支持 AP 和 CP ； consul 則結合了 zookeeper 和 nacos 的諸多優勢，還自然支持 多數據中心 ；而 zookeeper 則又能夠惟一感知到服務狀態的實時變化； Eureka 的自我保護機制使得它即便只剩下一臺服務，也不影響正常運行，具備高可用性

那麼選擇的時候，究竟應該如何選擇呢？
須要結合業務場景來進行選擇。好比說，對於金融類的業務場景，對於 一致性 要求更高，那麼就會排除掉 Eureka ,而後根據易用性、性價比等其餘方面再進行後續的選擇；對於 高可用 比較注重的項目，如電商類項目，則能夠選擇 Eurek 或者 Nacos ，但再比較其餘方面，Nacos不只能夠作註冊中心，還能夠做爲架構中的配置中心，而且社區活躍度比較高，功能也日漸在完善，使用的人愈來愈多，所以綜合來說，就選擇了 Nacos
具體選擇的過程當中，固然也會考慮這些因素以外的一些特色，包括人員的熟悉度等等，但確定也是先考慮主要的特色，再去考慮這些不是那麼重要的特色的
點個 在看,贊👍支持我吧
   

本文分享自微信公衆號 - 碼農沉思錄（code-thinker）。
若有侵權，請聯繫 support@oschina.cn 刪除。
本文參與「OSC源創計劃」，歡迎正在閱讀的你也加入，一塊兒分享。