服务发现比较:Consul vs Zookeeper vs Etcd vs Eureka

平时常常用到的服务发现的产品进行下特性的对比，首先看下结论:

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 设计上比较符合场景，但还需持续的完善。

 

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