| 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等其他工具可以一起使用。
在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 設計上比較符合場景，但還需持續的完善。
服務注冊發現一: consul介紹、安裝、及功能介紹
服務注冊發現二: 在Spring Cloud中使用Consul實現服務的注冊和發現
服務發現比較:Consul vs Zookeeper vs Etcd vs Eureka
服務注冊發現四: 基于Consul的KV存儲和分布式信號量實現分布式鎖
