Eureka服务注册中心的失效剔除与自我保护机制

Eureka作为一个成熟的服务注册中心当然也有合理的内部维护服务节点的机制，比如我们本章将要讲解到的服务下线、失效剔除、自我保护，也正是因为内部有这种维护机制才让Eureka更健壮、更稳定。

本章目标

了解Eureka是怎么保证服务相对较短时长内的有效性。

服务下线

迭代更新、终止访问某一个或者多个服务节点时，我们在正常关闭服务节点的情况下，Eureka Client会通过PUT请求方式调用Eureka Server的REST访问节点/eureka/apps/{appID}/{instanceID}/status?value=DOWN请求地址，告知Eureka Server我要下线了，Eureka Server收到请求后会将该服务实例的运行状态由UP修改为DOWN，这样我们在管理平台服务列表内看到的就是DOWN状态的服务实例。

有关Eureka Server内部的REST节点地址，请访问/eureka-rest.html来了解详情。

失效剔除

Eureka Server在启动完成后会创建一个定时器每隔60秒检查一次服务健康状况，如果其中一个服务节点超过90秒未检查到心跳，那么Eureka Server会自动从服务实例列表内将该服务剔除。

由于非正常关闭不会执行主动下线动作，所以才会出现失效剔除机制，该机制主要是应对非正常关闭服务的情况，如：内存溢出、杀死进程、服务器宕机等非正常流程关闭服务节点时。

自我保护

Eureka Server的自我保护机制会检查最近15分钟内所有Eureka Client正常心跳的占比，如果低于85%就会被触发。
我们如果在Eureka Server的管理界面发现如下的红色内容，就说明已经触发了自我保护机制。

EMERGENCY! EUREKA MAY BE INCORRECTLY CLAIMING INSTANCES ARE UP WHEN THEY'RE NOT. RENEWALS ARE LESSER THAN THRESHOLD AND HENCE THE INSTANCES ARE NOT BEING EXPIRED JUST TO BE SAFE.

当触发自我保护机制后Eureka Server就会锁定服务列表，不让服务列表内的服务过期，不过这样我们在访问服务时，得到的服务很有可能是已经失效的实例，如果是这样我们就会无法访问到期望的资源，会导致服务调用失败，所以这时我们就需要有对应的容错机制、熔断机制，我们在接下来的文章内会详细讲解这块知识点。

我们的服务如果是采用的公网IP地址，出现自我保护机制的几率就会大大增加，所以这时更要我们部署多个相同InstanId的服务或者建立一套完整的熔断机制解决方案。

自我保护开关

如果在本地测试环境，建议关掉自我保护机制，这样方便我们进行测试，也更准备的保证了服务实例的有效性！！！

关闭自我保护只需要修改application.yml配置文件内参数eureka.server.enable-self-preservation将值设置为false即可。

总结

我们通过本章的讲解，了解到了Eureka Server对服务的治理，其中包含服务下线、失效剔除、自我保护等，对自我保护机制一定要谨慎的处理，防止出现服务失效问题。