簡書里的文章：Spring Cloud Eureka簡介及與Zookeeper對比，明顯的區別可能就是Zookeeper為CP設計，而Eureka為AP設計，但是對CAP/AP/CP很不理解，於是查閱資料，做一個簡單的了解。
Eureka服務治理機制與Dubbo服務治理機制的比較
Feature Eureka Zookeeper 服務健康檢查 可配支持 (弱)長連接，keepalive CAP AP CP watch支持（客戶端觀察到服務提供者變化） 支持 long polling/大部分增量 支持 自我保護 支持 - 客戶端緩存 支持 - 自身集群的監控 metrics - Eureka支持健康檢查，自我保護等
Zookeeper為CP設計，Eureka為AP設計。作為服務發現產品，可用性優先級較高，一致性的特點並不重要，寧可返回錯誤的數據，也比不反回結果要好得多。
服務列表變更Zookeeper服務端會有通知，Eureka則通過長輪詢來實現，Eureka未來會實現watch機制
CAP理論提出就是針對分布式數據庫環境的，所以，P這個屬性是必須具備的。
P就是在分布式環境中，由於網絡的問題可能導致某個節點和其它節點失去聯系，這時候就形成了P(partition)，也就是由於網絡問題，將系統的成員隔離成了2個區域，互相無法知道對方的狀態，這在分布式環境下是非常常見的。
因為P是必須的，那么我們需要選擇的就是A和C。
大家知道，在分布式環境下，為了保證系統可用性，通常都采取了復制的方式，避免一個節點損壞，導致系統不可用。那么就出現了每個節點上的數據出現了很多個副本的情況，而數據從一個節點復制到另外的節點時需要時間和要求網絡暢通的，所以，當P發生時，也就是無法向某個節點復制數據時，這時候你有兩個選擇：
選擇可用性 A(Availability)，此時，那個失去聯系的節點依然可以向系統提供服務，不過它的數據就不能保證是同步的了（失去了C屬性）。
選擇一致性C(Consistency)，為了保證數據庫的一致性，我們必須等待失去聯系的節點恢復過來，在這個過程中，那個節點是不允許對外提供服務的，這時候系統處於不可用狀態(失去了A屬性)。
最常見的例子是讀寫分離，某個節點負責寫入數據，然后將數據同步到其它節點，其它節點提供讀取的服務，當兩個節點出現通信問題時，你就面臨着選擇A（繼續提供服務，但是數據不保證准確），C（用戶處於等待狀態，一直等到數據同步完成）。