zookeeper基於paxos的化簡版zab，etcd基於raft算法、consul也是基於raft算法。etcd和consul作為后起之秀，並沒有因為已經有了zookeeper而放棄自己，而是采用更為直接的raft算法。
這里就平時經常用到的服務發現的產品進行下特性的對比，首先看下結論:
Feature Consul zookeeper etcd euerka 服務健康檢查 服務狀態，內存，硬盤等 (弱)長連接，keepalive 連接心跳 可配支持 多數據中心 支持 — — — kv存儲服務 支持 支持 支持 — 一致性 raft paxos raft — cap ca 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集成 已支持 已支持 已支持 已支持
- 服務的健康檢查
Euraka 使用時需要顯式配置健康檢查支持；Zookeeper,Etcd 則在失去了和服務進程的連接情況下任務不健康，而 Consul 相對更為詳細點，比如內存是否已使用了90%，文件系統的空間是不是快不足了。
- 多數據中心支持
Consul 通過 WAN 的 Gossip 協議，完成跨數據中心的同步；而且其他的產品則需要額外的開發工作來實現；
- KV 存儲服務
除了 Eureka ,其他幾款都能夠對外支持 k-v 的存儲服務，所以后面會講到這幾款產品追求高一致性的重要原因。而提供存儲服務，也能夠較好的轉化為動態配置服務哦。
- 產品設計中 CAP 理論的取舍
Eureka 典型的 AP,作為分布式場景下的服務發現的產品較為合適，服務發現場景的可用性優先級較高，一致性並不是特別致命。其次 CA 類型的場景 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 設計上比較符合場景，但還需持續的完善。
Etcd 和 Zookeeper 提供的能力非常相似，在軟件生態中所處的位置也幾乎是一樣的，可以互相替代的。
都是通用的一致性元信息存儲，
都提供watch機制用於變更通知和分發，
也都被分布式系統用來作為共享信息存儲，
二者除了實現細節，語言，一致性協議上的區別，最大的區別在周邊生態圈。
Zookeeper 是apache下的，用java寫的，提供rpc接口，最早從hadoop項目中孵化出來，在分布式系統中得到廣泛使用(hadoop, solr, kafka, mesos 等)。
Etcd 是coreos公司旗下的開源產品，比較新，以其簡單好用的rest接口以及活躍的社區俘獲了一批用戶，在新的一些集群中得到使用(比如kubernetes)。
雖然v3為了性能也改成二進制rpc接口了，但其易用性上比 Zookeeper 還是好一些。
而 Consul 的目標則更為具體一些，Etcd 和 Zookeeper 提供的是分布式一致性存儲能力，具體的業務場景需要用戶自己實現，比如服務發現，比如配置變更。
而Consul 則以服務發現和配置變更為主要目標，同時附帶了kv存儲。
在軟件生態中，越抽象的組件適用范圍越廣，但同時對具體業務場景需求的滿足上肯定有不足之處。