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 + 2
1
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 
版权声明:本文为博主原创文章,转载请附上博文链接!
©️2020 CSDN 皮肤主题: 像素格子 设计师:CSDN官方博客 返回首页