一、整体对比
二、Eureka
云端服务发现，一个基于 REST 的服务，用于定位服务，以实现云端中间层服务发现和故障转移。
Eureka是一个服务发现工具。该体系结构主要是客户端/服务器，每个数据中心有一组Eureka服务器，通常每个可用区域一个。通常Eureka的客户使用嵌入式SDK来注册和发现服务。对于非本地集成的客户，使用功能区边框等透过Eureka透明地发现服务。
Eureka提供了一个弱一致的服务视图，使用尽力而为复制。当客户端向服务器注册时，该服务器将尝试复制到其他服务器，但不提供保证。服务注册的生存时间（TTL）较短，要求客户端对服务器心存感激。不健康的服务或节点将停止心跳，导致它们超时并从注册表中删除。发现请求可以路由到任何服务，由于尽力而为的复制，这些服务可能会导致陈旧或丢失数据。这个简化的模型允许简单的群集管理和高可扩展性。
三、Consul
Consul提供了一套超级功能，包括更丰富的健康检查，关键/价值存储以及多数据中心意识。Consul需要每个数据中心都有一套服务器，以及每个客户端的代理，类似于使用像Ribbon这样的负载均衡。Consul代理允许大多数应用程序成为Consul不知情者，通过配置文件执行服务注册并通过DNS或负载平衡器sidecars发现。
Consul提供强大的一致性保证，因为服务器使用Raft协议复制状态 。Consul支持丰富的健康检查，包括TCP，HTTP，Nagios / Sensu兼容脚本或基于Eureka的TTL。客户端节点参与基于Gossip的健康检查，该检查分发健康检查工作，而不像集中式心跳检测那样成为可扩展性挑战。发现请求被路由到选举出来的领事领导，这使他们默认情况下强烈一致。允许陈旧读取的客户端使任何服务器都可以处理他们的请求，从而实现像Eureka这样的线性可伸缩性。
Consul强烈的一致性意味着它可以作为领导选举和集群协调的锁定服务。Eureka不提供类似的保证，并且通常需要为需要执行协调或具有更强一致性需求的服务运行。
四、Zookeeper
与 Eureka 有所不同，Apache Zookeeper 在设计时就紧遵CP原则，即任何时候对 Zookeeper 的访问请求能得到一致的数据结果，同时系统对网络分割具备容错性，但是 Zookeeper 不能保证每次服务请求都是可达的。从 Zookeeper 的实际应用情况来看，在使用 Zookeeper 获取服务列表时，如果此时的 Zookeeper 集群中的 Leader 宕机了，该集群就要进行 Leader 的选举，又或者 Zookeeper 集群中半数以上服务器节点不可用（例如有三个节点，如果节点一检测到节点三挂了 ，节点二也检测到节点三挂了，那这个节点才算是真的挂了），那么将无法处理该请求。所以说，Zookeeper 不能保证服务可用性。
当然，在大多数分布式环境中，尤其是涉及到数据存储的场景，数据一致性应该是首先被保证的，这也是 Zookeeper 设计紧遵CP原则的另一个原因。但是对于服务发现来说，情况就不太一样了，针对同一个服务，即使注册中心的不同节点保存的服务提供者信息不尽相同，也并不会造成灾难性的后果。因为对于服务消费者来说，能消费才是最重要的，消费者虽然拿到可能不正确的服务实例信息后尝试消费一下，也要胜过因为无法获取实例信息而不去消费，导致系统异常要好。
当master节点因为网络故障与其他节点失去联系时，剩余节点会重新进行leader选举。问题在于，选举leader的时间太长，30~120s，而且选举期间整个zk集群都是不可用的，这就导致在选举期间注册服务瘫痪。在云部署环境下， 因为网络问题使得zk集群失去master节点是大概率事件，虽然服务能最终恢复，但是漫长的选举事件导致注册长期不可用是不能容忍的。
五、Etcd
A highly-available key value store for shared configuration and service discovery.
用于配置共享和服务发现的键值存储系统，其四个核心特点：
简单：基于HTTP+JSON的API让你用curl命令就可以轻松使用。
安全：可选SSL客户认证机制。
快速：每个实例每秒支持一千次写操作。
可信：使用Raft算法充分实现了分布式。
六、它们之前间的区别
Consul强一致性(C)带来的是：
1、服务注册相比Eureka会稍慢一些。因为Consul的raft协议要求必须过半数的节点都写入成功才认为注册成功
2、Leader挂掉时，重新选举期间整个consul不可用。保证了强一致性但牺牲了可用性。
Eureka保证高可用(A)和最终一致性：
1、服务注册相对要快，因为不需要等注册信息replicate到其他节点，也不保证注册信息是否replicate成功
2、当数据出现不一致时，虽然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(Discontinued)也计划支持。 Eureka 1,Consul,Etcd则都通过长轮询的方式来实现变化的感知；
♚自身集群的监控
除了Zookeeper,其他几款都默认支持 metrics，运维者可以搜集并报警这些度量信息达到监控目的；
♚安全
Consul、Zookeeper支持ACL，另外 Consul,Etcd 支持安全通道https。
♚Spring Cloud的集成
目前都有相对应的 boot starter，提供了集成能力。
总的来看，目前Consul 自身功能，和 spring cloud 对其集成的支持都相对较为完善，而且运维的复杂度较为简单（没有详细列出讨论），Eureka 设计上比较符合场景，但还需持续的完善。
声明：原创，欢迎转载~！ 记得点个关注我哦~！