SpringCloud | 第三章: Eureka 高可用配置

前言

上一章节简单介绍了 注册中心 Eureka，而在实际工作中，大型的项目都要有容灾机制，即发生故障时，要保证系统的稳定性。本章节就来说说关于 Eureka 的高可用。

Zookeeper 和 Eureka 之间的区别

先聊聊 Zookeeper 和 Eureka 两者间的区别吧。

CAP 理论

在总结两者的区别之前，我们先来看一个 CAP 理论。什么叫 CAP 理论呢？CAP 理论是由 Eric Brewer 教授提出，是分布式系统中的一个重要的概念。CAP 具体如下：

C（Consistency）：数据一致性。大家都知道，分布式系统中，数据会有副本。由于网络或者机器故障等因素，可能有些副本数据写入正确，有些却写入错误或者失败，这样就导致了数据的不一致了。而满足数据一致性规则，就是保证所有数据都要同步。

A（Availability）：可用性。我们需要获取什么数据时，都能够正常的获取到想要的数据（当然，允许可接受范围内的网络延迟），也就是说，要保证任何时候请求数据都能够正常响应。

P（Partition Tolerance：分区容错性。当网络通信发生故障时，集群仍然可用，不会因为某个节点挂了或者存在问题，而影响整个系统的正常运作。

对于分布式系统来说，出现网络分区是不可避免的，因此分区容错性是必须要具备的，也就是说，CAP三者，P是必须的，是个客观存在的事实，不可避免，也无法绕过。

Zookeeper 与 Eureka 区别

对于Eureka而言，其是满足AP的，而Zookeeper而言，是满足CP的。

1. Eureka 的 AP 原则：
   大规模网络部署时，失败是在所难免的，因此我们无法回避这个问题。当向注册中心查询服务列表时，我们可以容忍注册中心返回的是几分钟以前的注册信息，但不能接受服务直接 down 掉不可用。
   Eureka 在被设计的时候，就考虑到了这一点，因此在设计时优先保证可用性，这就是 AP 原则。Eureka 各个节点都是平等的，几个节点挂掉不会影响正常节点的工作，剩余的节点依然可以提供注册和查询服务。而 Eureka 的客户端在向某个 Eureka 注册或时如果发现连接失败，则会自动切换至其它节点，只要有一台 Eureka 还在，就能保证注册服务可用（即保证A原则），只不过查到的信息可能不是最新的（不保证C原则）。
   正因为应用实例的注册信息在集群的所有节点间并不是强一致的，所以需要客户端能够支持负载均衡以及失败重试。在 Netflix 的生态中，ribbon 可以提供这个功能。
   因此， Eureka 可以很好的应对因网络故障导致部分节点失去联系的情况，而不会像 zookeeper 那样使整个注册服务瘫痪。

2. Zookeeper 的 CP 原则
   对于 zookeeper 来说，它是 CP 的。也就是说，zookeeper 是保证数据的一致性的，但是这里还需要注意一点是，zookeeper 它不是强一致的，什么意思呢？打个比方，现在客户端 A 提交一个写操作，zookeeper 在过半数节点操作成功之后就可以返回，但此时，客户端 B 的读操作请求的是 A 写操作尚未同步到的节点，那么读取的就不是 A 最新提交的数据了。
   那如何保证强一致性呢？我们可以在读取数据的时候先执行一下 sync 操作，即与 leader 节点先同步一下数据，再去取，这样才能保证数据的强一致性。
   但是 zookeeper 也有个缺陷，刚刚提到了 leader 节点，当 master 节点因为网络故障与其他节点失去联系时，剩余节点会重新进行 leader 选举。问题在于，选举 leader 的时间太长，30 ~ 120s, 且选举期间整个 zookeeper 集群都是不可用的，这就导致在选举期间注册服务瘫痪。
   在云部署的环境下， 因网络问题使得 zookeeper 集群失去 master 节点是较大概率会发生的事，虽然服务能够最终恢复，但是漫长的选举时间导致的注册长期不可用是不能容忍的。比如双十一当天，那就是灾难性的。

所以，综上所述，作为服务注册中心而言，可用性原则是比数据一致性更重要的，可以接受短时间内数据不一致的情况。同时由于Eureka有自我保护模式，可保护服务注册表中的信息不被剔除，所以 Eureka 可以很好的应对因网络故障导致节点失去联系的情况。个人觉得 Eureka 作为单纯的服务注册中心来说要比 Zookeeper 更加“专业”一点。

Eureka的高可用原理

Eureka Server 的设计一开始就考虑了高可用的问题，在 Eureka 的服务治理设计中，所有的节点既是服务的提供方，也是服务消费方，服务注册中心也不例外。

Eureka Server 的高可用实际上就是将自己作为服务向其他服务注册中心注册自己，这样就可以形成一组互相注册的服务注册中心，以实现服务清单的互相同步，达到高可用的效果。

Eureka 服务端高可用

还是以上一章节的代码为例，增加 application.yml 的配置。启动两个相同的 Eureka Server 相互往对方的注册中心注册

spring:
  application:
    # 应用名称,默认也是注册中心的ID
    name: registry
server:
  # 注册中心映射端口号,默认端口8761
  port: 8761
eureka:
  client:
    # 对于Eureka服务器来说,自己没必要注册客户端
    register-with-eureka: false
    # 新增配置Eureka的高可用配置，往8762端口的注册中心注册
    service-url:
      defaultZone: http://localhost:8762/eureka

此时启动程序，分别访问http://localhost:8761/eureka 、http://localhost:8762/eureka，可以发现数据注册的客户端一致且注册中心相互注册。

Eureka 客户端注册

客户端往Eureka注册服务， application.yml 的配置，原先默认defaultZone填写一个注册中心的地址，一个注册成功后会将数据同步到另一个注册中心。但是如果defaultZone只填写一个注册中心，当这个注册中心无法访问时就无法注册。因此在defaultZone 中填写两个注册中心，客户端会依次去注册，直到注册成功为止。

spring:
  application:
    #客户端名称
    name: client
eureka:
  client:
    service-url:
    # 注册地址，往两个注册中心注册，依次注册，成功就不往后注册。
      defaultZone: http://localhost:8761/eureka/,http://localhost:8762/eureka
server:
  port: 8081

小结

本章主要是简单介绍Eureka服务的高可用，以及客户端的注册。了解了CAP、Zookeeper 和 Eureka 之间的区别。