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高可用架构)

二、服务状态

Eureka服务状态enum类：

com.netflix.appinfo.InstanceInfo.InstanceStatus 

三、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。

1. 缓存机制

Eureka Server存在三个变量：(registry、readWriteCacheMap、readOnlyCacheMap)保存服务注册信息，默认情况下定时任务每30s将readWriteCacheMap同步至readOnlyCacheMap，每60s清理超过90s未续约的节点，Eureka Client每30s从readOnlyCacheMap更新服务注册信息，而UI则从registry更新服务注册信息。

三级缓存：

缓存相关配置：

关键类：

四、Eureka Client

Eureka Client存在两种角色：服务提供者和服务消费者，作为服务消费者一般配合Ribbon或Feign(Feign内部使用Ribbon)使用。Eureka Client启动后，作为服务提供者立即向Server注册，默认情况下每30s续约(renew);作为服务消费者立即向Server全量更新服务注册信息，默认情况下每30s增量更新服务注册信息;Ribbon延时1s向Client获取使用的服务注册信息，默认每30s更新使用的服务注册信息，只保存状态为UP的服务。

二级缓存：

缓存相关配置：

关键类：

五、默认配置下服务消费者最长感知时间

考虑如下情况：

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系统作为服务注册中心。分布式系统中一般配置多节点，单个节点服务上线的状态更新滞后并没有什么影响，这里主要考虑服务下线后状态更新滞后的应对措施。

1. Eureka Server

缩短readOnlyCacheMap更新周期。缩短该定时任务周期可减少滞后时间。

eureka.server.responsecCacheUpdateIntervalMs: 10000  # Eureka Server readOnlyCacheMap更新周期 

关闭readOnlyCacheMap。中小型系统可以考虑该方案，Eureka Client直接从readWriteCacheMap更新服务注册信息。

eureka.server.useReadOnlyResponseCache: false        # 是否使用readOnlyCacheMap 

2. Eureka Client

服务消费者使用容错机制。如Spring Cloud Retry和Hystrix，Ribbon、Feign、Zuul都可以配置Retry，服务消费者访问某个已下线节点时一般报ConnectTimeout，这时可以通过Retry机制重试下一个节点。

服务消费者缩短更新周期。Eureka Client和Ribbon二级缓存影响状态更新，缩短这两个定时任务周期可减少滞后时间，例如配置：

eureka.client.registryFetchIntervalSeconds: 5        # Eureka Client更新周期 

ribbon.ServerListRefreshInterval: 2000   

服务提供者保证服务正常下线。服务下线时使用kill或kill -15命令，避免使用kill -9命令，kill或kill -15命令杀死进程时将触发Eureka Client的shutdown()方法，主动删除Server的registry和readWriteCacheMap中的注册信息，不必依赖Server的evict清除。

服务提供者延迟下线。服务下线之前先调用接口使Eureka Server中保存的服务状态为DOWN或OUT_OF_SERVICE后再下线，二者时间差根据缓存机制和配置决定，比如默认情况下调用接口后延迟90s再下线服务即可保证服务消费者不会调用已下线服务实例。

七、网关实现服务下线实时感知

在软件工程中，没有一个问题是中间层解决不了的，而网关是服务提供者和服务消费者的中间层。以Spring Cloud Zuul网关为例，网关作为Eureka Client保存了服务注册信息，服务消费者通过网关将请求转发给服务提供者，只需要做到服务提供者下线时通知网关在自己保存的服务列表中使该服务失效。为了保持网关的独立性，可实现一个独立服务接收下线通知并协调网关集群。

【本文是51CTO专栏机构宜信技术学院的原创文章，微信公众号“宜信技术学院( id: CE_TECH)”】

戳这里，看该作者更多好文

【编辑推荐】

系统性能提升优先法宝 | 缓存应用实践

Spring Cloud 终于按捺不住推出了自己的服务网关 Gateway

没想到，我们的分布式缓存竟这样把注册中心搞垮！

基于OpenResty的单机10万TPS网关在物流业务中的应用

宜人贷蜂巢API网关技术解密之Netty使用实践