Eureka与Zk有什么区别？

Zookeeper为CP设计强调一性，而Eureka为AP设计强调可用性

传统的数据库遵循acid原则（atomicity原子性、consistency一致性、isolation隔离性、durability持久性）
nosql数据库遵循cap原则（consistency一致性、availability可用性、artition tolerance分区容错性）

任何一个分布式系统没有办法同时满足cap,只能3个里面选2个

需求
当向注册中心查询服务列表时，我们可以容忍注册中心返回的是几分钟以前的注册信息，但是不能接受服务直接down不可用，就是说服务注册功能对可用性的要求高于一致性，这个时候时候用Eureka

zookeeper
zk会出现这样一种情况，当master节点因为网络故障与其他节点失去联系时，剩余节点会重新进行leader选举，问题在于，选择leader的时间太长，30-120s,且选举期间整个zk集群都是不可用的，者就导致在选举期间注册服务瘫痪，在云部署的环境下，因为网络问题使得zk集群失去master节点是较大概率会发生的事情，虽然服务能够最终恢复，但是漫长的选举时间导致的注册长期不可用是否能够忍受呢？

Eureka
Eureka各个节点都是平等的，几个节点挂掉不会影响正常节点的工作，剩余的节点依然可以提供注册和查询服务，Eureka的客户端在向某个Eureka服务端注册时如果发现链接失败，则自动切换到其他节点，只要有一台Eureka活着，就能保证服务可用，只不过查询到的信息可能不是最新的（不保证一致性）

Eureka因网络故障导致部分节点失去联系的情况下：依然提供服务，但不保证数据是最新的
zookeeper因网络故障导致部分节点失去联系的情况下：暂停对外提供服务，保证数据是最新的
Eureka架构设计图
采用了C-S的设计架构，Eureka Server作为服务注册功能的服务器，它是服务的注册中心

zookeeper架构设计图

节点角色说明：
 Provider: 暴露服务的服务提供方。
 Consumer: 调用远程服务的服务消费方。
 Registry: 服务注册与发现的注册中心。
 Monitor: 统计服务的调用次调和调用时间的监控中心。
 Container: 服务运行容器。
调用关系说明：
 0. 服务容器负责启动，加载，运行服务提供者。
 1. 服务提供者在启动时，向注册中心注册自己提供的服务。
 2. 服务消费者在启动时，向注册中心订阅自己所需的服务。
 3. 注册中心返回服务提供者地址列表给消费者，如果有变更，注册中心将基于长连接推
送变更数据给消费者。
 4. 服务消费者，从提供者地址列表中，基于软负载均衡算法，选一台提供者进行调用，
如果调用失败，再选另一台调用。
 5. 服务消费者和提供者，在内存中累计调用次数和调用时间，定时每分钟发送一次统计
数据到监控中心。

	Zookeeper	Eureka
设计原则	CP	AP
优点	数据强一致	服务高可用
缺点	网络分区会影响Leader选举，超过阈值后集群不可用	服务节点间的数据可能不一致； Client-Server间的数据可能不一致；
适用场景	单机房集群，对数据一致性要求较高	云机房集群，跨越多机房部署；对注册中心服务可用性要求较高