记一次Debug过程

刚刚加入新公司，就迎来第一场战斗，微服务拉入拉出测试。

简单的说，对于接入eureka 和 vi(携程开源的) 应用，在使用发布系统进行发布的时候，会经过这么一个流程
   UP —— STARTING ——（DOWN, 然后踢掉）—— STARTING —— UP

需要测试当应用进行发布的时候，是否会产生业务影响，即服务消费者消费服务的时候，是否会有流量进入处于发布状态的节点，以及发布后生产者的节点是否正常。

设计场景其实很简单，写一个脚本，持续不断调用消费者对外提供的http接口，通过判断消费者的服务正常来判断生产者的状态，这里就出现两个场景了，生产者有1/2个节点，2带表多个。

1个节点的测试细节不多说了，重点说一下测试过程中一个神奇的问题，当provider节点置为STARTING后，consumer仍然可以访问到这个节点，意即consumer本地缓存的服务节点中，这个provider还是UP, 可用状态，表现出来的现象就是，consumer的请求进入了STARTING provider, 长达30s。为什么呢？

第一个答案很快出来了，

# 定时刷新本地缓存时间，单位是s，默认值是30s
   eureka.client.registryFetchIntervalSeconds=5

这是eureka client的定时任务，访问eureka server获取当前最新的服务列表。

迅速增加配置，再来一次！

好像还是没有好，看来调整下思路，是不是从eureka server获取服务列表失败？

这里盗用下人家的代码（来自 https://blog.csdn.net/boling_cavalry/article/details/82827802 ）

不是这个问题，确实收到广播了。

换一个思路，本地缓存没有跟着更新？怎么打印本地当前缓存的内容呢？

鉴于公司使用 netflix全家桶，通过eureka管理微服务，那么另一个参数展现出它的身影：

# ribbon缓存时间，单位是ms，默认值是30s
   ribbon.ServerListRefreshInterval=5000

Ribbon !

Ribbon是netflix全家桶的一员，是用于eureka client的负载均衡器，运行在客户端上，具体介绍参考 http://blog.springcloud.cn/sc/sc-fzp-ribbon/

长话短说，看到这里，可以理解为客户端的在调用列表中的服务的时候，服务没有更新，也就是说，需要强制刷新缓存，ribbon 作为客户端负载均衡器，是第一个被考虑到的key point.

于是果然在消费者端检查ribbon的配置，果然没有加上这个。就笔者目前碰到的所有springcloud的配置中，如果没有特殊配置，默认都是30s, 是不是看起来很眼熟？

Bingo ! 这就是答案，在把ribbon.ServerListRefreshInterval的值修改为2000的时候，eureka server修改服务端节点为STARTING后，就只有1到2条流量进来了，如果不考虑对性能的影响，完全可以配置得更小。

于是问题解决。

总结一下，大概是始终关注当前的key point，顺便了解了springcloud的缓存管理。

PS， 特别注意SpringCloud的缓存更新是怎么实现的：

应用作为Eureka Client的启动时，在com.netflix.discovery.DiscoveryClient类的initScheduledTasks方法中，会启动周期性任务，每隔30秒从Eureka server获取服务列表信息，如下图，红框中的TimedSupervisorTask负责周期性执行，CacheRefreshThread负责具体的更新逻辑： getAndUpdateDelta(applications)

在CacheRefreshThread类中经过层层调用，获取服务列表并更新本地缓存的逻辑在fetchRegistry方法中实现，getAndStoreFullRegistry方法负责全量更新，getAndUpdateDelta方法负责增量更新，onCacheRefreshed方法负责发送广播，广播类型是服务列表的本地缓存已更新。