Ribbon源码解析及常见问题

1.遇到的问题及对应源码

    1.1.Ribbon LoadBalancer 请求缓存:

        1.1.1.问题描述: Spring Cloud 版本:Dalston.SR1,注册中心:Eureka.  基于 Rest 的微服务架构中,使用 Ribbon 来作为客户端负载.当一个服务调用另一个服务的时候, Ribbon 会缓存请求和 service list. 假设现在有service0和service1, 当service1异常关闭后,service0去调用,会提示错误.过了一段时间,service1正常启动了,此时,service0并不会立刻知道service1已经启动,而是等待 updateListOfServers 定时任务执行,它执行的时候,就会更新service list. 

        1.1.2.解决方案:   这里涉及2个定时任务,一个是EurekaClient的定时任务(com.netflix.discovery.DiscoveryClient.refreshRegistry()), 另一个是Ribbon的定时任务(com.netflix.loadbalancer.PollingServerListUpdater.start()) . Ribbon更新server list的时候,是根据EurekaClient中的 instance list 来更新的,Ribbon并不会发送请求到Eureka Server中,获取新的service list. 获取的操作是由EurekaClient的定时任务做的.  和EurekaClient定时任务有关的配置是: eureka.client.registry-fetch-interval-seconds 这个值就是Eureka Client 定时向 Eureka Server 获取 服务列表的间隔. 和Ribbon定时任务有关的配置是:ribbon.ServerListRefreshInterval . 测试的时候,调小这两个值,即可达到快速发现服务的效果. 更好的实现方式应该是由Spring Cloud Bus 来实现.还在研究源码中.

    1.2.Ribbon Ping :

        1.2.1.问题描述: 我这里使用的是 Dalston.SR1 版本,如果你使用了Eureka作为注册中心,这时候 Ribbon会使用EurekaRibbonClientConfiguration,IPing的实现类使用的是: NIWSDiscoveryPing ,观察NIWSDiscoveryPing.isAlive(), 这里面其实没有真正的实行ping操作,而是把参数server的status直接获取,判断一下是否为UP,就判定服务是否正常.是别有用意还是太草率了?

        1.2.2.解决方案: 自行实现一个IPing,并注入到Spring中.