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

FeatureConsulzookeeperetcdeuerka

服務健康檢查	服務狀態，內存，硬盤等	(弱)長連接，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 設計上比較符合場景，但還需持續的完善。

?

原文地址：https://luyiisme.github.io/2017/04/22/spring-cloud-service-discovery-products/?utm_source=tuicool&utm_medium=referral

轉載于:https://www.cnblogs.com/stimlee/p/9231196.html

創作挑戰賽新人創作獎勵來咯，堅持創作打卡瓜分現金大獎

總結

以上是生活随笔為你收集整理的服务发现比较:Consul vs Zookeeper vs Etcd vs Eureka的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。