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