Eureka的自我保护与健康检查机制

Eureka的自我保护

Eureka的自我保护是默认开启的如果需要关闭需要加上相关的配置。

#YAML配置
eureka:
  server: 
    evictionIntervalTimerInMs: 30000 #每间隔30秒剔除一次下线的服务
    enableSelfPreservation: false #关闭Eureka的自我保护

Eureka的自我保护机制其实是为了在网络状况不稳定的情况下仍然能在一段时间内保存服务的地址信息，防止微服务因网络原因频繁被剔除和注册，出现短时间内频繁修改注册信息的问题，也防止Eureka对服务状态的误判。当Eureka进入自我保护状态时，Eureka页面会出现红色的提示标语。

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.

实际上，我们大部分情况下会注意到这个服务明明停掉了，为什么状态还会是UP？网上大部分都是一笔带过，都是粗暴的剔除下线服务，就是上面提到的直接关闭自我保护。在微服务本地的配置里配合Eureka加上这个：

eureka:
  instance:
    # 每间隔30s，向服务端发送一次心跳，证明自己依然"存活"
    lease-renewal-interval-in-seconds: 15
    # 告诉服务端，如果我60s之内没有给你发心跳，就代表我"死"了，将我踢出掉。
    lease-expiration-duration-in-seconds: 30

的确解决了不会再轮训到下线的服务了，可我就是想见见Eureka服务状态里面的DOWN、OUT_OF_SERVICE、UNKNOWN的这些状态值。那么这个健康状态对于Eureka来说谁健康与否的判决别人说的不算，自家人知道自家事，就统一交给微服务自己解决，真的是好有道理。

Eureka的健康检查

客户端需要在工程中添加组件依赖:

<dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-actuator</artifactId>
    <version>1.5.14.RELEASE</version>
</dependency>

然后在配置文件里面加上健康状态检查配置:

eureka:
  client:
    healthcheck:
      enabled: true

这时，启动自己的服务，通过http://localhost:port/health访问就可以得到服务的健康状态信息：

{"description":"Composite Discovery Client","status":"UP"}

当这个配置设置为false时，服务将不会把健康状态传递给Eureka，那么Eureka就不会再更新Status信息，但是此时仍能够通过上面的地址获取这个真实的状态信息。

这个信息是怎么来的呢？
当直接增加配置启动项目时，项目启动会报找不到HealthAggregator类的错误，那么可以确定Eureka的服务的健康信息是由这个类来生成的，在根据配置的eureka.client.healthcheck.enabled在代码中查找，可以找到一个注解:

@ConditionalOnProperty(value = "eureka.client.healthcheck.enabled", matchIfMissing = false)

，默认情况下，健康状态检查接口是关闭的，当关闭时对EurekaHealthCheckHandler这个Bean的创建没有关系，/health这个url仍然能够访问服务，返回状态为UP的JSON字符串。
被注解这个类是一个内部类：

@Configuration
@ConditionalOnProperty(value = "eureka.client.healthcheck.enabled", matchIfMissing = false)
protected static class EurekaHealthCheckHandlerConfiguration {

    @Autowired(required = false)
    private HealthAggregator healthAggregator
        = new OrderedHealthAggregator();

    @Bean
    @ConditionalOnMissingBean(HealthCheckHandler.class)
    public EurekaHealthCheckHandler eurekaHealthCheckHandler() {
        return new EurekaHealthCheckHandler(this.healthAggregator);
    }
}

可以看出当用户自己没有创建HealthCheckHandler这个Bean时，会自己创建一个默认的健康状态检查的类，那么Eureka注册中心就是通过客户端的/health来获取服务的健康状态的，也就是说只有在微服务自己实现了HealthCheckHandler这个接口并且创建Bean之后，Eureka中status状态才会有变化。这个可以通过下面这个类得到印证：

org.springframework.boot.actuate.health.Status

这个类中定义了服务状态的UNKNOWN,UP,DOWN,OUT_OF_SERVICE这四个状态，Eureka中的Status显示的四个状态刚好可以对上。

总结

这两个应该是相互配合使用的。
1）Eureka的自我保护是对微服务实例的地址信息进行保护，避免因一些意外情况将正常节点直接剔除。

2）实例的健康检查则是微服务与Eureka注册中心交互正常的情况下，微服务因自己内部原因无法正常对外提供服务，主动告诉注册中心自己出了问题，让注册中心别发新的请求过来。

Eureka使用中，两种方式无论哪一种单独使用都有其局限性，所以在正常生产环境下，肯定需要自己针对业务场景调整配置参数来实现服务的高可用。