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.responseCacheUpdateInvervalMs

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