這裡就平時經常用到的服務發現的產品進行下特性的對比，首先看下結論:
|
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 設計上比較符合場景，但還需持續的完善。