著名的CAP理论指出，一个分布式系统不可能同时满足C(一致性)、A(可用性)和P(分区容错性)。由于分区容错性在是分布式系统中必须要保证的，因此我们只能在A和C之间进行权衡。在此Zookeeper保证的是CP, 而Eureka则是AP。

对于CAP不太熟悉的可以查看下面博客

分布式CAP原则与BASE理论

接下来我们从ZK和Eureka 设计实现上一步步分析

ZK服务注册原理（CP）

zookeeper可以作为注册中心，也可用于服务治理（zookeeper还有其他用途，例如：分布式事务锁等）   

当消费端启动时候会去zookeeper上订阅path(例如:/dubbo/com.test.demo.api/providers)下面的信息，也就是服务提供者列表信息，那么我们就可以基于这个原理来获取某一个服务提供者列表，然后对信息进行过滤加工，并且注册一个监听器，当服务提供者机器增减后，动态更新保存的地址列表。

1.每启动一个微服务，就会去zk中注册一个临时子节点(ZK集群完成一致性确认,保存数据)

2.服务订阅,拉取服务列表,并注册一个监听(zk的watch机制,不熟悉的可以简单去百度了解下)

3.每当有一个服务down机或者新的微服务注册进来，由于是临时接点，此节点会立即被删除或者添加一个，并通知订阅该服务（2中注册了监听的服务）的微服务更新服务列表（zk的watch机制，每当有节点更新，都会通知订阅该服务的微服务更新服务列表）

注：服务提供者全部宕掉后，服务消费者应用将无法使用，并无限次重连等待服务提供者恢复

ZK为什么是CP？

当向注册中心查询服务列表时，我们可以容忍注册中心返回的是几分钟以前的注册信息，但不能接受服务直接down掉不可用。也就是说，服务注册功能对可用性的要求要高于一致性(但是也会存在一点点延迟,毕竟需要网络传输和数据拉取处理,一般可能就几十毫秒,很短的时间)。但是zk会出现这样一种情况，当master节点因为网络故障与其他节点失去联系时，剩余节点会重新进行leader选举。问题在于，选举leader的时间太长，30 ~ 120s, 且选举期间整个zk集群都是不可用的，这就导致在选举期间注册服务瘫痪。在云部署的环境下，因网络问题使得zk集群失去master节点是较大概率会发生的事，虽然服务能够最终恢复，但是漫长的选举时间导致的注册长期不可用是不能容忍的(这也就是ZK的缺点之一,牺牲部分的可用性)。

Eureka服务注册原理(AP)

Eureka看明白了这一点，因此在设计时就优先保证可用性。Eureka各个节点都是平等的，几个节点挂掉不会影响正常节点的工作，剩余的节点依然可以提供注册和查询服务。而Eureka的客户端在向某个Eureka注册或时如果发现连接失败，则会自动切换至其它节点，就算全部挂掉，服务还能通过读取本地缓存的服务列表信息来进行调用,就能保证注册服务可用(保证可用性)，只不过查到的信息可能不是最新的(不保证强一致性)(注：前提是服务提供者的ip:port信息没有发生变化)。

除此之外，Eureka还有一种自我保护机制，如果在15分钟内超过85%的节点都没有正常的心跳，那么Eureka就认为客户端与注册中心出现了网络故障，此时会出现以下几种情况： 
1. Eureka不再从注册列表中移除因为长时间没收到心跳而应该过期的服务 
2. Eureka仍然能够接受新服务的注册和查询请求，但是不会被同步到其它节点上(即保证当前节点依然可用) 
3. 当网络稳定时，当前实例新的注册信息会被同步到其它节点中

因此， Eureka可以很好的应对因网络故障导致部分节点失去联系的情况，而不会像zookeeper那样使整个注册服务瘫痪。

1.服务B进行服务注册,并定时发送心跳(根据配置的规则 进行不达标节点下线)

2.Eureka接收注册信息后, 一是本地注册信息更新（同步）；二是将消息广播给其它服务器（异步）。

由此也可以看出 Eureka 是 AP 模型的，优先保障了可用性，事实上大多数注册中心的实现方案都是 AP 模型，只有 ZK 是 CP 模型。事实上，ZK 是分布式协调服务，并不是专门用来进行服务治理的。

3.服务A定时拉取最新的服务信息并缓存在本地

基于eureka的实现原理,可以看出它优先保证了可用性,牺牲了数据一致性,但并不是说集群中的数据是不一致的,集群中每个节点的数据同步延迟时间比较长而已,如果使用Eureka默认的配置信息,数据服务A要获取到最新的服务列表信息 延迟可能是几十秒甚至几分钟,因此,线上生产环境往往会对Eureka 进行调优,使发送心跳,拉取服务,定时检查等定时服务间隔时间调短,来达到服务信息延迟降低的目的。 

总结:

基于CAP理论来说,很多人说  Eureka作为单纯的服务注册中心来说要比zookeeper更加“专业”，因为注册服务更重要的是可用性，我们可以接受短期内达不到一致性的状况。但其实呢,个人认为技术不分优劣,更多的在于适不适合你的项目技术架构,你的服务是需要保证AP还是需要保证CP,能否容忍技术带来的不便之处,综合比较,选取最合适的技术才是最关键的。