EMERGENCY! EUREKA MAY BE INCORRECTLY CLAIMING INSTANCES ARE UP WHEN THEY'RE NOT. RENEWALS ARE LESSER

启动两个client，过了一会，停了其中一个，访问注册中心时，界面上显示了红色粗体警告信息：

查阅了很多资料，终于了解了中间的问题。现将理解整理如下：

Eureka server和client之间每隔30秒会进行一次心跳通信，告诉server，client还活着。由此引出两个名词：
Renews threshold：server期望在每分钟中收到的心跳次数
Renews (last min)：上一分钟内收到的心跳次数。

前文说到禁止注册server自己为client，不管server是否禁止，阈值（threshold）是1。client个数为n，阈值为1+2n（此为一个server且禁止自注册的情况）
如果是多个server，且开启了自注册，那么就和client一样，是对于其他的server来说就是client，是要2的

我开了两个server，自注册，相关数据如下
这里写图片描述
阈值：1+21
renews：
1）自注册 2 + 21
2）非自注册：2*1

Eurake有一个配置参数eureka.server.renewalPercentThreshold，定义了renews 和renews threshold的比值，默认值为0.85。当server在15分钟内，比值低于percent，即少了15%的微服务心跳，server会进入自我保护状态，Self-Preservation。在此状态下，server不会删除注册信息，这就有可能导致在调用微服务时，实际上服务并不存在。
这种保护状态实际上是考虑了client和server之间的心跳是因为网络问题，而非服务本身问题，不能简单的删除注册信息

stackoverflow上，有人给出的建议是：
1、在生产上可以开自注册，部署两个server
2、在本机器上测试的时候，可以把比值调低，比如0.49
3、或者简单粗暴把自我保护模式关闭

eureka.server.enableSelfPreservation=false

一、Eureka的自我保护模式
如果在Eureka Server的首页看到以下这段提示，则说明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.3
一般出现此模式时，服务返回错误。即如果真实的服务已经Down掉，但在注册中心界面服务却一直存在，且显示为UP状态。

产生原因：

    Eureka Server在运行期间，会统计心跳失败的比例在15分钟之内是否
低于85%，如果出现低于的情况（在单机调试的时候很容易满足，实际在
生产环境上通常是由于网
络不稳定导致），Eureka Server会将当前的实例注册信息保护起来，同时提
示这个警告。保护模式主要用于一组客户端和Eureka Server之间存在网络分
区场景下的保护。一旦进入保护模式，Eureka Server将会尝试保护其服务注
册表中的信息，不再删除服务注册表中的数据（也就是不会注销任何微服务）。
解决方法：

详情可见上一篇博客，就不在这边赘述了。
1
如何处理服务挂掉后或者手动关闭服务后，Ribbon负载均衡还是一直调用这个服务：

1.Hystrix,在fallback方法中shutdown指定的服务
2.让zuul只路由到活着的那个服务：
添加依赖：
  <dependency>
      <groupId>com.squareup.okhttp3</groupId>
      <artifactId>okhttp</artifactId>
      <version>3.6.0</version>
  </dependency>
配置文件：
ribbon.connectTimeout: 2000
ribbon.readTimeout: 10000
ribbon.maxAutoRetries: 1
ribbon.maxAutoRetriesNextServer: 2
ribbon.okToRetryOnAllOperations: true
ribbon.okhttp.enabled: true
3.重试机制（和上述一个道理）
spring.cloud.loadbalancer.retry.enabled=true
hystrix.command.default.execution.isolation.thread.timeoutInMilliseconds=10000
hello-service.ribbon.ConnectTimeout=250
hello-service.ribbon.ReadTimeout=1000
hello-service.ribbon.OkToRetryOnAllOperations=true
hello-service.ribbon.MaxAutoRetriesNextServer=2
hello-service.ribbon.MaxAutoRetries=1


spring.cloud.loadbalancer.retry.enabled：该参数用来开启重试机制，它默认是关闭的。这里需要注意，官方文档中的配置参数少了enabled
hystrix.command.default.execution.isolation.thread.timeoutInMilliseconds：断路器的超时时间需要大于ribbon的超时时间，不然不会触发重试。

hello-service.ribbon.ConnectTimeout：请求连接的超时时间

hello-service.ribbon.ReadTimeout：请求处理的超时时间

hello-service.ribbon.OkToRetryOnAllOperations：对所有操作请求都进行重试

hello-service.ribbon.MaxAutoRetriesNextServer：切换实例的重试次数

hello-service.ribbon.MaxAutoRetries：对当前实例的重试次数
二、指定Eureka的Environment
eureka.environment: 指定环境
1
三、指定Eureka的DataCenter
eureka.datacenter: 指定数据中心
--------------------- 
作者：陆鹏nic.lu 
来源：CSDN 
原文：https://blog.csdn.net/cvntopuyef/article/details/78477681 
版权声明：本文为博主原创文章，转载请附上博文链接！