zookeeper 和 eureka 作为两种最常用的 注册中心，他们之间有什么不同之处呢？
不同之处很多，这里指讨论一点。
两者的设计原则和对 CAP 的倾向不同
什么是 CAP
Zookeeper 的 CP 原则
对于 zookeeper 来说，它倾向满足 CP 的。也就是说，zookeeper 是保证数据的一致性的，但是这里还需要注意一点是，zookeeper 它默认不是强一致的，什么意思呢？
打个比方，现在客户端 A 提交一个写操作，zookeeper 在过半数节点操作成功之后就可以返回，但此时，客户端 B 的读操作请求的是 A 写操作尚未同步到的节点，那么读取的就不是 A 最新提交的数据了。
那如何保证强一致性呢？我们可以在读取数据的时候先执行一下 sync 操作，即与 leader 节点先同步一下数据，再去取，这样才能保证数据的强一致性。
满足一致性的同时，就很难满足可用性。刚刚提到了 leader 节点，当 master 节点因为网络故障与其他节点失去联系时，剩余节点会重新进行 leader 选举。问题在于，选举 leader 的时间太长，30 ~ 120s, 且选举期间整个 zookeeper 集群都是不可用的，这就导致在选举期间注册服务瘫痪。
Eureka 的 AP 原则
大规模的网络系统，失败是在所难免的，我们无法回避这个问题。当向注册中心查询服务列表时，我们可以容忍注册中心返回的是几分钟以前的注册信息，但不能接受服务直接 down 掉不可用
Eureka 在被设计的时候，就考虑到了这一点，因此在设计时优先保证可用性，这就是 AP 原则。
Eureka 各个节点都是平等的，几个节点挂掉不会影响正常节点的工作，剩余的节点依然可以提供注册和查询服务。 而 Eureka 的客户端在向某个 Eureka 注册或时如果发现连接失败，则会自动切换至其它节点，只要有一台 Eureka 还在，就能保证注册服务可用（即保证A原则），只不过查到的信息可能不是最新的（不保证C原则）。
除此之外, Eureka还有一种自我保护机制,如果在15分钟内超过85%的节点都没有正常的心跳,那么Eureka就认为客户端与注册中心出现了网络故障,此时会出现以下几种情况
-
Eureka不再从注册列表中移除因为长时间没收到心跳而应该过期的服务
-
Eureka仍然能够接受新服务的注册和查询请求,但是不会被同步到其它节点上(即保证当前节点依然可用)
-
当网络稳定时,当前实例新的注册信息会被同步到其它节点中.
Eureka 可以很好的应对因网络故障导致部分节点失去联系的情况，而不会像 zookeeper 那样使整个注册服务瘫痪
看法
作为服务注册中心，最重要的是要保证可用性，可以接受短时间内数据不一致的情况。因此个人觉得 Eureka 作为单纯的服务注册中心会更好一点
虽然 eureka2.x 分支不再维护，但是 eureka1.x 官方还在积极维护，并不是像网上说的 eureka 凉了。
Eureka 是随着 Spring Cloud 被人们熟知，是 Spring Cloud 的默认配置中心，但是 Spring Cloud 也支持使用 zookeeper、consul 等。
