终于，到了和Ribbon系列说再见的时候，笔者任务Ribbon的源码逻辑虽然比Eureka简单一些，但与Spring集成上稍微有点儿绕，主要是自动配置的执行顺序那块儿，如果采用静态代码阅读的方式的话，很难发现问题。不过，这也让笔者对Spring的自动配置机制有了更深的了解。

这篇文章算是前面三篇的一个总结，从一个请求被执行的角度，将Spring以及Ribbon的关键组件串起来思考。

Ribbon + Eureka感知故障实例的滞后性

我们先用一张图回顾一下Eureka客户端去Eureka Server拉取服务注册表的情况

我们上篇已经知道PollingServerListUpdater有可能是负责与Eureka交互定时获取服务列表的，本篇我们就剖析下这个组件相关的逻辑。

入口

我们在每次使用Spring Cloud Netflix Ribbon的时候，有一个固定的套路就是需要用@LoadBalanced注解修饰一个RestTemplate

1
2
3
4

@LoadBalanced
public RestTemplate getRestTemplate() {
    return new RestTemplate();
}

Ribbon解决了什么问题

当集群中有了注册中心之后，服务消费者可以拿到所有服务的列表，此时就需要有一个组件能够将请求负载均衡到各个实例上去。ribbon就是这样一个客户端侧的负载均衡组件，同出Netflix，与其他组件整合后非常实用。

Ribbon提供了多种不同的负载均衡算法实现，非常实用。