Zookeeper 保證了CP（C：一致性，P：分區容錯性），Eureka保證了AP（A：高可用）
【1】當向註冊中心查詢服務列表時，我們可以容忍註冊中心返回的是幾分鐘以前的信息，但不能容忍直接 down 掉不可用。也就是說，服務註冊功能對高可用性要求比較高，但 zk 會出現這樣一種情況，當 master 節點因爲網絡故障與其他節點失去聯繫時，剩餘節點會重新選 leader。問題在於，選取 leader 時間過長，30 ~ 120s，且選取期間 zk 集羣都不可用，這樣就會導致選取期間註冊服務癱瘓。在雲部署的環境下，因網絡問題使得 zk 集羣失去 master 節點是較大概率會發生的事，雖然服務能夠恢復，但是漫長的選取時間導致的註冊長期不可用是不能容忍的。
【2】Eureka 保證了可用性，Eureka 各個節點是平等的，掛掉幾個節點不會影響正常節點的工作，剩餘的節點仍然可以提供註冊和查詢服務。而 Eureka 的客戶端向某個 Eureka 註冊或發生連接失敗，則會自動切換到其他節點，只要有一臺 Eureka 還在，就能保證註冊服務可用，只是查到的信息可能不是最新的。除此之外，Eureka 還有自我保護機制，如果在15分鐘內超過85%的節點沒有正常的心跳，那麼 Eureka 就認爲客戶端與註冊中心發生了網絡故障，此時會出現以下幾種情況：
①、Eureka 不在從註冊列表中移除因爲長時間沒有收到心跳而應該過期的服務。
②、Eureka 仍然能夠接受新服務的註冊和查詢請求，但是不會被同步到其他節點上（即保證當前節點仍然可用）
③、當網絡穩定時，當前實例中新的註冊信息會被同步到其他節點。
因此，Eureka 可以很好的應對因網絡故障導致部分節點失去聯繫的情況，而不會像 Zookeeper 那樣使整個微服務癱瘓。