Eureka的自我保护模式

默认情况下，如果Eureka Server在90s内没有接收到某个微服务的心跳，Eureka Server将会移除该微服务。

但是当发生网络故障时，微服务与Eureka Server之间无法正常通信，而微服务本身是正常运行的，则此时不应该移除这个微服务。

所以Eureka引入了自我保护模式。

官方对于自我保护模式的定义是：一种针对网络异常波动的安全保护措施。

使用自我保护模式能使Eureka集群更加健壮、稳定地运行。

 

自我保护模式的工作机制是：

如果在15min内超过85%的客户端节点都没有正常的心跳，那么Eureka就认为客户端与注册中心之间出现了网络故障，Eureka Server将自动启动自我保护机制，此时Eureka Server不再从注册列表中移除因为长时间没收到心跳而应该过期的服务。

 

我们来做实验验证一下该机制。先启动第9章我们创建的Eureka Server和两个微服务，然后访问注册中心。

 

 

然后，我们停止其中一个微服务order，大概90s后再刷新一下这个页面，可以看到页面中出现红色文字提示，如图所示。出现这个提示就表明Eureka Server触发了自我保护，而实例列表中确实没有移除我们停止的order微服务。

 

 

 

为了验证续约频率高于阈值的情况，我们必须增加微服务的数量。为了方便，我们通过在同一个微服务中配置多个运行的方式快速得到6个微服务，如图所示。

 

 

单击左上角的加号选择Spring Boot，然后选择Main class启动类，再添加不同的端口号和名字即可。因为每个微服务都要分配一个不同的端口号和名字，所以需要通过设置覆盖端口号和名字的配置。

 

然后我们启动这些微服务，再次访问注册中心，可以看到注册了6个微服务，如图所示。

 

 接着，我们停止一个微服务goods5，大概90s后刷新此页面，结果如图所示。可以发现注册中心直接移除了goods5，证明此时并没有触发自我保护，因为我们只停止了众多微服务中的一个，续约频率低于阈值85%。

 

通过上面的实验，我们证实了Eureka Server的自我保护模式。在开发过程中，更多时候我们想知道服务真实的续约状态，这时就需要关闭Eureka Server的自我保护模式了。

通过配置 eureka.server.enable-self-preservation为false禁用自我保护模式，如程序清单10-1所示。不过在生产环境时建议开启此配置。