Spring Cloud Netflix 在設計 Eureka 時就緊遵AP原則（儘管現在2.0釋出了，但是由於其閉源的原因 ，但是目前 Ereka 1.x 任然是比較活躍的）。
Eureka Server 也可以執行多個例項來構建叢集，解決單點問題，但不同於 ZooKeeper 的選舉 leader 的過程，Eureka Server 採用的是Peer to Peer 對等通訊。這是一種去中心化的架構，無 master/slave 之分，每一個 Peer 都是對等的。在這種架構風格中，節點透過彼此互相註冊來提高可用性，每個節點需要新增一個或多個有效的 serviceUrl 指向其他節點。每個節點都可被視為其他節點的副本。
在叢集環境中如果某臺 Eureka Server 宕機，Eureka Client 的請求會自動切換到新的 Eureka Server 節點上，當宕機的伺服器重新恢復後，Eureka 會再次將其納入到伺服器叢集管理之中。當節點開始接受客戶端請求時，所有的操作都會在節點間進行復制（replicate To Peer）操作，將請求複製到該 Eureka Server 當前所知的其它所有節點中。
當一個新的 Eureka Server 節點啟動後，會首先嚐試從鄰近節點獲取所有註冊列表資訊，並完成初始化。Eureka Server 透過 getEurekaServiceUrls() 方法獲取所有的節點，並且會透過心跳契約的方式定期更新。
預設情況下，如果 Eureka Server 在一定時間內沒有接收到某個服務例項的心跳（預設週期為30秒），Eureka Server 將會登出該例項（預設為90秒， eureka.instance.lease-expiration-duration-in-seconds 進行自定義配置）。
Zookeeper
Apache Zookeeper 在設計時就緊遵CP原則，即任何時候對 Zookeeper 的訪問請求能得到一致的資料結果，同時系統對網路分割具備容錯性，但是 Zookeeper 不能保證每次服務請求都是可達的。
從 Zookeeper 的實際應用情況來看，在使用 Zookeeper 獲取服務列表時，如果此時的 Zookeeper 叢集中的 Leader 宕機了，該叢集就要進行 Leader 的選舉，又或者 Zookeeper 叢集中半數以上伺服器節點不可用（例如有三個節點，如果節點一檢測到節點三掛了 ，節點二也檢測到節點三掛了，那這個節點才算是真的掛了），那麼將無法處理該請求。所以說，Zookeeper 不能保證服務可用性。
當然，在大多數分散式環境中，尤其是涉及到資料儲存的場景，資料一致性應該是首先被保證的，這也是 Zookeeper 設計緊遵CP原則的另一個原因。
但是對於服務發現來說，情況就不太一樣了，針對同一個服務，即使註冊中心的不同節點儲存的服務提供者資訊不盡相同，也並不會造成災難性的後果。
因為對於服務消費者來說，能消費才是最重要的，消費者雖然拿到可能不正確的服務例項資訊後嘗試消費一下，也要勝過因為無法獲取例項資訊而不去消費，導致系統異常要好（淘寶的雙十一，京東的618就是緊遵AP的最好參照）。
當master節點因為網路故障與其他節點失去聯絡時，剩餘節點會重新進行leader選舉。問題在於，選舉leader的時間太長，30~120s，而且選舉期間整個zk叢集都是不可用的，這就導致在選舉期間註冊服務癱瘓。
在雲部署環境下， 因為網路問題使得zk叢集失去master節點是大機率事件，雖然服務能最終恢復，但是漫長的選舉事件導致註冊長期不可用是不能容忍的。
Eureka
Spring Cloud Netflix 在設計 Eureka 時就緊遵AP原則（儘管現在2.0釋出了，但是由於其閉源的原因 ，但是目前 Ereka 1.x 任然是比較活躍的）。
Eureka Server 也可以執行多個例項來構建叢集，解決單點問題，但不同於 ZooKeeper 的選舉 leader 的過程，Eureka Server 採用的是Peer to Peer 對等通訊。這是一種去中心化的架構，無 master/slave 之分，每一個 Peer 都是對等的。在這種架構風格中，節點透過彼此互相註冊來提高可用性，每個節點需要新增一個或多個有效的 serviceUrl 指向其他節點。每個節點都可被視為其他節點的副本。
在叢集環境中如果某臺 Eureka Server 宕機，Eureka Client 的請求會自動切換到新的 Eureka Server 節點上，當宕機的伺服器重新恢復後，Eureka 會再次將其納入到伺服器叢集管理之中。當節點開始接受客戶端請求時，所有的操作都會在節點間進行復制（replicate To Peer）操作，將請求複製到該 Eureka Server 當前所知的其它所有節點中。
當一個新的 Eureka Server 節點啟動後，會首先嚐試從鄰近節點獲取所有註冊列表資訊，並完成初始化。Eureka Server 透過 getEurekaServiceUrls() 方法獲取所有的節點，並且會透過心跳契約的方式定期更新。
預設情況下，如果 Eureka Server 在一定時間內沒有接收到某個服務例項的心跳（預設週期為30秒），Eureka Server 將會登出該例項（預設為90秒， eureka.instance.lease-expiration-duration-in-seconds 進行自定義配置）。
當 Eureka Server 節點在短時間內丟失過多的心跳時，那麼這個節點就會進入自我保護模式。
Eureka的叢集中，只要有一臺Eureka還在，就能保證註冊服務可用（保證可用性），只不過查到的資訊可能不是最新的（不保證強一致性）。除此之外，Eureka還有一種自我保護機制，如果在15分鐘內超過85%的節點都沒有正常的心跳，那麼Eureka就認為客戶端與註冊中心出現了網路故障，此時會出現以下幾種情況：
Eureka不再從登錄檔中移除因為長時間沒有收到心跳而過期的服務；
Eureka仍然能夠接受新服務註冊和查詢請求，但是不會被同步到其它節點上（即保證當前節點依然可用）；
當網路穩定時，當前例項新註冊的資訊會被同步到其它節點中；
因此，Eureka可以很好的應對因網路故障導致部分節點失去聯絡的情況，而不會像zookeeper那樣使得整個註冊服務癱瘓。
Nacos：
Nacos是阿里開源的，Nacos 支援基於 DNS 和基於 RPC 的服務發現。在Spring Cloud中使用Nacos，只需要先下載 Nacos 並啟動 Nacos server，Nacos只需要簡單的配置就可以完成服務的註冊發現。Nacos跟eureka一樣，也是走AP原則的。
Nacos除了服務的註冊發現之外，還支援動態配置服務。動態配置服務可以讓您以中心化、外部化和動態化的方式管理所有環境的應用配置和服務配置。動態配置消除了配置變更時重新部署應用和服務的需要，讓配置管理變得更加高效和敏捷。配置中心化管理讓實現無狀態服務變得更簡單，讓服務按需彈性擴充套件變得更容易。
一句話概括就是Nacos = Spring Cloud註冊中心 + Spring Cloud配置中心。