背景

默认的Spring Eureka服务器，服务提供者和服务调用者配置不够灵敏，总是服务提供者在停掉很久之后，服务调用者很长时间并没有感知到变化。或者是服务已经注册上去了，但是服务调用方很长时间还是调用不到，发现不了这个服务。

源码解读

通过对Spring Eureka源码的研究，发现如下机制（默认配置下）：

描述如下：

1. EurekaServer默认有两个缓存，一个是ReadWriteMap，另一个是ReadOnlyMap。有服务提供者注册服务或者维持心跳时时，会修改ReadWriteMap。当有服务调用者查询服务实例列表时，默认会从ReadOnlyMap读取（这个在原生Eureka可以配置，SpringCloud Eureka中不能配置，一定会启用ReadOnlyMap读取），这样可以减少ReadWriteMap读写锁的争用，增大吞吐量。EurekaServer定时把数据从ReadWriteMap更新到ReadOnlyMap中。
   ReadWriteMap是一个Guava Cache，过期时间是可以配置的。
2. 服务提供者注册服务后，会定时心跳。这个根据服务提供者的Eureka配置中的服务刷新时间决定。还有个配置是服务过期时间，这个配置在服务提供者配置但是在EurekaServer使用了，但是默认配置EurekaServer不会启用这个字段。需要配置好EurekaServer的扫描失效时间，才会启用EurekaServer的主动失效机制。在这个机制启用下：每个服务提供者会发送自己服务过期时间上去，EurekaServer会定时检查每个服务过期时间和上次心跳时间，如果在过期时间内没有收到过任何一次心跳，同时没有处于保护模式下（参考第一篇的Eureka自我保护机制），则会将这个实例从ReadWriteMap中去掉。
3. 在默认没有启用EurekaServer主动失效服务实例的情况下，服务过期是利用ReadWriteMap超时缓存失效实现的，只有发送心跳的实例缓存不会失效。
4. 服务调用者有本地缓存，定时从Eureka服务器上增量拉取所有服务实例列表

原因分析

服务提供者和服务调用者配置不够灵敏，总是服务提供者在停掉很久之后，服务调用者很长时间并没有感知到变化的原因：

服务已经注册上去了，但是服务调用方很长时间还是调用不到，发现不了这个服务：

解决方案

EurekaServer修改如下配置：

1
2
3
4
5
6
7
8
9
10
#eureka server刷新readCacheMap的时间，注意，client读取的是readCacheMap，这个时间决定了多久会把readWriteCacheMap的缓存更新到readCacheMap上
#默认30s
eureka.server.responseCacheUpdateIntervalMs=3000
#eureka server缓存readWriteCacheMap失效时间，这个只有在这个时间过去后缓存才会失效，失效前不会更新，过期后从registry重新读取注册服务信息，registry是一个ConcurrentHashMap。
#由于启用了evict其实就用不太上改这个配置了
#默认180s
eureka.server.responseCacheAutoExpirationInSeconds=180
#启用主动失效，并且每次主动失效检测间隔为3s
eureka.server.eviction-interval-timer-in-ms=3000

Eureka服务提供方修改如下配置：

1
2
3
4
5
6
7
8
#服务过期时间配置,超过这个时间没有接收到心跳EurekaServer就会将这个实例剔除
#注意，EurekaServer一定要设置eureka.server.eviction-interval-timer-in-ms否则这个配置无效，这个配置一般为服务刷新时间配置的三倍
#默认90s
eureka.instance.lease-expiration-duration-in-seconds=15
#服务刷新时间配置，每隔这个时间会主动心跳一次
#默认30s
eureka.instance.lease-renewal-interval-in-seconds=5

Eureka服务调用方修改如下配置：

1
2
3
4
5
6
7
#eureka client刷新本地缓存时间
#默认30s
eureka.client.registryFetchIntervalSeconds=5
#eureka客户端ribbon刷新时间
#默认30s
ribbon.ServerListRefreshInterval=5000

最后

以上就是细心衬衫最近收集整理的关于spring eureka 服务实例实现快速下线快速感知快速刷新配置解析背景源码解读原因分析解决方案的全部内容，更多相关spring内容请搜索靠谱客的其他文章。