1、常见问题
- 1、为什么服务下线了,Eureka Server接口返回的信息还会存在?
- 2、为什么服务上线了,Eureka Client不能及时获取到?
- 3、为什么偶尔会有如下提示:
EMERGENCY! EUREKA MAY BE INCORRECTLY CLAIMING INSTANCES ARE UP WHEN THEY'RENOT. RENEWALS ARE LESSER THAN THRESHOLD AND HENCE THE INSTANCES ARE NOT BEING EXPIRED JUST TO BE SAFE
2、解决方法
- 针对第一个问题,Eureka Server并不是强一致的,因此registry中会存留已过期的实例信息,有一下几个原因:
- 1、应用实例异常挂掉,没能在挂掉之前告知Eureka Server要下线该服务实例信息。这种情况下就需要依赖Eureka Server的EvictionTask去剔除。
- 2、应用实例下线时有告知Eureka Server下线,但是由于Eureka Server的REST API有response cache,因此需要等待缓存过期才能更新。
- 3、Eureka Server由于开启并引入了SELF PRESERVATION模式,导致registry的信息不会因为过期而被剔除掉,直到退出SELF PRESERVATION模式。
- 针对第二个问题,可以调整EvictionTask的调度频率,比如下面的配置,将调度间隔默认的60秒,调整为15秒:
eureka.server.eviction-interval-timer-in-ms=5000
-
针对response cache的问题,可以根据情况考虑关闭readOnlyCacheMap:
eureka.server.use-read-only-response-cache=false
-
或者调整readWriteCacheMap的过期时间:
eureka.server.response-cache-auto-expiration-in-seconds=60
-
针对SELF PRESERVATION的问题,在测试环境可以将enable-self-preservation设置为false:
eureka.server.enable-self-preservation=false
-
关闭的话,则会提示:
RENEWALS ARE LESSER THAN THE THRESHOLD. THE SELF PRESERVATION MODE IS TURNED OFF. THIS MAY NOT PROTECT INSTANCE EXPIRY IN CASE OF NETWORK/OTHER PROBLEMS.
或者:
THE SELF PRESERVATION MODE IR TURED OFF.THIS MAY NOT PROTECT INSTANCE EXPIRY IN CASE OF NETWORK/OTHER PROBLEMS.
- 针对新服务上线,Eureka Client获取不及时的问题,在测试环境,可以适当提高Client端拉取Server注册信息的频率,例如下面将默认的30秒改为15秒:
eureka.client.registry-fetch-interval-seconds=5
- 针对SELF PRESERVATION问题,在实际生产过程中,经常会有网络抖动等问题,造成服务实例与Eureka Server的心跳未能如期保持,但是服务实例本身是健康的,这个时候如果按照租约机制剔除的话,会造成误判,如果大范围误判的话,可能会导致整个服务列表中的大部分注册信息被剔除,从而导致没有可用服务。Eureka为了解决这个问题引入可SELF PRESERVATION机制,当最近一分钟接受到的续约的次数小于等于指定阀值的话,则关闭续约失效剔除,禁止定时任务剔除失效的实例,从而保护注册信息,对于开发测试环境,开启这个机制有时候反而会影响系统的持续集成,因此可以通过如下参数关闭该机制:
eureka.server.enable-self-preservation=false
在生产环境中,可以把renewalPercentThreshold及leaseRenewalIntervalInSeconds参数调小一点,进而提高SELF PRESERVATION机制的门槛,比如:
eureka.instance.lease-renewal-interval-in-seconds=10
eureka.server.renewal-percent-threshold=0.49