做爲架構師的我，微服務註冊中心該如何選型

我只總結乾貨，不喜歡扯爐子。確定還有不少方面沒有涉及到，但願各位指出。ths~

市面上流行的開源註冊中心不少，耳熟能詳的有 Eureka、Zookeeper、Nacos、Consul。咱們在選型的時候也主要從這四個組件中進行篩選。下面就對咱們內部的討論內容進行整理：

第一個維度：開源公司的實力

Eureka 是 Netflix 公司出品的一款註冊中心，Netflix 是一家美國公司，主要作在線影片租賃提供商。嗯.....，相似於愛奇藝吧。2012-2014開源，發佈了一個 release版本；Spring Cloud 是基於 Netflix Eureka 作了二次封裝。Eureka提供官方的控制檯來查詢服務註冊狀況【構建流程】。可是，Eureka 2.0 在2018年宣佈中止開發，但畢竟是開源的，因此有一羣小夥伴還在維護着，可是不會有新功能的添加，它們主要是對目前版本的bug的修復。比較巧的是 Nacos18年開源了。Eureka 服務實例規模在5000左右的時候，就已經出現服務不可用的問題（咱們不選擇它的主要緣由），甚至在壓測的過程當中，若是併發的線程數太高，就會形成 Eureka crash。不過若是服務規模在1000上下，幾乎目前全部的註冊中心均可以知足。可是它也有優勢就是穩定，穩定，像銀行這種微服務仍是比較適合的。不選它的緣由是源碼無更新，沒有新功能。同時，當併發和註冊用戶達到必定量級的時候就會出現性能問題和不支持K8S。

Zookeeper 是 Google 對Chubby一個開源的實現，後來託管到Apache，於2010年11月正式成爲 Apache的頂級項目。咱們也習慣性的稱它爲動物園。在大數據領域極爲普遍，是 Hadoop和 Hbase的重要組件。它是一個爲分佈式應用提供服務的軟件，提供的功能包括：配置維護、域名服務、分佈式同步等等。是一款經典的服務註冊中心產品（雖然它最初的定位並不在於此）在很長一段時間裏，它是國人在提起 RPC服務註冊中心時內心想到的惟一選擇，這很大程度上與Dubbo在中國的普及程度有關。不選它的緣由是不能與SpringCloud集成，同時ZooKeeper使用的 ZAB協議，因爲是單點寫，在集羣擴展性上不具有優點。

Nacos 是國產的組件，由阿里巴巴在2018年開源，2019年1.0發佈。此刻，應該有掌聲，哈哈。Nacos 是 Dynamic Naming and Configuration Service 的縮寫，動態命名和配置服務。Nacos 是阿里開源的註冊中心+ 配置中心（配置中心咱們使用的是攜程的阿波羅，這個後面聊）服務。Nacos提供官方的控制檯來查詢服務註冊狀況，但若是在公司，通常只有運維大佬有這個權限訪問控制檯來對裏面的服務刪除等危險操做，像咱們公司單獨開發了一套Nacos控制檯管理，權限對開發是比較小的，一些毀滅性的權限，是不會給它們分配的。 後續還會繼續加強控制臺的能力，增長控制檯登陸和權限的管控，監控體系和 Metrics的暴露。Nacos 服務實例註冊的支撐量約爲100萬，服務的數量能夠達到10萬以上。由於 Nacos 服務之間經過 Raft 算法保證一致性，因此建議 Nacos 部署的節點數爲大於 3 的奇數。咱們最終也是選擇使用 Nacos 做爲註冊中心。

Consul 是 HashiCorp 公司出品的開源工具，使用Go 語言編寫，也是一家美國公司，致力於爲企業提供服務（它牛逼的功能沒有對外開源，是對企業收費的）。Consul 遵循 CAP原理中的 CP原則（跟ZK保持的同樣），保證了強一致性和分區容錯性。雖然保證了強一致性，可是可用性就相應降低了，例如服務註冊的時間會稍長一些，由於Consul 的 raft 協議要求必須過半數的節點都寫入成功才認爲註冊成功 ；在 leader掛掉了以後，從新選舉出 leader以前會致使 Consul 服務不可用。不選擇的緣由，自己就是基於CP捨棄了 A，而咱們看中的就是A（有效性）。

中美貿易戰對咱們的影響：2020年5月29日禁止 HashiCorp（Consul的公司） 在中華人民共和國銷售或以其餘方式提供企業版本的產品，包括Consul企業版。目前不涉及到開源產品。

第二個維度：社區活躍度

Eureka 核心代碼停滯在2年前，源碼地址【GitHub】根據下圖咱們獲得的數據是：關注該項目的有 961次，點讚的9.4k，拉取項目次數 2.7k。咱們看項目commit 的時間都是比較舊的了，目前開源社區有人維護，全部偶爾也會有代碼提交，基本都是bug的修復。

2.0放棄維護聲明以下，1.x 相對穩定。若是大家還在使用，後續有必要遷移到其餘開源微服務註冊中心【連接】。

Zookeeper持續更新，源碼地址 【GitHub】根據下圖咱們獲得的數據是：關注該項目的有 661次，點讚的8.2k，拉取項目次數 5.2k。拉取的比Eureka多，當時國內流行 RPC分佈式調用的時候，仍是不少的。項目在2小時前也有代碼提交，仍是很活躍的。只是不太適合做爲咱們目前說的微服務註冊中心。

Nacos 持續更新，源碼地址【GitHub】根據下圖咱們獲得的數據是：關注該項目的有 750次，點讚的12.6k，拉取項目次數 4k。18年開源的，可是目前從數據上看是將來微服務開發的趨勢。據我瞭解目前不少公司，有能力遷移的都從Eureka遷移到了Nacos，由於它們碰見了性能問題。代碼更新也是前一天就有更新，這裏說下阿里的壞毛病，就是喜歡改項目名稱或者就不維護了（借鑑Dubbo等）可是微服務這塊你們就不用怕了，由於它託管給了 SpringCloud了，也就是 SpringCloudAlibaba。嗯...仍是值得信賴的。其實，Nacos基本都是咱們國內的公司再用，但我相信很快它仍是可以在國外打下一片江山，畢竟是通過阿里雙十一洗禮過的中間件。

Nacos 開發團隊：阿里巴巴、虎牙直播，都是中國人就貼出來。詳細信息本身能夠上官網看看 【連接】

Nacos 1.0 發佈時間點，2019.4.10 正式發佈1.0 版本。

Consul 持續更新，源碼地址【GitHub】根據下圖咱們獲得的數據是：關注該項目的有 985次，點讚的19.4k，拉取項目次數 3.3k。其實不少人沒怎麼聽過，可是使用的也很多，由於使用它的基本都是國外的公司，Consul和Nacos 其實很像，咱們在後面有一張對比圖你們也能看到二者差異不大，但Nacos仍是比Consul牛逼。嗯...打壓下你們的心情，其實，Consul牛逼的功能沒有開源，哈哈。是付了錢才能用的。。

第三個維度：社區用戶羣

Eureka、Consul 在2014開源，時間早，存在大量用戶，中文文檔資料也比較豐富。
Nacos 在2018開源，2019發佈1.0版本，比較年輕，社區用戶以國內爲主，中文文檔資料也比較豐富。目前市面上用戶羣：阿里巴巴、虎牙直播、中國工商銀行、愛奇藝、中國平安、平安科技、浙江農信、貝殼、豐巢、百世快遞、汽車之家等。平安科技根據需求將 Eureka 和 Nacos 都進行了使用。是否是大家的公司也在裏面，驕傲一波。。若是沒有，點這個連接Who is Using

Zookeeper 開源的比較早 2010年就開源，目前用戶量都來自大數據那邊，中文文檔也比較豐富。這個就留給大數據大小夥伴，這裏就很差好介紹了。

Spring Cloud 生態整合：獲得Spring Cloud 開源組織的承認的有兩個：
【1】 Spring Cloud Alibaba（鼓掌）：https://spring.io/projects/spring-cloud-alibaba
【2】Spring Cloud Netflix：https://spring.io/projects/spring-cloud-netflix

第四個維度：成熟穩定性

RESTful API 支持：Eureka & Nacos
■ 都有RESTful API 支持，能夠經過定製化開發，巡檢註冊中心的穩定性；
■ Nacos Open API的更豐富一些；
■ Eureka Restful 參考地址
■ Nacos Restful 參考地址

Nacos兜底策略：選Nacos就對了
■ 人員招聘：跟進開源社區，技術交流；
■ Nacos註冊中心，健康檢查：
 – 服務實例的健康狀態；
 – 服務實例的數量（包括健康、不健康）；
 – 服務節點的健康狀態；

其實選擇用哪一個註冊中心的時候，都是從業務的角度考慮的，因此之後選型的時候，帶着這張表就解決一大半問題：

功能	Nacos	Eureka	Consul	Zookeeper
協議	CP+AP	AP	CP	CP
負載均衡	weight/metadata/Selector	Rabbon	Fabio	-
監聽機制	支持	支持	支持	不支持
自動註銷實例	支持	支持	不支持	支持
雪崩保護	有	有	無	無
心跳檢測	TCP/HTTP/MYSQL/Client Beat	Client Beat	TCP/HTTP/gRPC/Cmd	Keep Alive
訪問協議	HTTP/DNS	HTTP	HTTP/DNS	TCP
多數據中心	支持	支持	支持	不支持
SpringCloud集成	支持	支持	支持	不支持
跨註冊中心同步	支持	不支持	支持	不支持
K8S集成	支持	不支持	支持	不支持
Dubbo集成	支持	不支持	不支持	支持

第五個維度：負載均衡的策略

其實，負載均衡並不算是傳統註冊中心的功能。咱們都知道服務發現的流程是先從註冊中心獲取到服務的實例列表，而後再根據自身的需求，來選擇其中的部分實例或者按照必定的流量分配機制來訪問不一樣的服務提供者，因此註冊中心自己通常不參與服務消費者的訪問策略。Eureka、ZooKeeper包括Consul，自己都沒有去實現可配置及可擴展的負載均衡機制，Eureka的負載均衡是由 Ribbon來完成的，而 Consul則是由 Fabio作負載均衡。

重點來了，阿里巴巴根據本身的業務場景，必須使用的相反的思路。服務消費者並不關心所訪問的服務提供者的負載均衡策略，消息者要的是以最高效的方式訪問提供者的服務。服務提供者則須要很是關注自身被訪問的流量的調配，緣由就是阿里巴巴內部服務訪問流量巨大，稍有不慎就會致使流量異常壓垮服務提供者的服務。所以服務提供者須要可以徹底掌控服務的流量調配，並能夠動態調整。服務端的負載均衡，給服務提供者更強的流量控制權，可是沒法知足不一樣的消費者但願使用不一樣負載均衡策略的需求。而不一樣負載均衡策略的場景也確實存在。客戶端的負載均衡則提供了這種靈活性，並對用戶擴展提供更好的支持。可是客戶端負載均衡存在的問題就是可能會致使服務提供者出現熱點，或者壓根就拿不到任何服務提供者。因此根據咱們的場景只能選基於流量限制的 Sentinel，後面再好好嘮這個。

生態中大禮包組件：Spring Cloud Alibaba 和 Netflix生態大禮包對比

組件	SpringCloud 官方	SpringCloud Netflix	SpringCloud Alibaba	咱們的選擇
分佈式配置	SpringCloud Config	Archaius	Nacos	Ctrip Apollo（攜程）
服務註冊和發現	-	Eureka(中止更新）	Nacos	Eureka/Nacos?
服務熔斷	-	Hystrix(維護狀態)	Sentinel	Sentinel
服務路由	Gateway	Zuul(維護狀態）	-	Gateway/Zuul
分佈式消息	RabbitMQ	-	RocketMQ
負載均衡	LoadBalancer	Ribbon		F五、Ribbon
分佈式事務	-	-	Seata	最終事務一致性

Nacos相關資料，關注後回覆 "nacos"