| 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集成 | 已支持 | 已支持 | 已支持 | 已支持 |
ZooKeeper：
zookeeper保证了cp(一致性、分区容错性)，但是作为服务注册中心，我们可以容忍注册中心返回的是几分钟以前的注册信息。但是服务中心却必须保证可用性，
即服务注册中心对于高可用性的需求高于一致性。对于可用性，zookeeper有一个leader选举方案。当master主节点宕机与其他节点失去联系时，其他节点会重
新进行Leader选举，选出新的master节点。然而选举耗时过长，一般为30~120S，并且整个选举期间，整个zookeeper集群是无法使用的。
Eureka：
eureka保证了ap(可用性、分区容错性)，eureka每一个节点都是平等的，几个节点宕机不会影响正常节点的工作。剩余的正常节点依旧可以提供服务注册和查询。
并且，当客户端向某节点注册服务时，注册失败或者超时，则会自动切换到其他节点。只要有一台eureka节点还正常工作，就能保证注册服务的可用。但是对于服
务信息的同步则不能保证一致性(不能保证强一致性，但是最终一致)。除此之外，Eureka还有一种自我保护机制，如果在15分钟内85%的节点都没有正常心跳(不可用)
那么Eureka就认为客户端与注册中心之间出现了网络故障，此时会出现以下几种情况：
1、Eureka不再从注册列表中移除因为长时间没收到心跳而应该过期的服务
2、Eureka仍然能够接收新服务的注册和查询请求，但是不会被同步到其他节点上(保证当前节点的可用性)
3、当网络稳定后，当前实例新注册的服务会被同步到其他节点
因此,Eureka能够保证注册中心的高可用性，而不会像zookeeper一样直接集群瘫痪