eureka心跳_Eureka 使用的常见问题总结

一、服务注册慢的问题

在我们启动一个服务后，可能要过一分多钟才能被其他服务调用到，那么这种情况不管是开发/测试环境，亦或是生产环境都会影响效率。出现该问题的原因有以下几种：

Eureka Server缓存

Eureka Server的两级缓存策略，在ResponseCacheImpl类中有readWriteCacheMap读写缓存和readOnlyCacheMap只读缓存，readWriteCacheMap缓存周期为180秒，readOnlyCacheMap会周期更新，默认每30秒从readWriteCacheMap更新至readOnlyCacheMap，客户端请求时默认会先从readOnlyCacheMap获取数据，获取不到数据的情况下，会从readWriteCacheMap中获取，相关逻辑在ResponseCacheImpl中可以找到。

可以通过eureka.server.response-cache-update-interval-ms参数配置readOnlyCacheMap的更新频率(默认30秒)，也可以通过eureka.server.use-read-only-response-cache=false(默认为true)参数配置来禁用readOnlyCacheMap。

Eureka Client缓存

客户端会定期的从Eureka Server获取最新的服务注册信息，默认为30秒，通过eureka.client.registry-fetch-interval-seconds参数可以配置更新周期

Ribbon缓存

Ribbon的负载平衡器从本地的Eureka Client获取服务注册列表信息。Ribbon本身还维护本地缓存，以避免为每个请求调用本地客户端。 此缓存每30秒刷新一次，通过ribbon.ServerListRefreshInterval参数可以配置

所以终上所述，一个服务注册上线需要的最大时间为30(eureka.server.response-cache-update-interval-ms)+30(eureka.client.registry-fetch-interval-seconds)+30(ribbon.ServerListRefreshInterval)=90秒。

二、服务注销慢的问题

在服务停掉后，Eureka Server并不能快速的将已停止的服务实例剔除，对调用方而言，请求到已停止的服务实例上则会提示拒绝连接，出现该问题的原因有以下几种：

Eureka Server失效服务剔除

Eureka Server，默认每60秒会检测失效的服务，检测标准就是超过一定时间(默认90秒)没有renew续约的服务，也就是如果有服务超过90秒没有向Eureka Server发起Renew请求的话，就会被当做失效服务剔除掉。通过参数eureka.server.eviction-interval-timer-in-ms配置，单位为毫秒

Eureka Client周期心跳

Eureka Client需要定期向Eureka Server发送心跳已续约自已的租期，避免被Eureka Server剔除，默认为30秒。通过eureka.instance.lease-renewal-interval-in-seconds参数配置。此外参数eureka.instance.lease-expiration-duration-in-seconds表示Eureka服务器在接收到实例的最后一次发出的心跳后，需要等待多久才可以将此实例删除,默认90秒

三、服务注册/注销慢的解决方案

综合以上服务注册慢/注销慢的原因，我们的解决方案其实就是将上述的一些参数时间缩短。参考配置如下：

Eureka Server端配置

#关闭自我保护模式

eureka.server.enable-self-preservation=false

#Eureka Server清理无效节点的频率，单位:毫秒,默认60秒

eureka.server.eviction-interval-timer-in-ms=5000

#禁用readOnlyCacheMap

eureka.server.use-read-only-response-cache=false

Eureka Client端配置

#从eureka服务端获取配置

eureka.client.fetch-registry = true

#将自身的服务注册至eureka服务端

eureka.client.register-with-eureka = true

#通过IP注册

eureka.instance.prefer-ip-address = true

#指示从Eureka服务器获取注册表信息的频率(秒),默认30秒

eureka.client.registry-fetch-interval-seconds=5

#客户端向Eureka服务器发送心跳以续约自已的租期,默认30秒

eureka.instance.lease-renewal-interval-in-seconds=5

#Eureka服务器在接收到实例的最后一次发出的心跳后，需要等待多久才可以将此实例删除,默认90秒

eureka.instance.lease-expiration-duration-in-seconds=5

#Ribbon更新服务注册列表的频率

ribbon.ServerListRefreshInterval=2000

上述的配置只适用于中小型应用，需要注意的是，如果把请求Eureka Server的时间都调小的话(比如获取注册表、发送心跳等)，在系统服务实例的数量很大的情况下，那么会对Eureka Server造成压力。

四、关于自我保护机制

如果Eureka服务节点在短时间里丢失了大量客户端的心跳连接时，(注：可能发生了网络故障，有可能客户端实例还在正常运行)，那么这个Eureka节点会进入”自我保护模式“，同时保留那些“心跳死亡“的服务注册信息不过期。此时，这个Eureka节点对于新的服务还能提供注册服务，对于”死亡“的仍然保留，以防还有客户端向其发起请求。当网络故障恢复后，这个Eureka节点会退出”自我保护模式“。所以Eureka的哲学是，同时保留”好数据“与”坏数据“总比丢掉任何”好数据“要更好。

对于不存在跨区、跨网络机房的中小型应用而言，建议关闭自我保护模式。

五、推荐阅读：

如果文章对你有帮助的话，给文章点个赞吧。

如果有写得不正确的地方，欢迎指出。

文章首发公众号：会跳舞的机器人，欢迎扫码关注。