Eureka服务实例下线机制

た入场券 2023-02-27 08:05 11阅读 0赞

Eureka服务实例的下线包含两种情况，第一种就是正常的服务实例下线，第二种是服务实例故障，然后自动摘除故障的服务实例

先来说说第一种情况，当一个eureka client正常的服务下线时，会自己调用一个shutdown()方法来执行下线的逻辑，里面包含了一些资源的释放，组件的关闭，主要是又会去调用一个cancelLease的接口，这里的Lease其实维护的是心跳的信息，eureka client和eureka server之间需要维护心跳，才能知道对方是不是还活着，还在正常工作

在cancelLease这个接口中，会将要下线的服务实例从注册表中删除，同时会在Lease，也就是心跳信息中维护一个evictionTimestamp变量作为实例的下线时间，通过evictionTimestamp就能判断一个实例是否已经下线了

最后还会利用到多级缓存的机制，简单来说就是将下线的服务实例丢到了一个最近变更队列recentChangedQueue中，然后由一个定时任务，每隔30秒将readWriteCacheMap（读写缓存）和readOnlyCacheMap（只读缓存）进行一个同步，下次所有的eureka client来拉取增量注册表的时候，就会发现readOnlyCacheMap里没有，会找readWriteCacheMap也会发现没有，然后就会从注册表里抓取增量注册表，recentChangedQueue中所包含的已经下线的实例就会从服务注册表中删除掉

如果上面的多级缓存相关的东西看不懂的话，有兴趣的同学可以参考一下[Eureka的注册表拉取及多级缓存机制简析][Eureka]

总体来说停止服务实例时的实例摘除大概就是下面这张图的逻辑  
![服务实例下线时的实例摘除][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0xPX1lVTg_size_16_color_FFFFFF_t_70]  
说完了正常的服务实例下线，再来讲一下服务实例故障时的服务实例摘除，上面讲到了eureka是通过心跳来感知某个服务是否已经宕机了，如果长时间没有收到服务的心跳的话，就认为那个服务实例已经宕机了，此时就会有一套自动故障感知机制来处理

这套自动感知机制也是通过一个定时任务，定期查看心跳信息中的服务实例是否已经过期  
这边再补充一下心跳信息Lease，其实心跳做的事情很简单，就是维护了一个lastUpdateTimestamp，代表的是上一次更新的时间戳，这个值是用当前时间加上心跳的间隔时间（默认90秒）

回过头来说判断服务实例是否已过期的条件，一个是evictionTimestamp，这个在上面说了，只要大于0，那么就说明当前的服务实例过期了，另外一个判断条件是判断当前时间是否大于lastUpdateTimestamp + 心跳间隔时间 + 补偿时间

这里就有一个问题了lastUpdateTimestamp里面已经加了一次心跳间隔时间了，这里又加了一遍，是不是重复了  
答案是就是重复了，这里算是一个bug吧，但是eureka也并不打算改了，我这里贴一下官方的注释，duration就是心跳间隔时间

* Note that due to renew() doing the 'wrong" thing and setting lastUpdateTimestamp to +duration more than
    * what it should be, the expiry will actually be 2 * duration. This is a minor bug and should only affect
    * instances that ungracefully shutdown. Due to possible wide ranging impact to existing usage, this will
    * not be fixed.

接着再来说明一下补偿时间，这个补偿时间其实是为了防止系统的一些非正常的时间延迟，比如说长时间的gc卡顿和linux系统时钟不准确等等原因  
打个比方，比如服务实例下线需要180秒，但是我的时钟出现了问题，延迟了30秒，那么只有210秒之后，才真正认为服务已经故障下线了

当所有的心跳信息都判断过了服务实例是否已经故障下线之后，下线的服务实例会加入到一个list中，如果你一次有大量的服务实例故障下线的话，其实是不会一次性将这些服务实例都下线掉的，有一个RenewalPercentThreshold，默认是0.85，这个的意思是只有15%的服务能被下线，其他已故障的服务实例需要等到下一次调用定时任务的时候才能接着下线

下线的服务实例是随机选择的，实际的下线逻辑跟上面的主动过期一样，还是注册表删除，下线服务实例加入到recentChangedQueue，然后多级缓存过期那一套

最后再来按照源码的顺序梳理一遍服务故障的实例摘除逻辑  
（1）调用定时任务检查服务实例是否过期，先计算出补偿时间  
（2）对每个服务的Lease信息判断一下，看看服务实例的心跳时间是否已经过期，将过期的服务实例加入list中  
（3）如果要下线的服务实例太多了，超过15%（默认）的服务实例都出问题了，那么就会分批下线，分批是随机选择服务实例的  
（4）从注册表中删除故障的服务实例，并维护最近变更的实例队列，更新多级缓存的数据

通过主动下线和故障自动检测机制，其余的服务实例就能感知到其他服务实例的下线，在这之间可能会存在一定的时间延迟，但是最终所有的服务实例都能完成最终的服务实例下线检测，所以Eureka其实在CAP理论中是一个AP的结构，因为他只能保证最终一致性，而不能保证强一致性

[Eureka]: https://blog.csdn.net/LO_YUN/article/details/107067869
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0xPX1lVTg_size_16_color_FFFFFF_t_70]: /images/20230209/80a6e0f9b0934d91b750469db0b2ca56.png