之前我们看过这个整体流程图：
接下来我们来仔细分析下这个流程，先不涉及源代码，只说流程
服务提供者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
