引言
Eureka 是 Netflix 开源的、用于实现服务注册和发现的服务。Spring Cloud Eureka 基于 Eureka 进行二次封装，增加了更人性化的 UI，使用更为方便。但是由于 Eureka 本身存在较多缓存，服务状态更新滞后，最常见的状况是：服务下线后状态没有及时更新，服务消费者调用到已下线的服务导致请求失败。本文基于 Spring Cloud Eureka 1.4.4.RELEASE，在默认 region 和 zone 的前提下，介绍 Eureka 的缓存机制。
一、AP 特性
从 CAP 理论看，Eureka 是一个 AP 系统，优先保证可用性 (A) 和分区容错性(P)，不保证强一致性(C)，只保证最终一致性，因此在架构中设计了较多缓存。
二、服务状态
Eureka 服务状态 enum 类：com.netflix.appinfo.InstanceInfo.InstanceStatus
| 状态 | 说明 | 状态 | 说明 |
|---|---|---|---|
| UP | 在线 | OUT_OF_SERVICE | 失效 |
| DOWN | 下线 | UNKNOWN | 未知 |
| STARTING | 正在启动 |
三、Eureka Server
在 Eureka 高可用架构中，Eureka Server 也可以作为 Client 向其他 server 注册，多节点相互注册组成 Eureka 集群，集群间相互视为 peer。Eureka Client 向 Server 注册、续约、更新状态时，接受节点更新自己的服务注册信息后，逐个同步至其他 peer 节点。
【注意】如果 server- A 向 server- B 节点单向注册，则 server- A 视 server- B 为 peer 节点，server- A 接受的数据会同步给 server-B，但 server- B 接受的数据不会同步给 server-A。
3.1 缓存机制
Eureka Server 存在三个变量：(registry、readWriteCacheMap、readOnlyCacheMap)保存服务注册信息，默认情况下定时任务每 30s 将 readWriteCacheMap 同步至 readOnlyCacheMap，每 60s 清理超过 90s 未续约的节点，Eureka Client 每 30s 从 readOnlyCacheMap 更新服务注册信息，而 UI 则从 registry 更新服务注册信息。
三级缓存
| 缓存 | 类型 | 说明 |
|---|---|---|
| registry | ConcurrentHashMap | 实时更新，类 AbstractInstanceRegistry 成员变量，UI 端请求的是这里的服务注册信息 |
| readWriteCacheMap | Guava Cache/LoadingCache | 实时更新，类 ResponseCacheImpl 成员变量，缓存时间 180 秒 |
| readOnlyCacheMap | ConcurrentHashMap | 周期更新 ，类 ResponseCacheImpl 成员变量，默认每30s 从 readWriteCacheMap 更新，Eureka client 默认从这里更新服务注册信息，可配置直接从 readWriteCacheMap 更新 |
缓存相关配置
| 配置 | 默认 | 说明 |
|---|---|---|
eureka.server.useReadOnlyResponseCache |
true | Client 从 readOnlyCacheMap 更新数据，false 则跳过 readOnlyCacheMap 直接从 readWriteCacheMap 更新 |
eureka.server.responsecCacheUpdateIntervalMs |
30000 | readWriteCacheMap 更新至 readOnlyCacheMap 周期，默认30s |
eureka.server.evictionIntervalTimerInMs |
60000 | 清理未续约节点 (evict) 周期，默认60s |
eureka.instance.leaseExpirationDurationInSeconds |
90 | 清理未续约节点超时时间，默认90s |
关键类
| 类名 | 说明 |
|---|---|
com.netflix.eureka.registry.AbstractInstanceRegistry |
保存服务注册信息，持有 registry 和 responseCache 成员变量 |
com.netflix.eureka.registry.ResponseCacheImpl |
持有 readWriteCacheMap 和 readOnlyCacheMap 成员变量 |
四、Eureka Client
Eureka Client 存在两种角色：服务提供者 和服务消费者，作为服务消费者一般配合 Ribbon 或 Feign（Feign 内部使用 Ribbon）使用。Eureka Client 启动后，作为服务提供者立即向 Server 注册，默认情况下每 30s 续约(renew)；作为服务消费者立即向 Server 全量更新服务注册信息，默认情况下每 30s 增量更新服务注册信息；Ribbon 延时 1s 向 Client 获取使用的服务注册信息，默认每 30s 更新使用的服务注册信息，只保存状态为 UP 的服务。
二级缓存
| 缓存 | 类型 | 说明 |
|---|---|---|
| localRegionApps | AtomicReference | 周期更新 ，类 DiscoveryClient 成员变量，Eureka Client 保存服务注册信息，启动后立即向 Server 全量更新，默认每30s 增量更新 |
| upServerListZoneMap | ConcurrentHashMap | 周期更新 ，类 LoadBalancerStats 成员变量，Ribbon 保存使用且状态为UP 的服务注册信息，启动后延时 1s 向 Client 更新，默认每 30s 更新 |
缓存相关配置
| 配置 | 默认 | 说明 |
|---|---|---|
eureka.instance.leaseRenewalIntervalInSeconds |
30 | Eureka Client 续约周期，默认30s |
eureka.client.registryFetchIntervalSeconds |
30 | Eureka Client 增量更新周期，默认30s（正常情况下增量更新，超时或与 Server 端不一致等情况则全量更新） |
ribbon.ServerListRefreshInterval |
30000 | Ribbon 更新周期，默认30s |
关键类
| 类名 | 说明 |
|---|---|
com.netflix.discovery.DiscoveryClient |
Eureka Client 负责注册、续约和更新，方法 initScheduledTasks()分别初始化续约和更新定时任务 |
com.netflix.loadbalancer.PollingServerListUpdater |
Ribbon 更新使用的服务注册信息，start 初始化更新定时任务 |
com.netflix.loadbalancer.LoadBalancerStats |
Ribbon，保存使用且状态为 UP 的服务注册信息 |
五、默认配置下服务消费者最长感知时间
| Eureka Client | 时间 | 说明 |
|---|---|---|
| 上线 | 30(readOnly)+30(Client)+30(Ribbon)=90s | readWrite -> readOnly -> Client -> Ribbon 各 30s |
| 正常下线 | 30(readonly)+30(Client)+30(Ribbon)=90s | 服务正常下线（kill 或 kill -15 杀死进程）会给进程善后机会，DiscoveryClient.shutdown()将向 Server 更新自身状态为 DOWN，然后发送 DELETE 请求注销自己，registry 和 readWriteCacheMap 实时更新，故 UI 将不再显示该服务实例 |
| 非正常下线 | 30+60(evict)*2+30+30+30= 240s | 服务非正常下线（kill - 9 杀死进程或进程崩溃）不会触发 DiscoveryClient.shutdown()方法，Eureka Server 将依赖每 60s 清理超过 90s 未续约服务从 registry 和 readWriteCacheMap 中删除该服务实例 |
考虑如下情况
- 0s 时服务未通知 Eureka Client 直接下线；
- 29s 时第一次过期检查 evict 未超过 90s；
- 89s 时第二次过期检查 evict 未超过 90s；
- 149s 时第三次过期检查 evict 未续约时间超过了 90s，故将该服务实例从 registry 和 readWriteCacheMap 中删除；
- 179s 时定时任务从 readWriteCacheMap 更新至 readOnlyCacheMap;
- 209s 时 Eureka Client 从 Eureka Server 的 readOnlyCacheMap 更新；
- 239s 时 Ribbon 从 Eureka Client 更新。
因此，极限情况下服务消费者最长感知时间将无限趋近 240s。
六、应对措施
服务注册中心在选择使用 Eureka 时说明已经接受了其优先保证可用性 (A) 和分区容错性 (P)、不保证强一致性(C) 的特点。如果需要优先保证强一致性(C)，则应该考虑使用 ZooKeeper 等 CP 系统作为服务注册中心。分布式系统中一般配置多节点，单个节点服务上线的状态更新滞后并没有什么影响，这里主要考虑服务下线后状态更新滞后的应对措施。
6.1 Eureka Server
-
1.缩短 readOnlyCacheMap 更新周期。缩短该定时任务周期可减少滞后时间。
eureka.server.responsecCacheUpdateIntervalMs: 10000 # Eureka Server readOnlyCacheMap 更新周期 -
2.关闭 readOnlyCacheMap。中小型系统可以考虑该方案，Eureka Client 直接从 readWriteCacheMap 更新服务注册信息。
eureka.server.useReadOnlyResponseCache: false # 是否使用 readOnlyCacheMap
6.2 Eureka Client
- 1.服务消费者使用容错机制。如 Spring Cloud Retry 和 Hystrix，Ribbon、Feign、Zuul 都可以配置 Retry，服务消费者访问某个已下线节点时一般报 ConnectTimeout，这时可以通过 Retry 机制重试下一个节点。
-
2.服务消费者缩短更新周期。Eureka Client 和 Ribbon 二级缓存影响状态更新，缩短这两个定时任务周期可减少滞后时间，例如配置：
eureka.client.registryFetchIntervalSeconds: 5 # Eureka Client 更新周期 ribbon.ServerListRefreshInterval: 2000 # Ribbon 更新周期 - 3.服务提供者保证服务正常下线 。服务下线时使用 kill 或 kill -15 命令，避免使用 kill - 9 命令，kill 或 kill -15 命令杀死进程时将触发 Eureka Client 的 shutdown() 方法，主动删除 Server 的 registry 和 readWriteCacheMap 中的注册信息，不必依赖 Server 的 evict 清除。
- 4.服务提供者延迟下线。服务下线之前先调用接口使 Eureka Server 中保存的服务状态为 DOWN 或 OUT_OF_SERVICE 后再下线，二者时间差根据缓存机制和配置决定，比如默认情况下调用接口后延迟 90s 再下线服务即可保证服务消费者不会调用已下线服务实例。
七、网关实现服务下线实时感知
在软件工程中，没有一个问题是中间层解决不了的，而网关是服务提供者和服务消费者的中间层。以 Spring Cloud Zuul 网关为例，网关作为 Eureka Client 保存了服务注册信息，服务消费者通过网关将请求转发给服务提供者，只需要做到服务提供者下线时通知网关在自己保存的服务列表中使该服务失效。为了保持网关的独立性，可实现一个独立服务接收下线通知并协调网关集群。下篇文章将详细介绍网关如何实现服务下线实时感知，敬请期待！
作者：冯永彪
内容来源：宜信技术学院