七、Eureka服务消费者、提供者、注册中心的心跳机制

1、服务消提供者

在注册服务完成以后，服务提供者会维持一个心跳（定时向EurekaServer发起Rest请求），告诉注册中心”我还活着”，这个我们称为服务的续约（renew）.

有两个重要参数可以修改服务续约的行为：

eureka:
  instance: 
    lease-renewal-interval-in-seconds: 10
    lease-expiration-duration-in-seconds: 5

服务提供者会有如下配置属性，默认请默认情况下每隔30s服务提供者会向注册中心发送一次心跳，证明自己还活着。

lease-renewal-interval-in-seconds：服务续约（renew）的间隔，默认是30s，客户端告诉服务端自己会按照该规则。
lease-expiration-duration-in-seconds:服务失效时间，默认是90s，客户端告诉服务端按照此规则等待自己。

也就是说，默认情况下每隔30s服务提供者会向注册中心发送一次心跳，证明自己还活着，如果超过90s没有心跳，
EurekaServer就会认为该服务宕机，会从服务列表移除，这两个值再生成环境不要修改，默认即可。

2、服务消费者

当服务消费者启动时，消费者（比如zuul）配置文件中会有如下属性：

eureka:
  client:
    fetch-registry: true
    registry-fetch-interval-seconds: 5

fetch-registry：如果为true，则会从EurekaServer服务的列表只读备份，然后缓存在本地。并且每隔30秒会重新获取并更新数据，生成环境我们一般都不需要修改这个值，但是为了开发环境下能够快速得到服务的最新状态，我们可以设置小一点。

3、注册中心

1、失效剔除

有时候，我们的服务提供方并不一定会正常下线，可能因为内存溢出、网络故障导致服务器无法正常工作。EurekaServer需要将这样的服务剔除服务列表。因此它会开启一个定时任务，每隔60秒对所有失效的服务（超过90秒：由服务提供者告诉自己的规则）进行剔除。可以通过如下配置修改。

eureka:
  server:
  ##剔除失效服务间隔
    eviction-interval-timer-in-ms: 2000 #扫描失效服务的间隔时间（缺省是60*1000ms）

生产环境通常用默认60秒就可以了，但是开发环境因为需要经常重启，所以可以稍微修改下值，比如2秒。

2、自我保护

我们关停了一个服务，就会在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.

这是触发了Eureka的自我保护机制。当一个服务未按时进行心跳续约时，Eureka会统计最近15分钟心跳失败的服务比例是否超过85%。如果低于 85%，Eureka Server 会将这些实例保护起来，让这些实例不会过期，在生产环境下，因为网络延迟等原因，心跳失败的实例比例很可能超标，但此时就把服务剔除列表并不妥当，因为服务可能没有宕机。Eureka就会把当前实例的注册信息保护起来，不予剔除。生产环境这很有效，保证了大多数服务依然可用。

但是这个给我们开发带来了麻烦，因此在开发阶段我们都会关闭自我保护模式：

eureka:
  server:
    enable-self-preservation: false #关闭自我保护机制，缺省为打开

4、总结

经过测试发现，若不关闭服务自我保护机制，不管怎样设置心跳时间，失效时间也没有用，所以微服务千万不要强行kill来做下线,如何优雅的下线，可以参考：http://www.itmuch.com/spring-cloud-sum/how-to-unregister-service-in-eureka/ 。