默认情况下eurekaclient会定时向eurekaserver端发送心跳(默认是30S),如果eurekaserver在一定时间内没有收到eurekaclient发送的心跳,便会把该实例从注册服务列表中剔除(默认是90S),但是短时间内丢失大量的实例心跳的话,这时候eurekaserver会开启自我保护机制,.所有的注册服务实例都将被保护起来,不被剔除.
产生的原因:
在开发测试时,需要频繁的重启服务实例,但是注册中心并不会一起重启,当在15分钟内收到的心跳数量低于总数的85%时,就会触发自我保护机制.我们可以在eureka管理界面上看到Renews threshold和Renews(last min),当后者(最后一分钟收到的心跳数) 小于前者(心跳阈值,也就是eureka计算的85%的心跳边界值) 的时候就会触发保护机制,会出现红色的警告
Renews threshold和Renews (last min)具体计算方式
Renews threshold 计算代码：
this.expectedNumberOfRenewsPerMin = count * 2;
this.numberOfRenewsPerMinThreshold = (int) (this.expectedNumberOfRenewsPerMin * serverConfig.getRenewalPercentThreshold());count表示服务的数量，如果 Eureka Server 开启自注册模式，也算一个服务，假设我们一共有4个服务,4个服务每个服务30S发送一次心跳,也就是一个服务一分钟有两次心跳,按照上面的公式就是4*2=8, 8是eureka server 理论上一分钟应该收到的心跳数,而自我抱回功能是低于85%的心跳,所以8*0.85=0.68 也就是6个,所以Renews threshold 的值为6 .
Renews (last min)代表一分钟服务端实际接收到的心跳,正常情况4个服务,收到的心跳应该是8,所以正常情况8永远都等于6,所以不会触发eureka的自我保护机制.
自我保护机制设计的初衷:
而eureka的自我保护机制的初衷是为了避免网络连接故障,在发生网络故障时,微服务和注册中心之间无法正常通信,但是服务本身是健康的,不应该注销该服务,如果eureka因为网络故障而把微服务误删除了,是非常不合理的.所以，eureka server在短时间内丢失过多的客户端心跳时，会进入自我保护模式，该模式下，eureka会保护注册表中的信息，不在注销任何微服务，当网络故障恢复后，eureka会自动退出保护模式。自我保护模式可以让集群更加健壮。
实际开发场景下:
但是我们在开发测试阶段，需要频繁地重启发布，如果触发了保护机制，则旧的服务实例没有被删除，这时请求有可能跑到旧的实例中，而该实例已经关闭了，这就导致请求错误，影响开发测试。所以，在开发测试阶段，我们可以把自我保护模式关闭，只需在eureka server配置文件中加上如下配置即可：
但在生产环境，不会频繁重启，所以，一定要把自我保护机制打开，否则网络一旦终端，就无法恢复。
