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，围观朋友圈，做个点赞之交。