Ribbon + Eureka感知故障实例的滞后性

我们先用一张图回顾一下Eureka客户端去Eureka Server拉取服务注册表的情况

• eureka server在最差情况下要3分钟才能感知到一个实例故障并从服务注册表剔除
• eureka client每隔30秒拉取服务注册表一次
• Spring提供的定时拉取eureka client的注册表，这个定时任务要30秒执行一次
• 综上所述，最差情况下Ribbon要4分钟才能感知到一个服务发生故障了

这里的最差情况只会发生在eureka client没有执行shutdown，或者没有调用eureka server对应的下线接口的情况下，这种发生的几率是很小的。

我们在生产环境中，肯定不是直接kill -9杀死一个服务，而是会做一定的优雅停机，这样的话，一般几十秒左右Ribbon就可以感知到一个服务实例故障，不再去请求这个故障实例了。

Spring是如何应对滞后性的？

Spring的设计理念是利用Hystrix来填补发往故障实例的请求，直接走对应的降级逻辑，这样就确保不会因为故障实例的问题，导致调用这个故障实例的那些服务长时间不能释放资源，导致服务雪崩。