Spring Cloud Eureka 全解 （2） - 整体流程篇

本文基于SpringCloud-Dalston.SR5

之前我们看过这个整体流程图：

接下来我们来仔细分析下这个流程，先不涉及源代码，只说流程

服务提供者EurekaClient -> EurekaServer

每个服务会生成自己的InstanceInfo：

除了这些，还有两个比较重要的配置

服务过期时间配置：eureka.instance.lease-expiration-duration-in-seconds

服务刷新时间配置：eureka.instance.lease-renewal-interval-in-seconds

EurekaServer会根据服务过期时间清理过期实例，同时会定时调用renew接口维持心跳，这个心跳周期由服务刷新时间配置决定。

同时，在实例初始化之后，服务提供者通过register接口注册实例。每隔服务信息更新时间检查本地信息是否过期，如果过期通过register接口更新InstanceInfo

服务信息更新时间配置（一般不配置，因为实例信息基本不会更新）：eureka.client.instance-info-replication-interval-seconds

EurekaServer内部缓存

服务实例注册，会放入registry这个ConcurrentHashMap中：

 private final ConcurrentHashMap<String, Map<String, Lease<InstanceInfo>>> registry
            = new ConcurrentHashMap<String, Map<String, Lease<InstanceInfo>>>();

其实就是把客户端生成的InstanceInfo放入这个registry的Map中。但是在服务消费者EurekaClient端获取所有服务与实例列表，并不是直接读取这个registry，而是从ResponseCache中获取。

ResponseCache包括两部分：ReadWriteMap和ReadOnlyMap；ReadWriteMap
就是一个Guava的LoadingCache。
在EurekaServer端，所有的读取请求都是读的ReadOnlyMap（这个可以配置），如果不存在则读取ReadWriteMap，如果不存在就从Registry拉取（LoadingCache的机制），实例信息更新会主动失效ReadWriteMap触发从Registry拉取。 ReadWriteMap比Registry多了两个key（ALL_APP还有ALL_APP_DELTA）

有定时任务会定时从ReadWriteMap同步到ReadOnlyMap这个时间配置是：eureka server刷新readCacheMap的时间，注意，client读取的是readCacheMap，这个时间决定了多久会把readWriteCacheMap的缓存更新到readCacheMap上

eureka server刷新readCacheMap的时间配置：eureka.server.responseCacheUpdateIntervalMs

ReadWriteMap是一个LoadingCache，将Registry中的服务实例信息封装成要返回的http响应（分别是经过gzip压缩和非压缩的），同时还有两个特殊key，ALL_APPS和ALL_APPS_DELTA
ALL_APPS就是所有服务实例信息
ALL_APPS_DELTA就是所有服务实例增量信息

这里面其中的内容，我们先不考虑；

EurekaServer内部有定时任务，每隔检查过期实例时间，扫描Registry里面过期的实例并删除，并且使对应的ReadWriteMap缓存失效：

检查过期实例时间配置：eureka.server.eviction-interval-timer-in-ms

EurekaServer -> 服务消费者EurekaClient

每隔增量获取服务列表时间配置向EurekaServer请求一次增量服务实例列表集合

增量获取服务列表时间配置：eureka.client.registryFetchIntervalSeconds

同时，SpringCloud环境下服务消费者调用一般用Ribbon做负载均衡，从Eureka所有服务所有实例缓存到Ribbon某个服务所有实例缓存，也是有定时任务，每隔Ribbon服务实例列表刷新时间同步

Ribbon服务实例列表刷新时间配置：ribbon.ServerListRefreshInterval