1、主流微服務注冊中心對比ZooKeeper、Eureka、Consul、Nacos：
最近微服務架構流行的幾年，公司一共用過3個服務注冊中心，分别是Eureka、Consul和Nacos（正在用😄），下面對這三個注冊中心，進行簡單的比較和分析。
記得之前最早的就是用Nginx，就可以滿足基本的RESTful服務的發現，服務的IP清單配置在Nginx上即可，後來出現了RPC服務，然後就學習了Zookeeper。
說起Zookeeper，肯定要說到Dubbo，Java開發的程式猿或多或少肯定有了解或者采用過，它是阿裡巴巴公司開源的一個高性能優秀的服務架構，使得應用可通過高性能的 RPC 實作服務的輸出和輸入功能，而且又可以和Spring架構無縫內建。主要Dubbo在國内很火，是以Zookeeper就順理成章的作為Dubbo服務的注冊中心，工業強度較高，可用于生産環境，并推薦使用。
Consul和Eureka都出現于2014年，Eureka則借着微服務概念的流行，與SpringCloud生态的深度結合，公司第一個微服務項目就使用Eureka來作為服務注冊中心。而Consul在設計上把很多分布式服務治理上要用到的功能都包含在内，可以支援服務注冊、健康檢查、配置管理、Service Mesh等，17年-18年的項目公司都采用Consul來作為服務注冊中心。2018年釋出并開源的Nacos，則攜帶着阿裡巴巴大規模服務生産經驗，試圖在服務注冊和配置管理這個市場上，提供給使用者一個新的選擇，今年開始我們就選擇Nacos來提供服務注冊和配置中心了。
1）CAP定理，指的是在一個分布式系統中， Consistency（一緻性）、 Availability（可用性）、Partition tolerance（分區容錯性），三者不可得兼。
一緻性（C）：在分布式系統中的所有資料備份，在同一時刻是否同樣的值。（等同于所有節點通路同一份最新的資料副本）
可用性（A）：在叢集中一部分節點故障後，叢集整體是否還能響應用戶端的讀寫請求。（對資料更新具備高可用性）
分區容忍性（P）：以實際效果而言，分區相當于對通信的時限要求。系統如果不能在時限内達成資料一緻性，就意味着發生了分區的情況，必須就目前操作在C和A之間做出選擇。
CAP原則的精髓就是要麼AP，要麼CP，要麼AC，但是不存在CAP。如果在某個分布式系統中資料無副本， 那麼系統必然滿足強一緻性條件， 因為隻有獨一資料，不會出現資料不一緻的情況，此時C和P兩要素具備，但是如果系統發生了網絡分區狀況或者當機，必然導緻某些資料不可以通路，此時可用性條件就不能被滿足，即在此情況下獲得了CP系統，但是CAP不可同時滿足。是以在進行分布式架構設計時，必須做出取舍。
CAP原理
Zookeeper和Consul保證的是CP，而Eureka則是AP，Nacos不僅支援CP也支援AP。
當向注冊中心查詢服務清單時，我們可以容忍注冊中心傳回的是幾分鐘以前的注冊資訊，但不能接受服務直接down掉不可用。也就是說，服務注冊功能對可用性的要求要高于一緻性。但是Zookeeper會出現這樣一種情況，當master節點因為網絡故障與其他節點失去聯系時，剩餘節點會重新進行leader選舉。問題在于，選舉leader的時間太長，30 ~ 120s， 且選舉期間整個Zookeeper叢集都是不可用的，這就導緻在選舉期間注冊服務癱瘓。在雲部署的環境下，因網絡問題使得Zookeeper叢集失去master節點是較大機率會發生的事，雖然服務能夠最終恢複，但是漫長的選舉時間導緻的注冊長期不可用是不能容忍的。
是以Eureka看明白了這一點，是以在設計時就優先保證可用性。Eureka各個節點都是平等的，幾個節點挂掉不會影響正常節點的工作，剩餘的節點依然可以提供注冊和查詢服務。而Eureka的用戶端在向某個Eureka注冊或時如果發現連接配接失敗，則會自動切換至其它節點，隻要有一台Eureka還在，就能保證注冊服務可用(保證可用性)，隻不過查到的資訊可能不是最新的(不保證強一緻性)。除此之外，Eureka還有一種自我保護機制，如果在15分鐘内超過85%的節點都沒有正常的心跳，那麼Eureka就認為用戶端與注冊中心出現了網絡故障，此時會出現以下幾種情況：
- Eureka不再從注冊清單中移除因為長時間沒收到心跳而應該過期的服務
- Eureka仍然能夠接受新服務的注冊和查詢請求，但是不會被同步到其它節點上(即保證目前節點依然可用)
- 當網絡穩定時，目前執行個體新的注冊資訊會被同步到其它節點中
是以， Eureka可以很好的應對因網絡故障導緻部分節點失去聯系的情況，而不會像zookeeper那樣使整個注冊服務癱瘓。
是以當時選用Eureka，一方面是因為Spring Cloud直接内置支援，另外一方面也是上面所說的原因，當然之前也沒用到Dubbo架構，公司項目位址：
https://www.tradeaider.com/web/#/zh-CN/login?redirect=%2Fzh-CN2）Eureka是一個服務發現工具。該體系結構主要是客戶機/伺服器，每個資料中心有一組Eureka伺服器，通常每個可用區域一個。Eureka的用戶端使用嵌入式SDK來注冊和發現服務。對于不是本機內建的客戶機，使用一個sidecar（如Ribbon）通過Eureka透明地發現服務。
Consul提供了一組超級功能，包括更豐富的健康檢查、密鑰/值存儲和多資料中心感覺。Consul在每個資料中心需要一組伺服器，在每個客戶機上需要一個代理，類似于使用類似sidecar的功能區。consul允許通過配置檔案執行服務注冊，并通過DNS或負載平衡器sidecars進行發現。
Consul提供了強大的一緻性保證，因為伺服器使用Raft協定複制狀态。Consul支援一組豐富的健康檢查，包括TCP、HTTP、Nagios/Sensu相容腳本或基于TTL的Eureka。同時Consul提供了支援面向服務體系結構所需的功能工具包。這包括服務發現，但也包括豐富的運作狀況檢查、鎖定、密鑰/值、多資料中心聯合、事件系統和acl。
Eureka1.X版本的實作是基于servlet的Java Web應用，它的極限性能肯定會受到影響。2.X的版本也不開源，停止更新了，是以當時17-18年之間考慮公司新項目選用Consul的原因，公司新項目app可以
點選下載下傳。
3）Consul實際上是和Nacos比較相似的産品，雖然Consul目前的主要發展方向放在了Service Mesh，但是Consul最初支援的服務發現和配置管理，也是Nacos的兩大功能。雖然Nacos在Consul之後以與之相似的部署架構開源，但這并不意味着Nacos在功能和架構上也模仿Consul，Nacos的架構和功能是由阿裡巴巴内部十年的運作演進經驗得來，是以二者的比較也一定會讓大家更加了解他們的定位和演進方向是完全不一樣的。
19年底阿裡雲要全面停止對docker swarm的支援，大力推廣支援k8s了，同時nacos也釋出一年多了，并且有了GA的版本，nacos對k8s支援也很好，是以公司新項目也打算上nacos了（打車項目就在我們的TRIP.ORG項目上新增這個大子產品，大家有興趣的可以來用，出差訂票，住酒店用我們的app産品，每單都有10%-15%的返利，趕緊
點選注冊下載下傳），緊随阿裡雲的步伐😄，這段時間也要把之前老項目從swarm遷移到k8s上。
下面是網上找的幾個主流産品的對比圖，希望能幫到大家更好的了解和選擇産品。
主流微服務産品對比圖
2、總結：
本文簡單介紹了幾塊微服務架構注冊中心的優勢和劣勢，當然内容上有些談的還是比較淺，更多的内容請參考下面的兩個本文參考連結，上面有更詳細的介紹。
本文參考連結：
1、
https://yq.aliyun.com/articles/6989302、
https://www.consul.io/intro/vs/index.html