咱們都說本年是互聯網隆冬，可是前段時刻有個讀者很快樂的跟我聊天說他去京東了。我問他都問了什麼問題？他說問了很多微效勞相關的，其中有一個問題就是：同樣是註冊中心，你覺得 zookeeper 和 eureka 哪個更好？
剛好最近也在看微效勞相關的東西，乾脆就針對這個問題，簡略總結一下 zookeeper 和 eureka 之間的差異，希望讀者能夠從中得到有用的東西。
0. CAP 理論
在總結兩者的差異之前，咱們先來看一個 CAP 理論。什麼叫 CAP 理論呢？CAP 理論是由 Eric Brewer 教授提出，是分佈式體系中的一個重要的概念。CAP 詳細如下：
C（Consistency）：數據共同性。咱們都知道，分佈式體系中，數據會有副本。由於網絡或許機器故障等因素，或許有些副本數據寫入正確，有些卻寫入錯誤或許失利，這樣就導致了數據的不共同了。而滿意數據共同性規則，就是確保一切數據都要同步。
A（Availability）：可用性。咱們需要獲取什麼數據時，都能夠正常的獲取到想要的數據（當然，允許可承受範圍內的網絡延遲），也就是說，要確保任何時分懇求數據都能夠正常響應。
P（Partition Tolerance）：分區容錯性。當網絡通信發作故障時，集群仍然可用，不會由於某個節點掛了或許存在問題，而影響整個體系的正常運作。
關於分佈式體系來說，出現網絡分區是不可避免的，因而分區容錯性是必需要具有的，也就是說，CAP三者，P是有必要的，是個客觀存在的現實，不可避免，也無法繞過。
1. Zookeeper 的 CP 準則
關於 zookeeper 來說，它是 CP 的。也就是說，zookeeper 是確保數據的共同性的，可是這兒還需要注意一點是，zookeeper 它不是強共同的，什麼意思呢？打個比如，現在客戶端 A 提交一個寫操作，zookeeper 在過對摺節點操作成功之後就能夠返回，但此時，客戶端 B 的讀操作懇求的是 A 寫操作沒有同步到的節點，那麼讀取的就不是 A 最新提交的數據了。
那如何確保強共同性呢？咱們能夠在讀取數據的時分先履行一下 sync 操作，即與 leader 節點先同步一下數據，再去取，這樣才能確保數據的強共同性。
可是 zookeeper 也有個缺點，剛剛提到了 leader 節點，當 master 節點由於網絡故障與其他節點失掉聯繫時，剩下節點會重新進行 leader 推舉。問題在於，推舉 leader 的時刻太長，30 ~ 120s, 且推舉期間整個 zookeeper 集群都是不可用的，這就導致在推舉期間註冊效勞癱瘓。
在雲部署的環境下，因網絡問題使得 zookeeper 集群失掉 master 節點是較大概率會發作的事，雖然效勞能夠終究康復，可是綿長的推舉時刻導致的註冊長期不可用是不能忍受的。比如雙十一當天，那就是災難性的。
2. Eureka 的 AP 準則
大規模網絡部署時，失利是在所難免的，因而咱們無法迴避這個問題。當向註冊中心查詢效勞列表時，咱們能夠忍受註冊中心返回的是幾分鐘曾經的註冊信息，但不能承受效勞直接 down 掉不可用。
Eureka 在被設計的時分，就考慮到了這一點，因而在設計時優先確保可用性，這就是 AP 準則。Eureka 各個節點都是相等的，幾個節點掛掉不會影響正常節點的工作，剩下的節點依然能夠供給註冊和查詢效勞。而 Eureka 的客戶端在向某個 Eureka 註冊或時如果發現連接失利，則會自動切換至其它節點，只要有一臺 Eureka 還在，就能確保註冊效勞可用（即確保A準則），只不過查到的信息或許不是最新的（不確保C準則）。
正由於應用實例的註冊信息在集群的一切節點間並不是強共同的，所以需要客戶端能夠支持負載均衡以及失利重試。在 Netflix 的生態中，ribbon 能夠供給這個功能。
因而， Eureka 能夠很好的應對因網絡故障導致部分節點失掉聯繫的狀況，而不會像 zookeeper 那樣使整個註冊效勞癱瘓。
3. 元芳，你怎麼看？
作為效勞註冊中心，最重要的是要確保可用性，能夠承受短時刻內數據不共同的狀況。個人覺得 Eureka 作為單純的效勞註冊中心來說要比 zookeeper 愈加“專業”一點。
不過 eureka2.x 分支不再保護，可是 eureka1.x 官方還在保護，現在最新 RELEASE 版本是 1.9.9，所以並不是像網上說的 eureka 涼了啥的。
Eureka 是隨著 Spring Cloud 被人們熟知，可是 Spring Cloud 支持使用 eureka、zookeeper、consul 實現效勞發現的能力。從 eureka 切換成 zookeeper 只需要改個依靠，改幾行裝備就能夠了。更多的是要多瞭解它們的原理和差異。
閱讀更多 java高級架構 的文章
