Spring-Cloud之Ribbon原理剖析

我们知道Ribbon主要的工作就是进行负载均衡，帮助我们无需再关注微服务中集群的地址信息，因此在源码剖析中我们就主要关注这部分的内容。

内置的负载均衡规则

RoundRobinRule：直接轮询的方案；即每次从server list中依次选择。
AvailabilityfileringRule：根据服务器可用性来决定；比如某个服务器的并发请求过高，那么此时ribbon就会绕过不再访问；同时如果3次连接失败就会等待30秒后再次访问；如果不断失败，那么等待时间会不断变长，如果某个服务器的并发请求太高了，那么会绕过去，不再访问。
WeightedResponseTimeRule：根据权重来分配；每个服务器都可以有权重，权重高就优先访问，如果某个服务器响应时间比较长，那么权重就会降低，减少访问。
ZoneAvoidanceRule：根据区域和服务器来进行负载均衡，也就是根据机房来分配，里面再使用轮询的方式。默认的就是这个
BestAvailableRule：忽略连接失败的服务器，同时尽量找并发比较低的服务器来请求。
RandomRule：随机选择一个。
RetryRule：在轮询的方案上增加重试机制；即通过轮询的方式选择一个服务器请求，在失败的时候会重新再找一个重试。

可以通过ribbon.NFLoadBalancerRuleClassName: top.vchar.MyRule 来切换规则

RestTemplate 加上 @LoadBalanced

当我们在 RestTemplate 上添加 @LoadBalanced 注解后，在写接口地址的时候可以直接使用服务名代替真实的地址；在执行请求的过程中Ribbon会自动的将其替换为真实的地址。加上 @LoadBalanced 注解就可以让 RestTemplate的请求交ribbon的原理如下：

在ribbon的整合中有个LoadBalancerAutoConfiguration的配置，它里面会注入所有带@LoadBalanced 注解的 RestTemplate的bean；然后会给这些RestTemplate添加上一个LoadBalancerInterceptor的拦截器；
在 RestTemplate 执行请求的时候，这个拦截器会拦截请求，将其转给LoadBalancerClient（实际是RibbonLoadBalancerClient来实现的）来做接下来的全部操作。
在RibbonLoadBalancerClient中会根据服务名从注册表获取该服务对应的服务信息集合，然后根据设置的负载均衡规则选择一个服务信息；
之后将将请求地址中的服务名称称替换为真实的地址，然后发起请求。

IPing机制

Ribbon中IPing机制其实就是定时的去检查拿到的注册表中的服务是否可用，如果不可用将会移除它。默认使用NIWSDiscoveryPing类实现IPing；它就是启动了一个定时任务，默认每隔30s执行一次，通过检查服务的状态是否是UP状态来判断该服务是否存活。

public boolean isAlive(Server server) {

    boolean isAlive = true;

    if (server != null && server instanceof DiscoveryEnabledServer) {

        DiscoveryEnabledServer dServer = (DiscoveryEnabledServer)server;

        InstanceInfo instanceInfo = dServer.getInstanceInfo();

        if (instanceInfo != null) {

             InstanceStatus status = instanceInfo.getStatus();

             if (status != null) {

                 isAlive = status.equals(InstanceStatus.UP);

             }

        }

    }

    return isAlive;

}

关于Ribbon获取服务注册表

Ribbon并没有直接使用eureka client的注册表信息，而是拷贝了一份注册表信息重新封装了一下。它在初始化的时候会通过PollingServerListUpdater来启动一个定时任务，默认每隔30s到eureka client的注册表中拷贝一次然后刷新它自己的。这个时间可以通过配置 ribbon.ServerListRefreshInterval 来修改定时任务的执行间隔时间。

那么如果某台机器故障宕机，ribbon需要多久才能感知到呢？下面我们来分析下：首先eureka server的服务故障感知最坏的情况下是需要180s，同时只读缓存默认30s才会自动更新，eureka client默认30s才会去拉取一次注册信息，加上ribbon自己的刷新时间30s，那么整个过程需要的时间就是180s+30s+30s+30s=270s，也就是大约要4分钟半左右。

关于Ribbon的配置

Ribbon配置支持的key在ribbon-core中的CommonClientConfigKey类中，我们可以根据需要到里面去查阅；配置方式分为全局和局部。

全部配置直接以ribbon开头，比如：ribbon.ServerListRefreshInterval:20 修改ribbon刷新注册表的时间
局部配置就是针对某个服务的配置，格式为：<clientName>.<nameSpace>.<propertyName>=<value> ；示例

# 配置memberServer的服务调用失败的时候重试一次

memberServer.ribbon.MaxAutoRetries=1