Eureka 系列（02）Eureka 一致性协议

Posted 2020-11-15 binarylei

目录

• Eureka 系列（02）Eureka 一致性协议
  • 1. 服务发现方案对比
    • 1.1 技术选型
    • 1.2 数据模型
  • 2. Eureka 一致性协议
    • 2.1 消息广播
    • 2.2 崩溃恢复
  • 3. 可靠性
    • 3.1 高可用客户端（Client HA）
    • 3.2 自我保护

Eureka 系列（02）Eureka 一致性协议

Eureka 是由 Netflix 基于 AP 模型的服务发现中间件，包括服务发现服务器和客户端的。相关文档推荐：一是 Spring Cloud Eureka 官网，二是 Eureka源码解析。

本系列源码分析基于 spring-cloud-starter-netflix-eureka-2.1.1.RELEASE 和 Eureka-1.9.8。

1. 服务发现方案对比

1.1 技术选型

表1：Spring Cloud 服务发现方案对比

技术选型	CAP模型	适用规模(建议)	控制台管理	社区活跃度
Eureka	AP	<30k	支持	低
Zookeeper	CP	<20k	不支持	中
Consul	AP	<5k	支持	高
Nacos	AP/CP	100k+	支持	靠大家啦?

注： 以上数据来源于 小马哥技术周报。

1.2 数据模型

表2：Spring Cloud 服务发现数据模型

框架	集群(框架)	服务应用	服务集群	服务实例	租约管理
Spring-Cloud	--	(serviceId)	--	ServiceInstance	--
Nacos	Server	Service	Cluster	Instance	--
Eureka	(serviceUrl)	Application(appName)	--	InstanceInfo(id)	Lease

不同的框架对应的数据结构不太一致，在此做一些约定：

1. 服务器集群 Server：指的是 Eureka Server 本身的集群。用 Server 代替，也可能是 ServerList 之类，总之与 Server 或 Peer 或 Node 相关的都代表框架自身的集群。
2. 服务 Service：代表一个应用，可能包含多个服务实例。 Service(服务) 或 serviceId 或 Application(应用) 或 appName 。
3. 集群 Cluster：一个 Service 可能包含多个 Cluster，Cluster 包含多个具体的实例。这是 Nacos 中的概念。
4. 服务实例 ServiceInstance：代表注册的一个具体实例。ServiceInstance(服务实例)或 InstanceInfo(实例id)或 Instance(实例)。

2. Eureka 一致性协议

Eureka 和 Zookeeper 的最大区别： Eureka 是 AP 模型，Zookeeper 是 CP 模型。在出现脑裂等场景时，Eureka 可用性是每一位，也就是说出现脑裂时，每个分区仍可以独立提供服务，是去中心化的。更多 Eureka与ZooKeeper 的比较。

那 Eureka 是如何实现最终一致性的呢？

2.1 消息广播

1. Eureka Server 管理了全部的服务器列表（PeerEurekaNodes）

2. 当 Eureka Server 收到客户端的注册、下线、心跳请求时，通过 PeerEurekaNode 向其余的服务器进行消息广播，如果广播失败则重试，直到任务过期后取消任务，此时这两台服务器之间数据会出现短暂的不一致。

   注意： 虽然消息广播失败，但只要收到客户端的心跳，仍会向所有的服务器（包括失联的服务器）广播心跳任务。

3. 如果网络恢复正常，收到了其它服务器广播的心跳任务，此时可能有三种情况：

   1. 一是脑裂很快恢复，一切正常；
   2. 二是该实例已经自动过期，则重新进行注册；
   3. 三是数据冲突，出现不一致的情况，则需要发起同步请求，其实也就是重新注册一次，同时踢除老的实例。

   总之，通过集群之间的消息广播可以实现数据的最终一致性。

2.1.2 服务注册

1. Spring Cloud Eureka 在应用启动时，会在 EurekaAutoServiceRegistration 这个类初始化的时候，主动去 Eureka Server 端注册。
2. Eureka 在启动完成之后会启动一个 40 秒执行一次的定时任务，该任务会去监测自身的 IP 信息以及自身的配置信息是否发生改变，如果发生改变，则会重新发起注册。
3. 续约返回 404 状态码时，会去重新注册

2.1.3 主动下线

Eureka 会在 spring 容器销毁的时候执行 shutDown 方法 ，该方法首先会将自身的状态改为 DOWN，接着发送cancle 命令至 Eureka Server 请求下掉自己的服务。

2.1.4 心跳续约与自动下线

健康检测，一般都是 TTL(Time To Live) 机制。eg: 客户端每 5s 发送心跳，服务端 15s 没收到心跳包，更新实例状态为不健康， 30s 未收到心跳包，从服务列表中删除。

Eureka Server 默认每 30s 发送心跳包，90s 未收心跳则删除。这个清理过期实例的线程，每 60s 执行一次。

2.2 崩溃恢复

2.2.1 重启

Spring Cloud Eureka 启动时，在初始化 EurekaServerBootstrap#initEurekaServerContext 时会调用 PeerAwareInstanceRegistryImpl#syncUp 从其它 Eureka 中同步数据。

2.2.2 脑裂

• 发生脑裂后：和 Eureka Server 同区的服务可以正常访问，而不同区的服务则自动过期。
• 脑裂恢复后：接收其它 Eureka Sever 发送过来的心跳请求，此时有三种情况：一是脑裂很快恢复，一切正常；二是该实例已经自动过期，则重新进行注册；三是数据冲突，出现不一致的情况，则需要发起同步请求。

3. 可靠性

3.1 高可用客户端（Client HA）

当有多个 Eureka Server 时，第一台宕机时会从下一台同步数据。注意：只有当第一台宕机时才会同步第二台，否则永远只会从第一台同步数据。

3.2 自我保护

如果每分钟的续约数小于阀值时 ，则开启自我保护机制，Eureka Server 将不会主动清除过期实例。

---

每天用心记录一点点。内容也许不重要，但习惯很重要！