這里就平時經常用到的服務發現的產品進行下特性的對比，首先看下結論:
| Feature | Consul | zookeeper | etcd | euerka |
|---|---|---|---|---|
| 服務健康檢查 | 服務狀態，內存，硬盤等 | (弱)長連接，keepalive | 連接心跳 | 可配支持 |
| 多數據中心 | 支持 | — | — | — |
| kv存儲服務 | 支持 | 支持 | 支持 | — |
| 一致性 | raft | paxos | raft | — |
| cap | cp | cp | cp | ap |
| 使用接口(多語言能力) | 支持http和dns | 客戶端 | http/grpc | http（sidecar） |
| watch支持 | 全量/支持long polling | 支持 | 支持 long polling | 支持 long polling/大部分增量 |
| 自身監控 | metrics | — | metrics | metrics |
| 安全 | acl /https | acl | https支持（弱） | — |
| spring cloud集成 | 已支持 | 已支持 | 已支持 | 已支持 |
Eureka是一個服務發現工具。該體系結構主要是客戶端/服務器，每個數據中心有一組Eureka服務器，通常每個可用區域一個。通常Eureka的客戶使用嵌入式SDK來注冊和發現服務。對於非本地集成的客戶，使用功能區邊框等透過Eureka透明地發現服務。
Eureka提供了一個弱一致的服務視圖，使用盡力而為復制。當客戶端向服務器注冊時，該服務器將嘗試復制到其他服務器，但不提供保證。服務注冊的生存時間（TTL）較短，要求客戶端對服務器心存感激。不健康的服務或節點將停止心跳，導致它們超時並從注冊表中刪除。發現請求可以路由到任何服務，由於盡力而為的復制，這些服務可能會導致陳舊或丟失數據。這個簡化的模型允許簡單的群集管理和高可擴展性。
CONSUL提供了一套超級功能，包括更豐富的健康檢查，關鍵/價值存儲以及多數據中心意識。Consul需要每個數據中心都有一套服務器，以及每個客戶端的代理，類似於使用像Ribbon這樣的負載均衡。Consul代理允許大多數應用程序成為Consul不知情者，通過配置文件執行服務注冊並通過DNS或負載平衡器sidecars發現。
Consul提供強大的一致性保證，因為服務器使用Raft協議復制狀態 。Consul支持豐富的健康檢查，包括TCP，HTTP，Nagios / Sensu兼容腳本或基於Eureka的TTL。客戶端節點參與基於Gossip的健康檢查，該檢查分發健康檢查工作，而不像集中式心跳檢測那樣成為可擴展性挑戰。發現請求被路由到選舉出來的領事領導，這使他們默認情況下強烈一致。允許陳舊讀取的客戶端使任何服務器都可以處理他們的請求，從而實現像Eureka這樣的線性可伸縮性。
Consul強烈的一致性意味着它可以作為領導選舉和集群協調的鎖定服務。Eureka不提供類似的保證，並且通常需要為需要執行協調或具有更強一致性需求的服務運行ZooKeeper。
Consul提供了支持面向服務的體系結構所需的一系列功能。這包括服務發現，還包括豐富的運行狀況檢查，鎖定，密鑰/值，多數據中心聯合，事件系統和ACL。Consul和consul-template和envconsul等工具生態系統都試圖盡量減少集成所需的應用程序更改，以避免需要通過SDK進行本地集成。Eureka是一個更大的Netflix OSS套件的一部分，該套件預計應用程序相對均勻且緊密集成。因此，Eureka只解決了一小部分問題，希望ZooKeeper等其他工具可以一起使用。
ZooKeeper與Eureka的區別：
Apache Zookeeper -> CP
與 Eureka 有所不同，Apache Zookeeper 在設計時就緊遵CP原則，即任何時候對 Zookeeper 的訪問請求能得到一致的數據結果，同時系統對網絡分割具備容錯性，但是 Zookeeper 不能保證每次服務請求都是可達的。從 Zookeeper 的實際應用情況來看，在使用 Zookeeper 獲取服務列表時，如果此時的 Zookeeper 集群中的 Leader 宕機了，該集群就要進行 Leader 的選舉，又或者 Zookeeper 集群中半數以上服務器節點不可用（例如有三個節點，如果節點一檢測到節點三掛了 ，節點二也檢測到節點三掛了，那這個節點才算是真的掛了），那么將無法處理該請求。所以說，Zookeeper 不能保證服務可用性。
當然，在大多數分布式環境中，尤其是涉及到數據存儲的場景，數據一致性應該是首先被保證的，這也是 Zookeeper 設計緊遵CP原則的另一個原因。但是對於服務發現來說，情況就不太一樣了，針對同一個服務，即使注冊中心的不同節點保存的服務提供者信息不盡相同，也並不會造成災難性的后果。因為對於服務消費者來說，能消費才是最重要的，消費者雖然拿到可能不正確的服務實例信息后嘗試消費一下，也要勝過因為無法獲取實例信息而不去消費，導致系統異常要好（淘寶的雙十一，京東的幺六八就是緊遵AP的最好參照）。
當master節點因為網絡故障與其他節點失去聯系時，剩余節點會重新進行leader選舉。問題在於，選舉leader的時間太長，30~120s，而且選舉期間整個zk集群都是不可用的，這就導致在選舉期間注冊服務癱瘓。在雲部署環境下， 因為網絡問題使得zk集群失去master節點是大概率事件，雖然服務能最終恢復，但是漫長的選舉事件導致注冊長期不可用是不能容忍的。
Spring Cloud Eureka -> AP
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 Server 的自我保護機制）。
Eureka的集群中，只要有一台Eureka還在，就能保證注冊服務可用（保證可用性），只不過查到的信息可能不是最新的（不保證強一致性）。除此之外，Eureka還有一種自我保護機制，如果在15分鍾內超過85%的節點都沒有正常的心跳，那么Eureka就認為客戶端與注冊中心出現了網絡故障，此時會出現以下幾種情況：
- Eureka不再從注冊表中移除因為長時間沒有收到心跳而過期的服務；
- Eureka仍然能夠接受新服務注冊和查詢請求，但是不會被同步到其它節點上（即保證當前節點依然可用）；
- 當網絡穩定時，當前實例新注冊的信息會被同步到其它節點中；
因此，Eureka可以很好的應對因網絡故障導致部分節點失去聯系的情況，而不會像zookeeper那樣使得整個注冊服務癱瘓。
在CAP中，Consul使用CP體系結構，有利於實現可用性的一致性。
最大的區別是Eureka保證AP, Consul為CP。
Consul強一致性(C)帶來的是：
- 服務注冊相比Eureka會稍慢一些。因為Consul的raft協議要求必須過半數的節點都寫入成功才認為注冊成功
- Leader掛掉時，重新選舉期間整個consul不可用。保證了強一致性但犧牲了可用性。
Eureka保證高可用(A)和最終一致性：
- 服務注冊相對要快，因為不需要等注冊信息replicate到其他節點，也不保證注冊信息是否replicate成功
- 當數據出現不一致時，雖然A, B上的注冊信息不完全相同，但每個Eureka節點依然能夠正常對外提供服務，這會出現查詢服務信息時如果請求A查不到，但請求B就能查到。如此保證了可用性但犧牲了一致性。
其他方面，eureka就是個servlet程序，跑在servlet容器中; Consul則是go編寫而成。
這里就平時經常用到的服務發現的產品進行下特性的對比，首先看下結論:
- Euraka 使用時需要顯式配置健康檢查支持；Zookeeper,Etcd 則在失去了和服務進程的連接情況下任務不健康，而 Consul 相對更為詳細點，比如內存是否已使用了90%，文件系統的空間是不是快不足了。服務的健康檢查
- 多數據中心支持
Consul 通過 WAN 的 Gossip 協議，完成跨數據中心的同步；而且其他的產品則需要額外的開發工作來實現；
- KV 存儲服務
除了 Eureka ,其他幾款都能夠對外支持 k-v 的存儲服務，所以后面會講到這幾款產品追求高一致性的重要原因。而提供存儲服務，也能夠較好的轉化為動態配置服務哦。
- 產品設計中 CAP 理論的取舍
Eureka 典型的 AP,作為分布式場景下的服務發現的產品較為合適，服務發現場景的可用性優先級較高，一致性並不是特別致命。其次 CP 類型的場景 Consul,也能提供較高的可用性，並能 k-v store 服務保證一致性。 而Zookeeper,Etcd則是CP類型 犧牲可用性，在服務發現場景並沒太大優勢；
- 多語言能力與對外提供服務的接入協議
Zookeeper的跨語言支持較弱，其他幾款支持 http11 提供接入的可能。Euraka 一般通過 sidecar的方式提供多語言客戶端的接入支持。Etcd 還提供了Grpc的支持。 Consul除了標准的Rest服務api,還提供了DNS的支持。
- Watch的支持（客戶端觀察到服務提供者變化）
Zookeeper 支持服務器端推送變化，Eureka 2.0(正在開發中)也計划支持。 Eureka 1,Consul,Etcd則都通過長輪詢的方式來實現變化的感知；
- 自身集群的監控
除了 Zookeeper ,其他幾款都默認支持 metrics，運維者可以搜集並報警這些度量信息達到監控目的；
- 安全
Consul,Zookeeper 支持ACL，另外 Consul,Etcd 支持安全通道https.
- Spring Cloud的集成
目前都有相對應的 boot starter，提供了集成能力。
總的來看，目前Consul 自身功能，和 spring cloud 對其集成的支持都相對較為完善，而且運維的復雜度較為簡單（沒有詳細列出討論），Eureka 設計上比較符合場景，但還需持續的完善。