Eureka 与 zookeeper 的区别、

前言
在微服务的开发过程中，如果使用的是 Dubbo 那就必须使用到 Zookeeper ，在使用 Spring Cloud Eureka 时，自然其功能更强大得多。博主也不得不感叹，Spring Cloud Eureka 后来者居上呀，Dubbo 早在几年前停止了维护，在其停止了维护的几年里正是互联网发展的大好时期，Eureka 借机快速发展，夺得了一大片市场，可以说已经超越了 Dubbo 了，17年的时候，阿里巴巴又突然宣布重启对 Dubbo 的维护，在其重启的发布会上，其主导维护者也表示，将希望加入 Eureka 的生态，呃。。。好吧。

废话过多，进入正题。为什么要用 Eureka 与 Zookeeper 进行比较呢，因为两者都有类似的起到服务注册中心的作用，请往下看。

关于 Eureka
1、什么是 Eureka ？

Eureka 是 Netflix 的一个子模块，也是核心模块之一。Eureka 是一个基于 REST（REpresentational State Transfer） 的服务，用于定位服务，以实现云端中间层服务器的负载均衡和故障转移。Eureka还附带了一个基于java的客户端组件——Eureka Client，它使得与服务的交互更加容易。Eureka Client 还有一个内置的负载均衡器，可以进行基本的循环负载均衡，在 Netflix，一个更加复杂的负载均衡器封装了 Eureka，可以根据流量、资源的使用情况、错误条件等因素根据自定义的权重来实现负载均衡，从而提供更好的弹性服务。

对于服务注册与发现对于微服务架构来说是非常重要的，有了服务发现与注册，只需要使用服务的标识符，就可以访问到服务，而不需要修改服务调用的配置文件了。

2、Eureka 基本架构原理

Eureka 采用了 C-S 的设计架构。Eureka Server 作为服务注册功能的服务器，它是服务注册中心。而系统中的其他微服务，则使用 Eureka Client 连接到 Eureka Server 并维持心跳连接。这样系统的维护人员就可以通过 Eureka Server 来监控系统中各个微服务是否正常运行。Spring Cloud 的一些其他子模块（例如 Gateway）就可以通过 Eureka Server 来发现系统中的其他微服务，并执行相关的业务逻辑。一个 Eureka 的高可用架构图如下（后面会专门的一篇文章来描述如何实现高可用）：

上面图描述了 Eureka 是如何部署在 Netflix 上的，这是 Eureka 典型的使用案例。每个区域都有一个 Eureka 集群，而这个 Eureka 集群只知道该区域中的实例。每个区域至少有一个 Eureka 服务器来处理该区域故障（故障转移）。

关于 Eureka 的更多内容，请查看《 Eureka 基本原理及其架构概述 》

Eureka 源码地址：GitHub For The Eureka

关于 Zookeeper
1、为什么要使用 Zookeeper ？

Zookeeper 是一个用于维护配置信息、命名、提供分布式同步和提供组服务的集中服务。 所有这些类型的服务都以某种形式被分布式应用程序使用。 每次实现它们时，都会有大量的工作用于修复不可避免的 bug 和竞争条件。 由于难以实现这些类型的服务，应用程序在开始时通常会缩减这些服务，这使得它们在出现变更时变得脆弱，难以管理。 即使正确地执行，在部署应用程序时，这些服务的不同实现也会导致管理复杂性。

ZooKeeper 的目标是将这些不同服务的精华提炼成一个非常简单的、集中的协调服务接口。 服务本身是分布式的，并且高度可靠的。 其一致性、集群管理和协议都将由服务来实现，这样应用程序就不需要自己再去实现它们。 这些应用程序的特定用途将由  Zookeeper 的特定组件和应用程序的特定约定组成。 而 Zookeeper Recipes 就向我们展示了如何使用这个简单的服务来构建更强大的抽象。

2、什么是 Zookeeper ？

ZooKeeper 是一个分布式的，开放源码的分布式应用程序协调服务，是 Google 的 Chubby 一个开源的实现，是 Hadoop 和 Hbase 的重要组件。它是一个为分布式应用提供一致性服务的软件，其主要功能包括：配置维护、域名服务、分布式同步、组服务管理等。

ZooKeeper 的目标就是错综复杂的、易出错的服务封装起来，将简其单易用的接口和性能高效、功能稳定的系统服务暴露出来并提供给用户调用使用。

3、Zooekeeper 基本原理

ZooKeeper 是以 Paxos 算法为基础的，而Paxos 算法存在活锁的问题，即当有多个 proposer 交错提交时，有可能互相排斥导致没有一个 proposer 能提交成功，而 Paxos 作了一些优化，通过选举产生一个leader （领导者），只有 leader 才能提交 proposer。

*注：所谓的 Paxos 算法是一种基于消息传递的一致性算法，并且该算法被认为是类似算法中最有效的。

ZooKeeper 的基本运行流程：
1、选举 Leader（所以一般要求3个，或者以上）。
2、同步数据。
3、选举 Leader 过程中算法有多中，但最终的选举标准是一致的。
4、Leader 被赋予最高的执行ID（竞选成功后的授权），其执行ID类似于Linux中的root权限。
5、集群中服务得到通知并一致的认可选出的 Leader。
6、Leader 服务器宕机，进入1）步，再次进行 Leader 选举。

4、Zookeeper 特性

在 Zookeeper 中，znode 是一个跟UFS（Unix File System） 路径相似的节点，可以往这个节点存储或获取数据。Zookeeper 使用 Watcher 事件进行监测，如果在创建 znode 时 Flag 设置为临时节点的（关于更多 Flag 的设置，请参考：Zookeeper 实战），那么当创建这个 znode 的节点与 Zookeeper 服务失去连接后，这个 znode 将不再存在在 Zookeeper 里。当客户端接收到事件信息，比如连接超时、节点数据改变、子节点改变，都可以调用相应的事件来处理数据。

Zookeeper 源码地址：GitHub For The Zookeeper

Eureka 与 zookeeper 的区别
1、了解什么是 CAP原则

CAP 原则又称 CAP 定理，1998年，加州大学的计算机科学家 Eric Brewer 提出的，指的是在一个分布式系统中，Consistency（一致性）、 Availability（可用性）、Partition tolerance（分区容错性），三者不可兼得（我们常说的鱼和熊掌不可兼得）。CAP 原则也是 NoSQL 数据库的基石。

2、CAP 原则的三个指标

1、一致性（Consistency，C）：在分布式系统中的所有数据备份，在同一时刻是否同样的值。（等同于所有节点访问同一份最新的数据副本）。

2、可用性（Availability，A）：在一个分布式系统的集群中一部分节点故障后，该集群是否还能够正常响应客户端的读写请求。（对数据更新具备高可用性）。

3、分区容错性（Partition tolerance，P）：大多数的分布式系统都分布在多个子网络中，而每个子网络就叫做一个区（partition）。分区容错的意思是，区间通信可能失败。比如阿里巴巴的服务器（不知道各位有没有发现，不管你到那个城市去，你访问的服务器总是该城市的，其中使用 了算法，由于篇幅有限就不再这儿一一讲解了），一台服务器放在上海，另一台服务器放在北京，这就是两个区，它们之间可能存在无法通信的情况。在一个分布式系统中一般分区容错是无法避免的，因此可以认为 CAP 中的 P 总是成立的。CAP 理论告诉我们，在 C 和 A 之间是无法同时做到。

3、区别

Spring Cloud Eureka  -> AP

Spring Cloud Netflix 在设计 Eureka 时就紧遵AP原则（尽管现在2.0发布了，但是由于其闭源的原因 ，博主一直无法进一步的研究，但是目前 Ereka 1.x 任然是比较活跃的）。Eureka Server 也可以运行多个实例来构建集群（后面专门的文章讲解），解决单点问题，但不同于 ZooKeeper 的选举 leader 的过程，Eureka Server 采用的是Peer to Peer 对等通信。这是一种去中心化的架构（参看：微服务与微服务架构思想与原则），无 master/slave 之分，每一个 Peer 都是对等的。在这种架构风格中，节点通过彼此互相注册来提高可用性，每个节点需要添加一个或多个有效的 serviceUrl 指向其他节点。每个节点都可被视为其他节点的副本。

在集群环境中如果某台 Eureka Server 宕机，Eureka Client 的请求会自动切换到新的 Eureka Server 节点上，当宕机的服务器重新恢复后，Eureka 会再次将其纳入到服务器集群管理之中。当节点开始接受客户端请求时，所有的操作都会在节点间进行复制（replicate To Peer）操作，将请求复制到该 Eureka Server 当前所知的其它所有节点中。

当一个新的 Eureka Server 节点启动后，会首先尝试从邻近节点获取所有注册列表信息，并完成初始化。Eureka Server 通过 getEurekaServiceUrls() 方法获取所有的节点，并且会通过心跳契约的方式定期更新。默认情况下，如果 Eureka Server 在一定时间内没有接收到某个服务实例的心跳（默认周期为30秒），Eureka Server 将会注销该实例（默认为90秒，如果某个 eureka.instance.lease-expiration-duration-in-seconds 进行自定义配置）。当 Eureka Server 节点在短时间内丢失过多的心跳时，那么这个节点就会进入自我保护模式（后面有文章会谈及关于 Eureka Server 的自我保护机制）。

Apache Zookeeper -> CP

与 Eureka 有所不同，Apache Zookeeper 在设计时就紧遵CP原则，即任何时候对 Zookeeper 的访问请求能得到一致的数据结果，同时系统对网络分割具备容错性，但是 Zookeeper 不能保证每次服务请求都是可达的。从 Zookeeper 的实际应用情况来看，在使用 Zookeeper 获取服务列表时，如果此时的 Zookeeper 集群中的 Leader 宕机了，该集群就要进行 Leader 的选举，又或者 Zookeeper 集群中半数以上服务器节点不可用（例如有三个节点，如果节点一检测到节点三挂了 ，节点二也检测到节点三挂了，那这个节点才算是真的挂了），那么将无法处理该请求。所以说，Zookeeper 不能保证服务可用性。

当然，在大多数分布式环境中，尤其是涉及到数据存储的场景，数据一致性应该是首先被保证的，这也是 Zookeeper 设计紧遵CP原则的另一个原因。但是对于服务发现来说，情况就不太一样了，针对同一个服务，即使注册中心的不同节点保存的服务提供者信息不尽相同，也并不会造成灾难性的后果。因为对于服务消费者来说，能消费才是最重要的，消费者虽然拿到可能不正确的服务实例信息后尝试消费一下，也要胜过因为无法获取实例信息而不去消费，导致系统异常要好（淘宝的双十一，京东的幺六八就是紧遵AP的最好参照）。

4、结束语

ZooKeeper 基于 CP，不能保证高可用，Eureka 基于AP，能保证高可用。作为注册中心而言，配置是不经常变动的，只有当新版本发布或者服务器出故障时会变动。CP 不合适于配置经常变动的，而 AP 在遇到问题时可以牺牲其一致性来保证系统服务的高可用性，既返回旧数据。

Eureka从理论上讲作为系统服务的注册中心是最适合的。也有不少人认为，在现实生产环境中他（她）遇到的很多项目都采用的是 Zookeeper + Dubbo 实现的服务注册与发现，那是因为你们的集群（业务流量需求）还不够庞大，流量小，一般环境运行都比较稳定的，基本上不会遇到注册中心的实例（节点）半数以上都挂了的情况，问题也不会那么的明显罢了，或根本就遇不到。

所以在实际生产环境中，选择 Zookeeper 还是选择 Eureka ，这个就要取决于系统架构师对于业务环境的权衡了。