首先在比较两者之前我们先了解两者是什么，用来做什么最后在比较两者的区别吧！
从上图中可以看出，在SpringCloud中，Eureka的定位是服务治理。
同样在ZooKeeper官方文档中介绍也为服务治理，那么接下来先了解什么是服务治理（服务发现组件）。
服务发现简介
在微服务以及分布式的架构中，存在着寻多单体服务，然后各个服务之间通过网络通讯实现互调，一般使用服务提供者、服务消费者来描述微服务之间的调用关系 。
随着服务的逐渐增加，有可能一个消费者要调用多个提供者，所以出现了服务治理中心比如Dubbo使用ZooKeeper来做服务注册管理中心，SpringCloud使用Eureka来做服务治理中心。
以上两图是SpringCloud的服务注册发现调用以及Dubbo的服务注册发现及调用。
Eureka
Eureka 是 Netflix 出品的用于实现服务注册和发现的工具。Spring Cloud 集成了 Eureka，并提供了开箱即用的支持。Eureka的架构如下图：
Application Service 相当于服务提供者
Application Client 相当于服务消费者
Make Remote Call 以Restful API方式调用的行为
us-east-1c、us-east-1d 等都是zone，它们都属于us-east-1这个region
由上图可以看出，Eureka包括两个组件：Eureka Server 和 Eureka Client，它们的作用如下：
Eureka Server 提供服务发现能力，各个微服务启动时，会向Eureka Server
注册自己的信息（例如IP、端口、微服务名称等），Eureka Server会存储这些信息。
Erueka Client是一个java客户端，用于简化与Eureka的交互。
微服务启动后，会周期性（默认30s）地向Eureka Server发送心跳以续约自己的“ 租期 ”。
如果Eureka server在一定的时间内没有接收到某个微服务实例的心跳，Eureka Server将注销该实例（默认90s）。
默认情况下，Eureka Server同时也是Eureka Client。多个Eureka Server 实例互相之间通过复制的方式来实现服务注册表中数据的同步。
Eureka Client 会缓存服务注册表中的信息，这种方式有一定的优势——首先，无须每次请求都查询Eureka Server，从而降低了Eureka Server的压力；其次，即使Eureka Server所有节点都宕掉，服务消费者依然可以使用缓存中的信息找到服务提供者并完成调用。综上，Eureka通过心跳检查、客户端缓存等机制，提高了系统的灵活性、可伸缩性和可用性。
Eureka Server作为一个独立的部署单元，以REST API的形式为服务实例提供了注册、管理和查询等操作。同时，Eureka Server也为我们提供了可视化的监控页面，可以直观地看到各个Eureka Server当前的运行状态和所有已注册服务的情况。
Zookeeper:
ZooKeeper是用于分布式应用程序的分布式，开放源代码协调服务。它公开了一组简单的原语，分布式应用程序可以基于这些原语来实现用于同步，配置维护以及组和命名的更高级别的服务。它的设计易于编程，并使用了按照文件系统熟悉的目录树结构样式设置的数据模型。它以Java运行，并且具有Java和C的绑定。
众所周知，协调服务很难做到。它们特别容易出现诸如比赛条件和死锁之类的错误。ZooKeeper背后的动机是减轻分布式应用程序从头开始实施协调服务的责任。
设计目标：
ZooKeeper很简单。ZooKeeper允许分布式进程通过共享的分层名称空间相互协调，该命名空间的组织方式类似于标准文件系统。名称空间由数据寄存器（在ZooKeeper中称为znodes）组成，它们类似于文件和目录。与设计用于存储的典型文件系统不同，ZooKeeper数据保留在内存中，这意味着ZooKeeper可以实现高吞吐量和低延迟数。
ZooKeeper实施对高性能，高可用性，严格有序访问加以重视。ZooKeeper的性能方面意味着它可以在大型的分布式系统中使用。可靠性方面使它不会成为单点故障。严格排序意味着可以在客户端上实现复杂的同步原语。
ZooKeeper已复制。像它协调的分布式进程一样，ZooKeeper本身也可以在称为集合的一组主机上进行复制。
组成ZooKeeper服务的服务器都必须彼此了解。它们维护内存中的状态图像，以及持久存储中的事务日志和快照。只要大多数服务器可用，ZooKeeper服务将可用。
客户端连接到单个ZooKeeper服务器。客户端维护一个TCP连接，通过它发送请求，获取响应，获取监视事件并发送心跳。如果与服务器的TCP连接断开，则客户端将连接到其他服务器。
ZooKeeper已订购。ZooKeeper用一个反映所有ZooKeeper事务顺序的数字标记每个更新。后续操作可以使用该命令来实现更高级别的抽象，例如同步原语。
ZooKeeper很快。在“读取为主”的工作负载中，它特别快。ZooKeeper应用程序可在数千台计算机上运行，并且在读取比写入更为常见的情况下，其性能最佳，比率约为10：1。
数据模型和分层名称空间
ZooKeeper提供的名称空间与标准文件系统的名称空间非常相似。名称是由斜杠（/）分隔的一系列路径元素。ZooKeeper名称空间中的每个节点都由路径标识。
ZooKeeper的层次命名空间
节点和短暂节点:
与标准文件系统不同，ZooKeeper命名空间中的每个节点都可以具有与其关联的数据以及子节点。就像拥有一个文件系统一样，该文件系统也允许文件成为目录。（ZooKeeper旨在存储协调数据：状态信息，配置，位置信息等，因此每个节点上存储的数据通常很小，在字节到千字节范围内。）我们使用术语znode来明确表示在谈论ZooKeeper数据节点。
Znodes维护一个统计数据结构，其中包括用于数据更改，ACL更改和时间戳的版本号，以允许进行缓存验证和协调更新。znode的数据每次更改时，版本号都会增加。例如，每当客户端检索数据时，它也接收数据的版本。
原子地读取和写入存储在名称空间中每个znode上的数据。读取将获取与znode关联的所有数据字节，而写入将替换所有数据。每个节点都有一个访问控制列表（ACL），用于限制谁可以执行操作。
ZooKeeper还具有短暂节点的概念。只要创建znode的会话处于活动状态，这些znode就会存在。会话结束时，将删除znode。当您想实现[tbd]时，临时节点非常有用。
有条件的更新和监视
ZooKeeper支持手表的概念。客户端可以在znode上设置手表。znode更改时，将触发并删除监视。触发监视后，客户端会收到一个数据包，说明znode已更改。如果客户端与其中一个ZooKeeper服务器之间的连接断开，则客户端将收到本地通知。这些可以用于[tbd]。
保证金
ZooKeeper非常快速且非常简单。但是，由于其目标是作为构建更复杂的服务（例如同步）的基础，因此它提供了一组保证。这些是：
顺序一致性-来自客户端的更新将按照其发送顺序进行应用。
原子性-更新成功或失败。没有部分结果。
单个系统映像-无论客户端连接到哪个服务器，客户端都将看到相同的服务视图。
可靠性-应用更新后，此更新将一直持续到客户端覆盖更新为止。
及时性-确保系统的客户视图在特定时间范围内是最新的。
简单的API
ZooKeeper的设计目标之一是提供一个非常简单的编程界面。因此，它仅支持以下操作：
create：在树中的某个位置创建一个节点
delete：删除节点
存在：测试某个位置是否存在节点
获取数据：从节点读取数据
设置数据：将数据写入节点
获取子节点：获取节点子节点的列表
sync：等待数据传播
实作
ZooKeeper组件显示ZooKeeper服务的高级组件。除请求处理器外，构成ZooKeeper服务的每个服务器都复制其自己的每个组件副本。
复制的数据库是包含整个数据树的内存数据库。将更新记录到磁盘以确保可恢复性，并且将写入操作序列化到磁盘之后再将其应用于内存数据库。
每个ZooKeeper服务器都为客户端提供服务。客户端仅连接到一台服务器即可提交请求。读取请求从每个服务器数据库的本地副本提供服务。更改服务状态的请求（写请求）由协议协议处理。
作为协议协议的一部分，来自客户端的所有写请求都被转发到称为领导者的单个服务器。其余的ZooKeeper服务器（称为跟随者）从领导者接收消息建议并同意消息传递。消息传递层负责替换出现故障的领导者，并将跟随者与领导者同步。
ZooKeeper使用自定义的原子消息传递协议。由于消息传递层是原子层，因此ZooKeeper可以确保本地副本永远不会发散。当领导者收到写请求时，它将计算要应用写操作时系统的状态，并将其转换为捕获该新状态的事务.
CAP 与 Base：
CAP原则又称CAP定理，指的是在一个分布式系统中， Consistency（一致性）、 Availability（可用性）、Partition tolerance（分区容错性），三者不可得兼。
CAP原则是NOSQL数据库的基石。
分布式系统的CAP理论：理论首先把分布式系统中的三个特性进行了如下归纳：
一致性（C）：在分布式系统中的所有数据备份，在同一时刻是否同样的值。（等同于所有节点访问同一份最新的数据副本）
可用性（A）：在集群中一部分节点故障后，集群整体是否还能响应客户端的读写请求。（对数据更新具备高可用性）
分区容忍性（P）：以实际效果而言，分区相当于对通信的时限要求。系统如果不能在时限内达成数据一致性，就意味着发生了分区的情况，必须就当前操作在C和A之间做出选择
BASE理论
BASE是Basically Available（基本可用）、Soft state（软状态）和Eventually consistent（最终一致性）三个短语的简写，BASE是对CAP中一致性和可用性权衡的结果，其来源于对大规模互联网系统分布式实践的结论，是基于CAP定理逐步演化而来的，其核心思想是即使无法做到强一致性（Strong consistency），但每个应用都可以根据自身的业务特点，采用适当的方式来使系统达到最终一致性（Eventual consistency）。
具体区别差异及选用，点击查看此文章即可。CAP原则(CAP定理)、BASE理论
区别：
著名的CAP理论指出，一个分布式系统不可能同时满足C(一致性)、A(可用性)和P(分区容错性)。由于分区容错性在是分布式系统中必须要保证的，因此我们只能在A和C之间进行权衡。在此Zookeeper保证的是CP, 而Eureka则是AP。
Zookeeper保证CP
当向注册中心查询服务列表时，我们可以容忍注册中心返回的是几分钟以前的注册信息，但不能接受服务直接down掉不可用。也就是说，服务注册功能对可用性的要求要高于一致性。但是zk会出现这样一种情况，当master节点因为网络故障与其他节点失去联系时，剩余节点会重新进行leader选举。问题在于，选举leader的时间太长，30 ~ 120s, 且选举期间整个zk集群都是不可用的，这就导致在选举期间注册服务瘫痪。在云部署的环境下，因网络问题使得zk集群失去master节点是较大概率会发生的事，虽然服务能够最终恢复，但是漫长的选举时间导致的注册长期不可用是不能容忍的。
Eureka保证AP
Eureka看明白了这一点，因此在设计时就优先保证可用性。Eureka各个节点都是平等的，几个节点挂掉不会影响正常节点的工作，剩余的节点依然可以提供注册和查询服务。而Eureka的客户端在向某个Eureka注册或时如果发现连接失败，则会自动切换至其它节点，只要有一台Eureka还在，就能保证注册服务可用(保证可用性)，只不过查到的信息可能不是最新的(不保证强一致性)。除此之外，Eureka还有一种自我保护机制，如果在15分钟内超过85%的节点都没有正常的心跳，那么Eureka就认为客户端与注册中心出现了网络故障，此时会出现以下几种情况：
Eureka不再从注册列表中移除因为长时间没收到心跳而应该过期的服务
Eureka仍然能够接受新服务的注册和查询请求，但是不会被同步到其它节点上(即保证当前节点依然可用)
当网络稳定时，当前实例新的注册信息会被同步到其它节点中
因此， Eureka可以很好的应对因网络故障导致部分节点失去联系的情况，而不会像zookeeper那样使整个注册服务瘫痪。
本文分享自微信公众号 - 互联网后端架构（fullstack888）。
如有侵权，请联系 support@oschina.cn 删除。
本文参与“OSC源创计划”，欢迎正在阅读的你也加入，一起分享。
