这篇文章算是前面三篇的一个总结，从一个请求被执行的角度，将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提供了多种不同的负载均衡算法实现，非常实用。

Spring Cloud Netflix Eureka对eureka原生项目做了一点儿轻量级的封装。

• eureka 客户端会在启动时，从eureka server抓取全量注册表到本地

• 什么是eureka集群？
  一组互相复制数据，完全对等的eureka节点。通过配置文件指定，也可以热刷新（扩容缩容）

• 自我保护机制是什么？
  在eureka server中，他假定正常情况下肯定有大于85%的服务实例能够保持正常的心跳，最近1分钟内少于85%的服务实例心跳成功，eureka开发团队认为，此时大概率是eureka server自己的网络故障了，此时再进行过期实例剔除都会是误伤，于是就不再对故障实例剔除。这就叫进入了自我保护机制。

• 故障感知和摘除指的是什么？
  正常下线，会通过eureka client的shutdown方法进行，走下线流程。
  当因为一些原因，没有通过正常下线的方式，服务实例却下线了，这种异常情况，成为故障。
  感知，eureka server会通过定时检查多久没心跳了，感知到这种故障服务实例，并自动从注册表中把这个服务实例摘除。