加入收藏 | 设为首页 | 会员中心 | 我要投稿 西安站长网 (https://www.029zz.com.cn/)- 科技、建站、经验、云计算、5G、大数据,站长网!
当前位置: 首页 > 建站 > 正文

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

发布时间:2019-08-23 18:31:27 所属栏目:建站 来源:Java从算法到架构
导读:副标题#e# 微服务架构中最核心的部分是服务治理,服务治理最基础的组件是注册中心。随着微服务架构的发展,出现了很多微服务架构的解决方案,其中包括我们熟知的 Dubbo 和 Spring Cloud。 关于注册中心的解决方案,dubbo 支持了 Zookeeper、Redis、Multicas

这里比较核心的条件是自我保护机制,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 的多层数据结构进行的:

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

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

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

服务同步机制

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

启动时同步

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

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

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

运行过程中同步

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

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

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

这里省略了两个部分:

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

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

写在最后

(编辑:西安站长网)

【声明】本站内容均来自网络,其相关言论仅代表作者个人观点,不代表本站立场。若无意侵犯到您的权利,请及时与联系站长删除相关内容!

热点阅读