著名的CAP理論指出，一個分佈式系統不可能同時滿足C(一致性)、A(可用性)和P(分區容錯性)。由於分區容錯性在是分佈式系統中必須要保證的，因此我們只能在A和C之間進行權衡。在此Zookeeper保證的是CP, 而Eureka則是AP。
對於CAP不太熟悉的可以查看下面博客
接下來我們從ZK和Eureka 設計實現上一步步分析
ZK服務註冊原理（CP）
zookeeper可以作爲註冊中心，也可用於服務治理（zookeeper還有其他用途，例如：分佈式事務鎖等）
當消費端啓動時候會去zookeeper上訂閱path(例如:/dubbo/com.test.demo.api/providers)下面的信息，也就是服務提供者列表信息，那麼我們就可以基於這個原理來獲取某一個服務提供者列表，然後對信息進行過濾加工，並且註冊一個監聽器，當服務提供者機器增減後，動態更新保存的地址列表。
1.每啓動一個微服務，就會去zk中註冊一個臨時子節點(ZK集羣完成一致性確認,保存數據)
2.服務訂閱,拉取服務列表,並註冊一個監聽(zk的watch機制,不熟悉的可以簡單去百度瞭解下)
3.每當有一個服務down機或者新的微服務註冊進來，由於是臨時接點，此節點會立即被刪除或者添加一個，並通知訂閱該服務（2中註冊了監聽的服務）的微服務更新服務列表（zk的watch機制，每當有節點更新，都會通知訂閱該服務的微服務更新服務列表）
注：服務提供者全部宕掉後，服務消費者應用將無法使用，並無限次重連等待服務提供者恢復
ZK爲什麼是CP？
當向註冊中心查詢服務列表時，我們可以容忍註冊中心返回的是幾分鐘以前的註冊信息，但不能接受服務直接down掉不可用。也就是說，服務註冊功能對可用性的要求要高於一致性(但是也會存在一點點延遲,畢竟需要網絡傳輸和數據拉取處理,一般可能就幾十毫秒,很短的時間)。但是zk會出現這樣一種情況，當master節點因爲網絡故障與其他節點失去聯繫時，剩餘節點會重新進行leader選舉。問題在於，選舉leader的時間太長，30 ~ 120s, 且選舉期間整個zk集羣都是不可用的，這就導致在選舉期間註冊服務癱瘓。在雲部署的環境下，因網絡問題使得zk集羣失去master節點是較大概率會發生的事，雖然服務能夠最終恢復，但是漫長的選舉時間導致的註冊長期不可用是不能容忍的(這也就是ZK的缺點之一,犧牲部分的可用性)。
Eureka服務註冊原理(AP)
Eureka看明白了這一點，因此在設計時就優先保證可用性。Eureka各個節點都是平等的，幾個節點掛掉不會影響正常節點的工作，剩餘的節點依然可以提供註冊和查詢服務。而Eureka的客戶端在向某個Eureka註冊或時如果發現連接失敗，則會自動切換至其它節點，就算全部掛掉，服務還能通過讀取本地緩存的服務列表信息來進行調用,就能保證註冊服務可用(保證可用性)，只不過查到的信息可能不是最新的(不保證強一致性)(注：前提是服務提供者的ip:port信息沒有發生變化)。
除此之外，Eureka還有一種自我保護機制，如果在15分鐘內超過85%的節點都沒有正常的心跳，那麼Eureka就認爲客戶端與註冊中心出現了網絡故障，此時會出現以下幾種情況：
1. Eureka不再從註冊列表中移除因爲長時間沒收到心跳而應該過期的服務
2. Eureka仍然能夠接受新服務的註冊和查詢請求，但是不會被同步到其它節點上(即保證當前節點依然可用)
3. 當網絡穩定時，當前實例新的註冊信息會被同步到其它節點中
因此， Eureka可以很好的應對因網絡故障導致部分節點失去聯繫的情況，而不會像zookeeper那樣使整個註冊服務癱瘓。
1.服務B進行服務註冊,並定時發送心跳(根據配置的規則 進行不達標節點下線)
2.Eureka接收註冊信息後, 一是本地註冊信息更新（同步）；二是將消息廣播給其它服務器（異步）。
由此也可以看出 Eureka 是 AP 模型的，優先保障了可用性，事實上大多數註冊中心的實現方案都是 AP 模型，只有 ZK 是 CP 模型。事實上，ZK 是分佈式協調服務，並不是專門用來進行服務治理的。
3.服務A定時拉取最新的服務信息並緩存在本地
基於eureka的實現原理,可以看出它優先保證了可用性,犧牲了數據一致性,但並不是說集羣中的數據是不一致的,集羣中每個節點的數據同步延遲時間比較長而已,如果使用Eureka默認的配置信息,數據服務A要獲取到最新的服務列表信息 延遲可能是幾十秒甚至幾分鐘,因此,線上生產環境往往會對Eureka 進行調優,使發送心跳,拉取服務,定時檢查等定時服務間隔時間調短,來達到服務信息延遲降低的目的。
總結:
基於CAP理論來說,很多人說 Eureka作爲單純的服務註冊中心來說要比zookeeper更加“專業”，因爲註冊服務更重要的是可用性，我們可以接受短期內達不到一致性的狀況。但其實呢,個人認爲技術不分優劣,更多的在於適不適合你的項目技術架構,你的服務是需要保證AP還是需要保證CP,能否容忍技術帶來的不便之處,綜合比較,選取最合適的技術纔是最關鍵的。