##序 最近一口气发布好几个服务,涉及大约9个实例同时更新,而总共有16个服务实例注册,出现了eureka开启自我保护模式,过了好几分钟还没有恢复。
##分析 设定的eureka.instance.leaseRenewalIntervalInSeconds为10秒。eureka为2个实例,eureka.server.renewalPercentThreshold为0.85,而eureka.server.renewalThresholdUpdateIntervalMs为900000。
按这么算,正常的阈值为27,而当9个服务重启,则瞬间注册的实例为16+9=25,那么此时阈值就更新为42,而启动的时候,旧的9个实例相续关闭,而新的9个实例相续还没有启动起来,那么实际每分钟能发送心跳的数为7*6=42.
##是否开启自我保护 eureka-core-1.4.12-sources.jar!/com/netflix/eureka/registry/PeerAwareInstanceRegistryImpl.java
@Override
public boolean isLeaseExpirationEnabled() {
if (!isSelfPreservationModeEnabled()) {
// The self preservation mode is disabled, hence allowing the instances to expire.
return true;
}
return numberOfRenewsPerMinThreshold > 0 && getNumOfRenewsInLastMin() > numberOfRenewsPerMinThreshold;
}
最近1分钟收到的心跳数没有大于阈值,那么这个时候,就开启自我保护了。
##小结 这个有点类似惊群问题(thundering herd):
故障后的服务恢复上线后,如果有大量其他服务正在同一个重试窗口内重试,此时很容易给系统造成巨大压力。这种情况也叫惊群效应(Thundering herd),使用随机化的重试窗口可轻松避免这种问题。如果基础架构没有实施断路开关,建议将随机化重试窗口与指数退避(Exponential backoff)配合使用以便让请求进一步分散。
同理,对于使用eureka作为服务发现的应用来说,在部署生产的要十分小心,要么每次部署的实例不要太多,要么修改eureka的相关参数,比如renewalPercentThreshold或者renewalThresholdUpdateIntervalMs。
想获取最新资讯,请关注微信公众号