Eureka核心源码解析系列(二)- 服务剔除、下线篇
在上一篇文章中,我们介绍了Eureka的服务注册与服务续约,今天我们再来接着往下看看服务剔除和服务下线的原理。
服务剔除
Eureka-server
当Eureka-server发现有的实例没有续约超过一定时间,则将该服务从注册列表剔除,该项工作由一个定时任务完成的。该任务的定义过程比较复杂,仅列出其调用过程:
EurekaServerInitializerConfiguration # start() ->
EurekaServerBootstrap # contextInitialized() ->
# initEurekaServerContext() ->
PeerAwareInstanceRegistryImpl # openForTraffic() ->
AbstractInstanceRegistry # postInit()
在AbstractInstanceRegistry
的postInit
方法中,定义EvictionTask
定时任务,构建定时器启动该任务,执行任务中剔除方法 evict()
。
private long evictionIntervalTimerInMs = 60 * 1000;
任务的时间被定义为60秒,即默认每分钟执行一次。具体查看evit()
剔除方法:
实现了功能:
1、新建实例列表expiredLeases
,用来存放过期的实
2、遍历registry
注册表,对实例进行检测工作,使用isExpired
方法判断实例是否过期:
解释一下各个参数的意义:
evictionTimestamp:剔除时间,当剔除节点的时候,将系统当前时间赋值给这个evictionTimestamp
additionalLeaseMs:集群同步产生的预留时间,这个时间是程序中传过来的
这里进行判断:
系统当前时间 > 最后更新时间 + 过期时间 + 预留时间
当该条件成立时,认为服务过期。在Eureka中过期时间默认定义为3个心跳的时间,一个心跳是30秒,因此过期时间是90秒。当该条件成立时,认为服务过期。在Eureka中过期时间默认定义为3个心跳的时间,一个心跳是30秒,因此过期时间是90秒
当以上两个条件之一成立时,判断该实例过期,将该过期实例放入上面创建的列表中。注意这里仅仅是将实例放入List中,并没有实际剔除。
在实际剔除任务前,需要提一下eureka的自我保护机制,当15分钟内,心跳失败的服务大于一定比例时,会触发自我保护机制。
这个值在Eureka中被定义为85%,一旦触发自我保护机制,Eureka会尝试保护其服务注册表中的信息,不再删除服务注册表中的数据。
参数意义:
registrySizeThreshold:根据阈值计算可以被剔除的服务数量最大值
evictionLimit:剔除后剩余最小数量
expiredLeases.size():剔除列表的数量
上面的代码中根据自我保护机制进行了判断,使用Min函数计算两者的最小值,剔除较小数量的服务实例。
举个例子,假如当前共有100个服务,那么剔除阈值为85,如果list中有60个服务,那么就会剔除该60个服务。但是如果list中有95个服务,那么只会剔除其中的85个服务,在这种情况下,又会产生一个问题,eureka-server该如何判断去剔除哪些服务,保留哪些服务呢?
这里使用了随机算法进行剔除,保证不会连续剔除某个微服务的全部实例。最终调用internalCancel
方法,实际执行剔除。
其实剔除操作的实质非常简单,就是从gMap
中remove
掉这个节点,并从缓存中剔除。
服务下线
Eureka-client
当eureka-client关闭时,不会立刻关闭,需要先发请求给eureka-server,告知自己要下线了。主要看一下客户端shutdown
方法,其中调用关键的unregister
方法:
调用AbstractJerseyEurekaHttpClient
的cancel
方法
发送http请求告诉eureka-server自己下线。
Eureka-server
调用AbstractInstanceRegistry
中 cancel
方法:
最终还是调用了和服务剔除中一样的方法,remove
掉了gMap
中的实例。
总结
本文作为Eureka源码分析的第二篇,主要分析了服务的剔除和下线,和注册过程比起来,这两个过程相对简单一些。下一篇文章,我们讲讲最后的服务发现和集群信息同步。
最后
觉得对您有所帮助,小伙伴们可以点个赞啊,非常感谢~
公众号『码农参上』,一个热爱分享的公众号,有趣、深入、直接,与你聊聊技术。欢迎来加我好友 DrHydra9,围观朋友圈,做个点赞之交。
- 点赞
- 收藏
- 关注作者
评论(0)