Eureka 客户端已经成功下线，为什么还会有请求流入？

在微服务内部互相调用时，你是否遇到过，服务明明已经成功下线，在 Eureka UI 界面也看到服务注销了，但还是会有请求流入到下线的服务，短时间内出现服务调用失败。

通过下面这张图来解释下为什么会出现上述问题。

为了保证高可用和高性能，Eureka Server 中设计了三级缓存。

• registry 缓存，新注册的服务信息会保存到 registry 对象中；
• readWriteCacheMap 会实时同步 registry 对象中的数据；
• readOnlyCacheMap 默认每 30 秒去同步一次 readWriterCacheMap 对象中的数据；

在 Eureka UI 页面看到的信息避开了响应缓存 readOnlyCacheMap，直接从 registry 对象获取的，所以我们能够在 Eureka UI 页面实时的看到注册的新服务。

但是 Eureka Client 拉取的数据是从响应缓存 readOnlyCacheMap 中获取到的，这个数据不是实时拉取的，而是默认每 30 秒更新一次，所以就会出现 UI 页面看到服务已经注册好了，但是调用时却出现没有有效服务的错误。

服务下线也存在同样的问题，服务已经下线了，但是还是有客户端在调用已经下线的服务，这时就会出现连接拒绝的错误。

Spring Cloud 通过负载均衡器 Ribbon 从 Eureka Client 中获取被调用服务实例的信息，然后通过获取到的实例来调用对应的服务，Ribbon 从 Eureka Client 中获取到的服务列表也不是实时的，默认 30s 更新一次。

我们来计算下一个服务成功下线后，极端情况下多久才能被客户端感知到。

16:20:14 readOnlyCacheMap 同步 readWriteCacheMap 最新注册列表
16:20:15 服务成功下线，更新 registry 注册列表
16:20:43 Eureka Client 从 readOnlyCacheMap 拉取一次注册列表
16:20:44 readOnlyCacheMap 同步 readWriteCacheMap 最新注册列表，此时会感知到下线的服务
16:21:12 Ribbon 从 Eureka Client 中拉取注册列表
16:21:13 Eureka Client 从 readOnlyCacheMap 拉取一次注册列表，此时 Client 感知到下线的服务
16:21:42 Ribbon 从 Eureka Client 中拉取注册列表，此时 Ribbon 感知到下线的服务

极端情况，在服务下线后的 90s 内，流入的请求都会调用失败。这是在服务 graceful shutdown 的前提下，如果服务异常终止或者被 kill -9 强制杀死，这个时间会更长。

在非 graceful shutdown 情况下，客户端不会调用 Eureka API 来更新 registry 注册列表，而是只能等 Eureka Server 的 evict 线程定时清理无效节点，这个周期默认是 60s，客户端默认的续约超时时间是 90s。

续约周期是 30s，在连续 3 次丢失心跳后会被 Eureka Server 的 evict 线程清理，也就是说服务下线后，可能需要延迟 180s 之后，Eureka Server 中的 registry 对象才会被更新。

总的加起来，在非 graceful shutdown 情况下，Ribbon 中的缓存需要 4 分钟左右才会感知到下线的服务，这个情况在生产环境将是非常严重的。我们可以通过参数的调优来缩短这个时间：

1. 缩短 Eureka Server 多层缓存同步的周期
2. 缩短服务消费者 Client 拉取服务列表的周期
3. 保证服务是以 graceful shutdown 方式销毁的

下面是服务端和客户端参数的默认值。

• eureka-server 端

# 开启响应缓存
use-read-only-response-cache: true

# readOnlyCacheMap 从 readWriterCacheMap 同步数据的时间间隔
eureka.server.response-cache-update-interval-ms = 30000

# eureka server 清理无效节点的时间间隔
eureka.server.eviction-interval-timer-in-ms = 60

• eureka-client 端

# 客户端续约的频率
eureka.instance.lease-renewal-interval-in-seconds = 30

# 续约超时时间
eureka.instance.lease-expiration-duration-in-seconds = 90

# 客户端拉取服务列表周期
eureka.client.registry-fetch-interval-seconds = 30

Eureka Server 维护了一个最近注销实例的 CircularQueue 循环队列：recentCanceledQueue，和最近注册实例的 CircularQueue 循环队列：recentRegisteredQueue，容量均为 1000，可以在 UI 界面展示：

private final CircularQueue<Pair<Long, String>> recentRegisteredQueue;
private final CircularQueue<Pair<Long, String>> recentCanceledQueue;

~ END ~。