常用的服務發現對比（Consul、zookeeper、etcd、eureka）

這裡就平時經常用到的服務發現的産品進行下特性的對比，首先看下結論:

Feature	Consul	Zookeeper	Etcd	Eureka
服務健康檢查	服務狀态，記憶體，硬碟等	(弱)長連接配接，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 設計上比較符合場景，但還需持續的完善。