最大的區別是Eureka保證AP, Consul為CP。

Consul強一致性(C)帶來的是：

   1 服務註冊相比Eureka會稍慢一些。因為Consul的raft協議要求必須過半數的節點都寫入成功才認為註冊成功
   2 Leader掛掉時，重新選舉期間整個consul不可用。保證了強一致性但犧牲了可用性。

Eureka保證高可用(A)和最終一致性：

   1 服務註冊相對要快，因為不需要等註冊資訊replicate到其他節點，也不保證註冊資訊是否replicate成功
   2 當資料出現不一致時，雖然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,作為分散式場景下的服務發現的產品較為合適，服務發現場景的可用性優先順序較高，一致性並不是特別緻命。其次 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 設計上比較符合場景，但還需持續的完善。