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的哲学是，同时保留”好数据“与”坏数据“总比丢掉任何”好数据“要更好。

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

五、推荐阅读：

• 为什么不应该使用ZooKeeper做服务发现

---

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

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

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