Spring Cloud 源码分析之 Eureka 篇第五章:更新服务列表
欢迎访问我的 GitHub
这里分类和汇总了欣宸的全部原创(含配套源码):https://github.com/zq2599/blog_demos
在上一章《Spring Cloud源码分析之Eureka篇第四章:服务注册是如何发起的 》,我们知道了作为 Eureka Client 的应用启动时,在 com.netflix.discovery.DiscoveryClient 类的 initScheduledTasks 方法中,会做以下几件事:
周期性更新服务列表;
周期性服务续约;
服务注册逻辑;
本章学习的是周期性更新服务列表的相关代码,也就是定期获取所有注册到 Eureka server 上的应用的信息
概览
以下图片来自Netflix官方,图中显示 Eureka Client 会向注册中心发起 Get Registry 请求来获取服务列表,接下来就去看下对应的代码实现;
结论提前知晓
看源码易犯困,又难保持注意力集中,因此先抛结论吧,这样不看源码也有收获:
Eureka client 从注册中心更新服务列表,然后自身会做缓存;
作为服务消费者,就是从这些缓存信息中获取的服务提供者的信息;
增量更新的服务以 30 秒为周期循环调用;
增量更新数据在服务端保存时间为 3 分钟,因此 Eureka client 取得的数据虽然被称为"增量更新",仍然可能和 30 秒前取的数据一样,所以 Eureka client 要自己来处理重复信息;
由 3、4 两点可以推断出,Eureka client 的增量更新,其实获取的是 Eureka server 最近三分钟内的变更,因此,如果 Eureka client 有超过三分钟没有做增量更新的话(例如网络问题),那么再调用增量更新接口时,那三分钟内 Eureka server 的变更就可能获取不到了,这就造成了 Eureka server 和 Eureka client 之间的数据不一致,需要有个方案来及时发现这个问题;
正常情况下,Eureka client 多次增量更新后,最终的服务列表数据应该 Eureka server 保持一致,但如果期间发生异常,可能导致和 Eureka server 的数据不一致,为了暴露这个问题,Eureka server 每次返回的增量更新数据中,会带有一致性哈希码,Eureka client 用本地服务列表数据算出的一致性哈希码应该和 Eureka server 返回的一致,若不一致就证明增量更新出了问题导致 Eureka client 和 Eureka server 上的服务列表信息不一致了,此时需要全量更新;
Eureka server 上的服务列表信息对外提供 JSON/XML 两种格式下载;
Eureka client 使用 jersey 的 SDK,去下载 JSON 格式的服务列表信息;
关于源码版本
本次分析的 Spring Cloud 版本为 Edgware.RELEASE,对应的 eureka-client 版本为 1.7.0;
如何做到周期性执行
更新服务列表和服务续约都是周期性循环执行的,这是如何实现的呢,来看 initScheduledTasks 方法的源码:
如上图两个红框中所示,scheduler.schedule 方法其实启动的是一个延时执行的一次性任务,不过 TimedSupervisorTask 内有乾坤,会在每次执行完任务后再启动一个同样的任务,这样就能实现周期性执行任务了,并且 TimedSupervisorTask 的功能还不止如此,它还负责任务超时、动态调节周期性间隔、线程池满、未知异常等各种情况的处理,推荐您参考《Eureka的TimedSupervisorTask类(自动调节间隔的周期性任务)》了解更多细节;
来自官方文档的指导信息
最准确的说明信息来自 Netflix 的官方文档,地址:https://github.com/Netflix/eureka/wiki/Understanding-eureka-client-server-communication#fetch-registry
学习源码之前先看文档可以确定大方向,不会因为陷入源码细节导致偏离学习目标,如下图所示:
对上文,我的理解:
Eureka client 从注册中心更新服务列表,然后自身会做缓存;
作为服务消费者,就是从这些缓存信息中获取的服务提供者的信息;
增量更新的服务以 30 秒为周期循环调用;
增量更新数据在服务端保存时间为 3 分钟,因此 Eureka client 取得的数据虽然被称为"增量更新",仍然可能和 30 秒前取的数据一样,所以 Eureka client 要自己来处理重复信息;
由 3、4 两点可以推断出,Eureka client 的增量更新,其实获取的是 Eureka server 最近三分钟内的变更,因此,如果 Eureka client 有超过三分钟没有做增量更新的话(例如网络问题),那么再调用增量更新接口时,那三分钟内 Eureka server 的变更就可能获取不到了,这就造成了 Eureka server 和 Eureka client 之间的数据不一致,需要有个方案来及时发现这个问题;
正常情况下,Eureka client 多次增量更新后,最终的服务列表数据应该 Eureka server 保持一致,但如果期间发生异常,可能导致和 Eureka server 的数据不一致,为了暴露这个问题,Eureka server 每次返回的增量更新数据中,会带有一致性哈希码,Eureka client 用本地服务列表数据算出的一致性哈希码应该和 Eureka server 返回的一致,若不一致就证明增量更新出了问题导致 Eureka client 和 Eureka server 上的服务列表信息不一致了,此时需要全量更新;
Eureka server 上的服务列表信息对外提供 JSON/XML 两种格式下载;
Eureka client 使用 jersey 的 SDK,去下载 JSON 格式的服务列表信息;准备工作就到此,接下来学习源码,整个过程应围绕上述点八进行,不要过早陷入某些代码细节中;
源码分析
如下图红框所示,更新服务列表的逻辑已经封装在 CacheRefreshThread 类中:
CacheRefreshThread 类中又是调用 refreshRegistry 方法来实现服务列表更新的,refreshRegistry 方法如下:
如上图所示,本文假设应用部署在非 AWS 环境,所以 Eureka client 不做 region 和 zone 相关的配置,因此上图绿框中的代码不会执行,我们聚焦红框中的代码,先看 fetchRegistry 方法;
fetchRegistry 方法源码如下,请注意中文注释:
上述代码中已有注释详细说明,就不另外赘述了,接下来细看 getAndStoreFullRegistry 和 getAndUpdateDelta 这两个方法,了解全量增量更新的细节;
全量更新本地缓存的服务列表
getAndStoreFullRegistry 方法负责全量更新,代码如下所示,非常简单的逻辑:
getAndStoreFullRegistry 方法中并无复杂逻辑,只有 eurekaTransport.queryClient.getApplications(remoteRegionsRef.get()) 这段需要展开细看,和 Eureka server 交互的逻辑都在这里面,方法 getApplications 的具体实现是在 EurekaHttpClientDecorator 类:
EurekaHttpClientDecorator 类从名字看是个装饰者模式的实现,看它的其他代码,发现各类远程服务都在此被封装成 API 了,例如注册的:
还有续租的:
再继续追踪 delegate.register(info),进入了 AbstractJerseyEurekaHttpClient 类,这里面是各种网络请求的具体实现,EurekaHttpClientDecorator 类中的 getApplications、register、sendHeartBeat 等方法对应的网络请求响应逻辑在 AbstractJerseyEurekaHttpClient 中都有具体实现,篇幅所限我们只关注 getApplications:
上述代码中,利用 jersey-client 库的 API 向 Eureka server 发起 restful 请求,并将响应数据封装到 EurekaHttpResponse 实例中返回;
小结:获取全量数据,是通过 jersey-client 库的 API 向 Eureka server 发起 restful 请求实现的,并将响应的服务列表数据放在一个成员变量中作为本地缓存;
获取服务列表信息的增量更新
获取服务列表信息的增量更新是通过 getAndUpdateDelta 方法完成的,具体分析请看下面的中文注释:
上述代码中有几处需要注意:a. 获取增量更新数据使用的方法是:eurekaTransport.queryClient.getDelta(remoteRegionsRef.get());b. 将增量更新的数据和本地缓存合并的方法是: updateDelta(delta);c. 通过检查一致性哈希码可以确定历经每一次增量更新后,本地的服务列表信息和 Eureka server 上的是否还保持一致,若不一致就要做一次全量更新,通过调用 reconcileAndLogDifference 方法来完成;
上述 a、b、c 三点,接下来依次展开:
向 Eureka server 发起网络请求的逻辑和前面全量更新的差不多,也是 EurekaHttpClientDecorator 和 AbstractJerseyEurekaHttpClient 这两个类合作实现的,先看 EurekaHttpClientDecorator 部分:
再看 AbstractJerseyEurekaHttpClient 类中的 getDelta 方法,居然和全量获取服务列表数据调用了相同的方法 getApplicationsInternal,只是 ur 参数不一样而已;
由上述代码可见,从 Eureka server 的获取增量更新,和一些常见的方式略有区别:a. 一般的增量更新是在请求中增加一个时间戳或者上次更新的 tag 号等参数,由服务端根据参数来判断哪些数据是客户端没有的;b. 而这里的 Eureka client 却没有这类参数,联想到前面官方文档中提到的“Eureka 会把更新数据保留三分钟”,就可以理解了:Eureka 把最近的变更数据保留三分钟,这三分钟内每个 Eureka client 来请求增量更新是,server 都返回同样的缓存数据,只要 client 能保证三分钟之内有一次请求,就能保证自己的数据和 Eureka server 端的保持一致;c. 那么如果 client 有问题,导致超过三分钟才来获取增量更新数据,那就有可能 client 和 server 数据不一致了,此时就要有一种方式来判断是否不一致,如果不一致,client 就会做一次全量更新,这种判断就是一致性哈希码;
Eureka client 获取到增量更新后,通过 updateDelta 方法将增量更新数据和本地数据做合并:
上述代码有几点需要注意:a. 检查每个服务的 region,如果跨 region 的,就合并到另一个专门存放跨 region 服务的缓存中;b. 增量数据中,对每个应用下实例的变动,分为新增、修改、删除三种,合并的过程就是对这三种数据在本地缓存中做不同的处理;c. 合并过程中还会对缓存数据做整理,这样后续每次使用时,获取的多个实例其顺序是一样的;
前面曾经提到,如果 Eureka client 不及时做增量更新,那么有可能会错过 Eureka server 上的数据变化,导致两边的服务列表信息不一致,这个问题会通过一致性哈希码对比发现,发现后如何处理呢?先看增量更新的 getAndUpdateDelta 方法中的一个注释,如下图红框所示,个人觉得这个注释写得很好,内容既简洁又重要:
上图红框中提醒:此处会发生一次远程调用,这说明发现 Eureka server 和 Eureka client 保存的服务列表数据不一致时会向 Eureka server 发起一次请求,打开 reconcileAndLogDifference 方法看详情:
上述代码较简单:从 Eureka server 获取全量数据,再尝试 CAS,如果成功就更新本地缓存数据;
至此,全量和增量更新的源码都看过了,接下来看看更新完数据后的两次广播:更新缓存和状态变化(有变化才广播);
广播:更新缓存
更新缓存的广播是在 onCacheRefreshed 方法中执行的,该方法在扩展类 CloudEurekaClient 中被覆盖:
上述代码显示,这是个 spring 容器内的广播,this.publisher 的类型是 ApplicationEventPublisher,如果您对 spring 的广播机制有兴趣,可以参考文章《spring4.1.8扩展实战之三:广播与监听》;
广播:本地状态变化
从 Eureka server 中取得的服务列表,自然也包括当前应用自己的信息,这个信息会保存在成员变量 lastRemoteInstanceStatus 中,每次更新了缓存后,都会用缓存中的信息和 lastRemoteInstanceStatus 对比,如果不一致,就表示在 Eureka server 端记录的当前应用状态发生了变化,此时就广播一次;
小结
至此,更新服务列表的源码学习就完成了,除了原理的学习,还另有两大收获:
第一,官方文档对整个过程做了准确的总结,围绕着这些总结去看代码,能够事半功倍,重要是整个过程都保持的正确的方向,不会由于细节的干扰而偏离主线;
第二,Eureka 的注册中心设计,尽管多个 client 轮询请求会增加服务器压力,但使用增量更新再加上 Server 自身缓存 3 分钟数据的方式,可以有效的减少数据量和相关的计算,再加上一致性哈希码来弥补增量更新的弊端,在性能和完整性方面都有了保证,另外增量更新不需要 client 的时间戳,这样既节省性能又简化了实现逻辑,这种设计方式值得我们学习;
欢迎关注 InfoQ:程序员欣宸
版权声明: 本文为 InfoQ 作者【程序员欣宸】的原创文章。
原文链接:【http://xie.infoq.cn/article/d50d4258ccf21ea9f94be0100】。文章转载请联系作者。
评论