SpringCloud 入门4Eureka 和 zookeeper 的区别

Eureka 与 Zookeeper 的区别

1、集群结构

• Eureka 的集群架构本身就是平级结构
• zookeeper和consul则均为 主从结构

2、集群角色

Eureka：平级都为主人

Eureka：集群各节点都是平起平坐的关系，数据是相互复制的，因此各个节点都是主人角色

• 如图，服务端 Eureka-server 会存储服务实例信息，通过复制实现服务实例信息在各个节点同步，并定期去检查服务实例信息状态；
• 各个客户端也会通过健康检查等机制进行自我状态检查，要是信息有了变化，均会向服务 Eureka-server 发起请求
• Eureka-server则会分别处理这些状态变化，来保持实例信息的更新

Zookeeper：一主多从结构

• zookeeper：集群角色包含leader、follower以及observer三类。
• 具体来说是一主多从结构，就是有一个 leader，多个follower，以及只负责读操作、不参与选举的 observer。

下面是关于三个角色之间的关系图

a）首先图上是有 client 和 serve r两大角色。client通过TCP与其中一个 server 建立连接。其中server分为leader、follower，以及observer三个角色

• leader: 负责投票的发起和决议
• follower: 同步 leader 的状态，参与 leader 选举。将写操作转发给 leader ,并参与“过半写成功”策略
• observer: 同步leader的状态，将写操作转发给Leader。不参加投票选举过程， 也不参加写操作的“过半写成功”策略

b）当leader因为网络或者其他原因挂掉之后，会重新在follower里面选择一个新的leader。
c）observer 机器可以在不影响写性能的情况下提升集群的读性能。

3、是否可以及时知道服务状态变化

• 由于 zooKeeper 具有 watcher 机制，因此可以及时知道数据目录的状态变化，那么也就可以及时知道服务器节点以及所注册的实例的变化。我们可以通过这种监听机制，能够实时获取到某个服务器的故障或者我们比较关心的节点数据的更改（zookeeper的节点znode包含服务器节点和数据节点）
• Eureka 没有这样的机制，只是可以通过管理端进行主动查看服务状态，并不能实时感知服务状态的变化 心跳连接

4、雪崩保护（即心跳机制）

• Eureka ：当Eureka Server节点在短时间内丢失过多客户端（可能发生了网络分区故障），默认是15分钟内收到的续约低于原来的85%时，这个节点就会进入自我保护模式
• zookeeper ：无

5、CAP理论

C： Consistency，一致性的意思。

• 一致性就是说，我们读写数据必须是一摸一样的。
  比如一条数据，分别存在两个服务器中，server1和server2。
  我们此时将数据 a 通过 server1 修改为数据 b。此时如果我们访问server1访问的应该是b。
• 当我们访问server2的时候，如果返回的还是未修改的a，那么则不符合一致性，如果返回的是b，则符合数据的一致性。

Availability，可用性的意思。

• 只要我对服务器，发送请求，服务器必须对我进行相应，保证服务器一直是可用的。

P：Partition tolerance，分区容错的意思。

• 一般来说，分布式系统是分布在多个位置的。比如我们的一台服务器在北京，一台在上海。可能由于天气等原因的影响。造成了两条服务器直接不能互相通信，数据不能进行同步。这就是分区容错。
• 我们认为，分区容错是不可避免的。也就是说 P 是必然存在的。

eureka 支持 AP ，即保障可用性和分区容错性

• eureka 优先保证可用性。在 Eureka 平台中，如果某台服务器宕机，Eureka 不会有类似于 ZooKeeper 的选举 leader 的过程；客户端请求会自动切换 到新的Eureka节点；
• 当宕机的服务器重新恢复后，Eureka会再次将其纳入到服务器集群管理之中；而对于它来说，所有要做的无非是同步一些新的服务 注册信息而已。
• Eureka 甚至被设计用来应付范围更广 的 网络分割故障，并实现“0”宕机维护需求。当网络分割故障发生时，每个 Eureka 节点，会持续的对外提供服务（注：ZooKeeper 不会）：
  • 接收新的服务注册同时将它们提供给下游的服务发现请求。 这样一来，就可以实现在同一个子网中（same side of partition），新发布的服务仍然可以被发现与访问。 没有master，不会出现脑裂
  • Eureka 各个节点都是平等的，几个节点挂掉不会影响正常节点的工作，剩余的节点依然可以提供注册和查询服务。而Eureka的客户端在向某个 Eureka 注册或时如果发现连接失败，则会自动切换至其它节点，只要有一台Eureka还在，就能保证注册服务可用(保证可用性)，只不过查到的信息可能不是最新的(不保证强一致性)。
  • 除此之外，Eureka 还有一种自我保护机制，如果在15分钟内超过85%的节点都没有正常的心跳，那么Eureka就认为客户端与注册中心出现了网络故障，此时不再注销示例，可以相应请求将其存在自己的缓存中，但不会同步，直到网络恢复。

zookeeper保证cp，即数据一致性和分区容错性

6、自动注销实例

zk 和 Eureka 均支持自动注销实例

• 1）Eureka：默认情况下，如果 Eureka Server 在90秒内没有接收到某个微服务实例的心跳，Eureka Server 将会注销该实例（时间间隔可以配置）在此基础上，也有保护机制

• 2）zookeeper: 使用临时节点，依托于 Session 超时时间来实现 TTL 功能来实现自动注销。可以给每一个键或目录指定一个存活时限TTL，当指定的秒数过去以后，如果相应的键或目录没有得到更新，就会被自动从Etcd记录中移除 设置存活时间

7、 社区是否活跃

• Eureka的更新频率相对来说，明显比较低，Zookeeper逐渐趋于成熟化，因此代码更新频率也很低，只是稍好于Eureka

8、是否有管理端

• Eureka 有现成的管理端；zookeeper没有现成的管理端，但客户端也可以根据提供的API，很容易自己实现一个也控制台。

9、负载均衡

使用了更多的机器保证了机器的良性使用，不会由于某一高峰时刻导致系统cpu急剧上升。负载均衡有好几种实现策略，常见的有：

• 随机 (Random)
• 轮询 (RoundRobin)
• 一致性哈希 (ConsistentHash)
• 哈希 (Hash)
• 加权（Weighted）

Eureka:使用 ribbon 实现负载均衡：

• Ribbon客户端组件提供一系列完善的配置项如连接超时，重试等。简单的说，就是在配置文件中列出Load Balancer (简称LB) 后面所有的机器，Ribbon 会自动帮助你基于某种规则（如 简单轮询，随机连接等 ）去连接这些机器。我们容易使用Ribbon 实现自定义负载均衡的算法
• Ribbon本地负载均衡，在调用微服务接口的时候，会在注册中心上获取服务列表之后缓存到 JVM 本地，从而本地实现 RPC 远程调用 （Nginx 是服务器负载均衡，客户端所有的请求都会交给 nginx ，然后由 nginx 实现转发请求。即负载均衡是由服务端实现的）

Zookeeper:一般可以直接采用 RPC 的负载均衡

• RPC【Remote Procedure Call】 是指远程过程调用，是一种进程间通信方式，他是一种技术的思想，而不是规范。详情见 Dubbo 入门（1）

10、Spring Cloud集成

两种注册中心，现均已支持Spring Cloud的集成

11 健康检查

• Eureka：Eureka Server 与 Eureka Client 之间使用心跳机制来确定Eureka Client 的状态，默认情况下，服务器端与客户端的心跳保持正常，应用程序就会始终保持UP状态
• Zookeeper：本身没有健康检查机制，需要消费者自己实现服务提供者的健康检查动作

12 是否可用作配置中心

除了eureka不可以作为配置中心以外注册中心有专门的config类，其他均可以作为配置中心

13 多数据中心

• 都有方案部署为多数据中心

14 跨注册中心同步

都不支持注册中心同步

15 Dubbo集成

• zookeeper 支持Dubbo集成
• Eureka 暂不支持

16 K8S 集成

• 二个注册中心均支持k8s集成

这篇好文章是转载于：学新通技术网