Consul vs Zookeeper vs Etcd vs Eureka

Feature Consul zookeeper etcd euerka
服务健康检查 服务状态，内存，硬盘等 (弱)长连接，keepalive 连接心跳 可配支持
多数据中心 支持 — — —
kv存储服务 支持 支持 支持 —
一致性 raft paxos raft —
cap cp 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集成 已支持 已支持 已支持 已支持
Eureka是一个服务发现工具。该体系结构主要是客户端/服务器，每个数据中心有一组Eureka服务器，通常每个可用区域一个。通常Eureka的客户使用嵌入式SDK来注册和发现服务。对于非本地集成的客户，使用功能区边框等透过Eureka透明地发现服务。

Eureka提供了一个弱一致的服务视图，使用尽力而为复制。当客户端向服务器注册时，该服务器将尝试复制到其他服务器，但不提供保证。服务注册的生存时间（TTL）较短，要求客户端对服务器心存感激。不健康的服务或节点将停止心跳，导致它们超时并从注册表中删除。发现请求可以路由到任何服务，由于尽力而为的复制，这些服务可能会导致陈旧或丢失数据。这个简化的模型允许简单的群集管理和高可扩展性。

CONSUL提供了一套超级功能，包括更丰富的健康检查，关键/价值存储以及多数据中心意识。Consul需要每个数据中心都有一套服务器，以及每个客户端的代理，类似于使用像Ribbon这样的负载均衡。Consul代理允许大多数应用程序成为Consul不知情者，通过配置文件执行服务注册并通过DNS或负载平衡器sidecars发现。

Consul提供强大的一致性保证，因为服务器使用Raft协议复制状态 。Consul支持丰富的健康检查，包括TCP，HTTP，Nagios / Sensu兼容脚本或基于Eureka的TTL。客户端节点参与基于Gossip的健康检查，该检查分发健康检查工作，而不像集中式心跳检测那样成为可扩展性挑战。发现请求被路由到选举出来的领事领导，这使他们默认情况下强烈一致。允许陈旧读取的客户端使任何服务器都可以处理他们的请求，从而实现像Eureka这样的线性可伸缩性。

Consul强烈的一致性意味着它可以作为领导选举和集群协调的锁定服务。Eureka不提供类似的保证，并且通常需要为需要执行协调或具有更强一致性需求的服务运行ZooKeeper。

Consul提供了支持面向服务的体系结构所需的一系列功能。这包括服务发现，还包括丰富的运行状况检查，锁定，密钥/值，多数据中心联合，事件系统和ACL。Consul和consul-template和envconsul等工具生态系统都试图尽量减少集成所需的应用程序更改，以避免需要通过SDK进行本地集成。Eureka是一个更大的Netflix OSS套件的一部分，该套件预计应用程序相对均匀且紧密集成。因此，Eureka只解决了一小部分问题，希望ZooKeeper等其他工具可以一起使用。

在CAP中，Consul使用CP体系结构，有利于实现可用性的一致性。

最大的区别是Eureka保证AP, Consul为CP。

Consul强一致性(C)带来的是：

服务注册相比Eureka会稍慢一些。因为Consul的raft协议要求必须过半数的节点都写入成功才认为注册成功
Leader挂掉时，重新选举期间整个consul不可用。保证了强一致性但牺牲了可用性。
Eureka保证高可用(A)和最终一致性：

服务注册相对要快，因为不需要等注册信息replicate到其他节点，也不保证注册信息是否replicate成功
当数据出现不一致时，虽然A, B上的注册信息不完全相同，但每个Eureka节点依然能够正常对外提供服务，这会出现查询服务信息时如果请求A查不到，但请求B就能查到。如此保证了可用性但牺牲了一致性。
其他方面，eureka就是个servlet程序，跑在servlet容器中; Consul则是go编写而成。

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

Euraka 使用时需要显式配置健康检查支持；Zookeeper,Etcd 则在失去了和服务进程的连接情况下任务不健康，而 Consul 相对更为详细点，比如内存是否已使用了90%，文件系统的空间是不是快不足了。服务的健康检查
多数据中心支持
　　　　Consul 通过 WAN 的 Gossip 协议，完成跨数据中心的同步；而且其他的产品则需要额外的开发工作来实现；

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

产品设计中 CAP 理论的取舍
　　　　Eureka 典型的 AP,作为分布式场景下的服务发现的产品较为合适，服务发现场景的可用性优先级较高，一致性并不是特别致命。其次 CP 类型的场景 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 设计上比较符合场景，但还需持续的完善。