注册中心调研

根据目前开源或者比较流行的服务发现中间件进行比较：

特性	Consul	zookeeper	etcd	eureka	redis
健康检查	服务、内存硬盘等状态	长连接	连接心跳	可配支持	连接心跳
多数据中心	支持	-	-	-	-
KV存储	支持	支持	支持	-	支持
一致性	gossip	paxos	raft	-	raft
多语言	http/dns	支持	http/grpc	http(sidecar)	支持
watch	http/dns	支持	http/grpc	http(sidecar)	支持
自身监控	metrics	-	metrics	metrics	-
安全	acl /https	acl	https	—	auth
spring cloud	支持	支持	支持	支持	支持
实现语言	go	java	go	java	c
http/json api	支持	-	支持	-	-

Eureka 使用时需要显式配置健康检查支持；Zookeeper,Etcd, Redis 则在失去了和服务进程的连接情况下任务不健康，而 Consul 相对更为详细点，比如内存是否已使用了90%，文件系统的空间是不是快不足了。

Consul 通过 WAN 的 Gossip 协议，完成跨数据中心的同步；而且其他的产品则需要额外的开发工作来实现。

除了 Eureka ,其他几款都能够对外支持 k-v 的存储服务，所以后面会讲到这几款产品追求高一致性的重要原因。而提供存储服务，也能够较好的转化为动态配置服务。

Zookeeper的跨语言支持较弱，其他几款支持 http11 提供接入的可能。Euraka 一般通过 sidecar的方式提供多语言客户端的接入支持。Etcd 还提供了Grpc的支持。 Consul除了标准的Rest服务api,还提供了DNS的支持。

Zookeeper 支持服务器端推送变化，Eureka 2.0(正在开发中)也计划支持。 Eureka 1,Consul,Etcd则都通过长轮询的方式来实现变化的感知。

除了 Zookeeper ,其他几款都默认支持 metrics，运维者可以搜集并报警这些度量信息达到监控目的。

Consul,Zookeeper 支持ACL，另外 Consul,Etcd 支持安全通道https。

目前都有相对应的 boot starter，提供了集成能力。

结论

Consul天然支持多数据中心，但是在获取services api的时候返回服务的名字和tag, 如果需要具体服务的信息需要再发起一次请求(请求次数太多)，需要数百万Key-value的系统将受到高延迟和内存压力的影响。

Etcd3借鉴了zookeeper的优势，在此基础上提供了:

目前Etcd用于大名鼎鼎的项目K8中。

Eureka提供了一个弱一致的服务机制。当客户端向服务器注册时，该服务器将尝试复制到其他服务器，但不提供保证。服务注册有一个短的生存时间（TTL），要求客户端与服务器心跳。不健康的服务或节点将停止心跳，使他们超时并从注册表中删除。因为Euerka2目前github已经终止开发，目前维护不及时。

zookeeper新版本的bug： ZOOKEEPER-1159、ZOOKEEPER-1576

因为dubbo开源已经实现了zookeeper和redis注册中心，因此剩余Etcd和Consul都是比较优秀开源中间件，考虑到etcd的新特性、使用广泛度和社区活跃度，近期先优先开发支持etcd3的注册中心。未来根据实际情况接入Eureka和Consul。