微服务注册中心 Eureka 架构深入解读(2)

服务提供者、服务消费者、以及服务注册中心自己，启动后都会向注册中心注册服务(如果配置了注册)。下图是介绍如何完成服务注册的：

注册中心服务接收到 register 请求后：

• 保存服务信息，将服务信息保存到 registry 中;
• 更新队列，将此事件添加到更新队列中，供 Eureka Client 增量同步服务信息使用。
• 清空二级缓存，即 readWriteCacheMap，用于保证数据的一致性。
• 更新阈值，供剔除服务使用。
• 同步服务信息，将此事件同步至其他的 Eureka Server 节点。

服务续约机制

服务注册后，要定时(默认 30S，可自己配置)向注册中心发送续约请求，告诉注册中心“我还活着”。

注册中心收到续约请求后：

• 更新服务对象的最近续约时间，即 Lease 对象的 lastUpdateTimestamp;
• 同步服务信息，将此事件同步至其他的 Eureka Server 节点。
• 剔除服务之前会先判断服务是否已经过期，判断服务是否过期的条件之一是续约时间和当前时间的差值是不是大于阈值。

服务注销机制

服务正常停止之前会向注册中心发送注销请求，告诉注册中心“我要下线了”。

注册中心服务接收到 cancel 请求后：

• 删除服务信息，将服务信息从 registry 中删除;
• 更新队列，将此事件添加到更新队列中，供 Eureka Client 增量同步服务信息使用。
• 清空二级缓存，即 readWriteCacheMap，用于保证数据的一致性。
• 更新阈值，供剔除服务使用。
• 同步服务信息，将此事件同步至其他的 Eureka Server 节点。
• 服务正常停止才会发送 Cancel，如果是非正常停止，则不会发送，此服务由 Eureka Server 主动剔除。

服务剔除机制

Eureka Server 提供了服务剔除的机制，用于剔除没有正常下线的服务。

服务的剔除包括三个步骤，首先判断是否满足服务剔除的条件，然后找出过期的服务，最后执行剔除。

判断是否满足服务剔除的条件

有两种情况可以满足服务剔除的条件：

• 关闭了自我保护
• 如果开启了自我保护，需要进一步判断是 Eureka Server 出了问题，还是 Eureka Client 出了问题，如果是 Eureka Client 出了问题则进行剔除。

这里比较核心的条件是自我保护机制，Eureka 自我保护机制是为了防止误杀服务而提供的一个机制。Eureka 的自我保护机制“谦虚”的认为如果大量服务都续约失败，则认为是自己出问题了(如自己断网了)，也就不剔除了;反之，则是 Eureka Client 的问题，需要进行剔除。而自我保护阈值是区分 Eureka Client 还是 Eureka Server 出问题的临界值：如果超出阈值就表示大量服务可用，少量服务不可用，则判定是 Eureka Client 出了问题。如果未超出阈值就表示大量服务不可用，则判定是 Eureka Server 出了问题。

条件 1 中如果关闭了自我保护，则统统认为是 Eureka Client 的问题，把没按时续约的服务都剔除掉(这里有剔除的最大值限制)。

这里比较难理解的是阈值的计算：

• 自我保护阈值 = 服务总数 * 每分钟续约数 * 自我保护阈值因子。
• 每分钟续约数 =(60S/ 客户端续约间隔)

最后自我保护阈值的计算公式为：

自我保护阈值 = 服务总数 * (60S/ 客户端续约间隔) * 自我保护阈值因子。

举例：如果有 100 个服务，续约间隔是 30S，自我保护阈值 0.85。

自我保护阈值 =100 * 60 / 30 * 0.85 = 170。

如果上一分钟的续约数 =180>170，则说明大量服务可用，是服务问题，进入剔除流程;

如果上一分钟的续约数 =150<170，则说明大量服务不可用，是注册中心自己的问题，进入自我保护模式，不进入剔除流程。

找出过期的服务

遍历所有的服务，判断上次续约时间距离当前时间大于阈值就标记为过期。并将这些过期的服务保存到集合中。

剔除服务

在剔除服务之前先计算剔除的数量，然后遍历过期服务，通过洗牌算法确保每次都公平的选择出要剔除的任务，最后进行剔除。

执行剔除服务后：

• 删除服务信息，从 registry 中删除服务。
• 更新队列，将当前剔除事件保存到更新队列中。
• 清空二级缓存，保证数据的一致性。
• 实现过程参考 AbstractInstanceRegistry.evict() 方法。

服务获取机制

Eureka Client 获取服务有两种方式，全量同步和增量同步。获取流程是根据 Eureka Server 的多层数据结构进行的：

无论是全量同步还是增量同步，都是先从缓存中获取，如果缓存中没有，则先加载到缓存中，再从缓存中获取。(registry 只保存数据结构，缓存中保存 ready 的服务信息。)

• 先从一级缓存中获取
• a> 先判断是否开启了一级缓存
• b> 如果开启了则从一级缓存中获取，如果存在则返回，如果没有，则从二级缓存中获取
• d> 如果未开启，则跳过一级缓存，从二级缓存中获取
• 再从二级缓存中获取
• a> 如果二级缓存中存在，则直接返回;
• b> 如果二级缓存中不存在，则先将数据加载到二级缓存中，再从二级缓存中获取。注意加载时需要判断是增量同步还是全量同步，增量同步从 recentlyChangedQueue 中 load，全量同步从 registry 中 load。

服务同步机制

服务同步机制是用来同步 Eureka Server 节点之间服务信息的。它包括 Eureka Server 启动时的同步，和运行过程中的同步。

启动时同步

Eureka Server 启动后，遍历 eurekaClient.getApplications 获取服务信息，并将服务信息注册到自己的 registry 中。

注意这里是两层循环，第一层循环是为了保证已经拉取到服务信息，第二层循环是遍历拉取到的服务信息。

运行过程中同步

当 Eureka Server 节点有 register、renew、cancel 请求进来时，会将这个请求封装成 TaskHolder 放到 acceptorQueue 队列中，然后经过一系列的处理，放到 batchWorkQueue 中。

TaskExecutor.BatchWorkerRunnable是个线程池，不断的从 batchWorkQueue 队列中 poll 出 TaskHolder，然后向其他 Eureka Server 节点发送同步请求。

这里省略了两个部分：

一个是在 acceptorQueue 向 batchWorkQueue 转化时，省略了中间的 processingOrder 和 pendingTasks 过程。

另一个是当同步失败时，会将失败的 TaskHolder 保存到 reprocessQueue 中，重试处理。

写在最后

（编辑：ASP站长网）