Spring Cloud Eureka原理分析（三）：注册信息读取（服务端）

服务端的注册信息读取使用缓存，而非直接读取registry那个 ConcurrentHashMap 。缓存的主要逻辑都在 ResponseCacheImpl 这个类中。

缓存有两层，第一层是Guava的带生存时间的 LoadingCache ，称为 readWriteCacheMap ；第二层是一个 ConcurrentHashMap ，称为 readOnlyCacheMap 。

参见下面的示意图：

下面看一下图中两个重要的方法。

generatePayload(Key key)

此方法接受一个 Key 类型的参数，返回一个 Value 类型。 其中 Key 中重要的字段有：

• KeyType ，表示payload文本格式，有JSON和XML两种值。
• EntityType ，表示缓存的类型，有 Application , VIP , SVIP 三种值。
• entityName ，表示缓存的名称，可能是单个应用名，也可能是 ALL_APPS 或 ALL_APPS_DELTA 。

Value 则有一个 String 类型的payload和一个 byte 数组，表示gzip压缩后的字节。

generatePayload() 中根据 EntityType 和 EntityName ，会调用不同的方法获取regitry中的信息。

• registry.getApplications() : 得到所有的应用注册信息，结果为 Applications 对象。
• registry.getApplicationsDeltas() ：得到增量更新信息。
• registry.getApplication() ：得到单个应用信息。
• getApplicationsForVip ：就是先得到所有的应用注册信息，然后提取出 vipAddress 符合请求的应用信息。

vip和svip是什么

在Spring Cloud Eureka中，这两个设置变成了VirtualHostName和SecureVirtualHostName，应该是类似DNS名称。

invalidate(String appName, ...)

传入的为某个应用名，而实际上要让以下缓存失效：

• 应用的缓存
• ALL_APPS缓存
• ALL_APPS_DELTA缓存

定时刷新readOnlyCache任务

行为很简单，就是把readWriteMap拷贝到readOnlyMap（但只拷贝readOnlyCache中已有的key）。 任务执行频率由 eureka.server.responseCacheUpdateIntervalMs 控制，默认为30秒。

另外， eureka.server.useReadOnlyResponseCache 可以设置是否启用readOnlyCache，默认启用。

全量信息与增量信息

前文已述， generatePayload() 方法根据 entityName 是 ALL_APPS 或 ALL_APPS_DELTA 决定生成已注册的全量信息，还是增量信息。

全量信息

调用 registry.getApplications() ，最终就是从本地（也可能包含远程）的registry中读取所有注册信息，构造成 Applications 对象。

增量信息

在前两篇文章中，提到了registry的实现类有一个 AbstractInstanceRegistry.recentlyChangedQueue 队列，保存最近的租约变更记录。在注册、下线等操作时，会修改此队列。

另外，还有一个定时任务专门对超过一定时长的记录进行移除。定时任务的执行间隔由 eureka.server.deltaRetentionTimerIntervalInMs 控制；时长阈值由 eureka.server.retentionTimeInMSInDeltaQueue 控制。

客户端获取增量信息，与本地缓存合并后通服务端的全量信息比较哈希值（哈希算法有特别实现，主要根据注册应用内容）。如果哈希值不同，则增量获取失败，需要一次全量获取。