簡書裡的文章：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（使用者處於等待狀態，一直等到資料同步完成）。