「 从0到1学习微服务SpringCloud 」03 Eureka的自我保护机制

系列文章(更新ing):

「 从0到1学习微服务SpringCloud 」01 一起来学呀!

「 从0到1学习微服务SpringCloud 」02 Eureka服务注册与发现

Eureka的高可用需要依赖于它的心跳机制和自我保护机制

心跳检测机制

Eureka server和client之间每隔30秒会进行一次心跳通信，告诉server，client还活着 默认为30秒,可在client配置进行配置

eureka: 
  instance:
    #eureka客户端发送心跳给eureka服务器的时间间隔，表明它仍活着，默认30秒
    lease-renewal-interval-in-seconds: 5

自我保护机制

在某一些时候注册在Eureka的服务已经挂掉了，但是服务却还留在Eureka的服务列表的情况。 在Eureka图形界面会有一行红字,如下图

因为Eureka有自我保护机制,它在提醒你,实例列表可能存在不可用的实例

默认情况下，如果Eureka Server在一定时间内（默认90秒）没有接收到某个微服务实例的心跳，Eureka Server将会移除该实例。

但是,如果在15分钟内超过15%的客户端节点都没有正常的心跳，那么Eureka就认为客户端与注册中心出现了网络故障，而微服务本身是正常运行的，此时不应该移除这个微服务,这就是自我保护机制

这种保护状态实际上是考虑了client和server之间的心跳是因为网络问题，而非服务本身问题，不能简单的删除注册信息

自我保护机制时会出现以下几种情况：

1、Eureka Server不再从注册列表中移除因为长时间没收到心跳而应该过期的服务。 2、Eureka Server仍然能够接受新服务的注册和查询请求，但是不会被同步到其它节点上，保证当前节点依然可用。 3、当网络稳定时，当前Eureka Server新的注册信息会被同步到其它节点中

这里引出两个名词： Renews threshold：server期望在每分钟中收到的心跳次数 Renews (last min)：上一分钟内收到的心跳次数。

前文说到禁止注册server自己为client，不管server是否禁止，threshold初始值是1。client个数为n，threshold=1+2*n（此为禁止自注册的情况,这里的乘以2是因为默认每分钟发两次心跳）

如果是多个server，且开启了自注册，那么就和client一样，是对于其他的server来说就是client，client个数就得加上这个开启了自注册的server了

自注册:自注册指的是,当自身是Eureka Server时,向自己或别的Eureka Server进行注册 对应注解为register-with-eureka: true,默认为true,表示是否将自己向Eureka Server进行注册

现在开启两个Eureka Server(非自注册),1个个Eureka Client,这两个名词数据显示在Eureka图形界面右侧

threshold=1+2*1 renews = 2*1

当renews/threshold<0.85时,就会进入自我保护机制

这个保护机制有时会让人难以琢磨,解决建议是： 1、在生产上可以开自注册，部署多个server(这样做是为了增大renews) 2、简单粗暴把自我保护模式关闭(开发或测试环境,建议生产开启)

eureka:
  server:
    enable-self-preservation: false