Ribbon负载均衡原理笔记

一 Ribbon执行一次负载均衡的过程
如果我们要使用Ribbon做负载均衡，只需要使用LoadBalancerClient即可：

T execute(String serviceId, LoadBalancerRequest request) throws IOException;
调用上面的这个方法，方法接收一个需要调用的服务id，以及具体的请求数据，返回请求的结果。

这个方法可以说是Ribbon负载均衡的入口方法，进入这个方法后，Ribbon会调用其他组件完成所有逻辑，并返回请求的结果，具体流程入下：

LoadBalancerClient调用ILoadBalancer模块，请求选取一个服务节点，以便执行execute方法参数中的request请求。
ILoadBalancer收到选取节点的请求后，会收集可用的服务节点的信息，然后把节点信息交给IRule，请求IRule选取一个服务节点。
IRule收到请求后，会按照一定规则选取出一个服务节点（不同的实现有不同的规则，下面会具体说），并返回给ILoadBalancer
ILoadBalancer收到IRule的结果后又会把节点信息返回给LoadBalancerClient
LoadBalancerClient使用ILoadBalancer返回的节点信息调用服务，获取到请求结果后返回。
从以上的流程可以看出来，Ribbon负载均衡有两个非常关键的点：

ILoadBalancer如何收集和维护可用的节点信息。
IRule的具体选取规则是什么。
可以说搞清楚Ribbon其实就是在搞清楚这两点是怎么做到的。

二 ILoadBalancer如何收集和维护可用的节点信息
从ServerList中获取所有的节点信息，ServerList是一个接口，专门用于获取一个应用所有的节点信息。
使用ServerListFilter进行过滤，把不能使用的节点过滤掉。
使用Ping接口每隔10秒检测一下服务节点信息是否需要更新。
以上前两点会在ILoadBalancer初始化的时候实现：

public DynamicServerListLoadBalancer() { //省略参数列表
    //省略代码
    restOfInit(clientConfig);
}

void restOfInit(IClientConfig clientConfig) {
    //省略代码
    updateListOfServers();
    //省略代码
}

@VisibleForTesting
public void updateListOfServers() {
    List<T> servers = new ArrayList<T>();
    if (serverListImpl != null) {
        servers = serverListImpl.getUpdatedListOfServers();
        if (filter != null) {
            servers = filter.getFilteredListOfServers(servers);
        }
    }
    updateAllServerList(servers);
}

所以其实ILoadBalancer调用了ServerList接口来获取服务所有的节点信息。

3.1 使用ServerList获取所有的服务节点信息
ServerLis接口定义如下：

public interface ServerList {
public List getInitialListOfServers();
public List getUpdatedListOfServers();
}
ServerList的实现类有很多个，比如ConfigurationBasedServerList会从配置文件中获取所有的服务节点自信，但是这不重要，重要的是DiscoveryEnabledNIWSServerList，这个类个从Eureka服务治理中心获取服务节点的信息。

DiscoveryEnabledNIWSServerList的构造方法中带有一个可以获取EurekaClient对象的Provider：

public DiscoveryEnabledNIWSServerList(IClientConfig clientConfig, Provider<EurekaClient> eurekaClientProvider) {
    this.eurekaClientProvider = eurekaClientProvider;
    initWithNiwsConfig(clientConfig);
}

而获取服务列表的两个方法都使用了

@Override
public List<DiscoveryEnabledServer> getInitialListOfServers(){
    return obtainServersViaDiscovery();
}

@Override
public List<DiscoveryEnabledServer> getUpdatedListOfServers(){
    return obtainServersViaDiscovery();
}

private List<DiscoveryEnabledServer> obtainServersViaDiscovery() {
    List<DiscoveryEnabledServer> serverList = new ArrayList<DiscoveryEnabledServer>();

    if (eurekaClientProvider == null || eurekaClientProvider.get() == null) {
        return new ArrayList<DiscoveryEnabledServer>();
    }

    EurekaClient eurekaClient = eurekaClientProvider.get();
    if (vipAddresses!=null){
        for (String vipAddress : vipAddresses.split(",")) {
            // 使用Eureka获取服务列表
            List<InstanceInfo> listOfInstanceInfo = eurekaClient.getInstancesByVipAddress(vipAddress, isSecure, targetRegion);
            for (InstanceInfo ii : listOfInstanceInfo) {
                //作一些包装，日志等操作
            }
            if (serverList.size()>0 && prioritizeVipAddressBasedServers){
                break; // if the current vipAddress has servers, we dont use subsequent vipAddress based servers
            }
        }
    }
    return serverList;
}

3.2 如何更新节点的变化信息
ILoadBalancer在启动时就开启了一个定时任务，具体代码在BaseLoadBalancer中：

void setupPingTask() {
    if (canSkipPing()) {
        return;
    }
    if (lbTimer != null) {
        lbTimer.cancel();
    }
    lbTimer = new ShutdownEnabledTimer("NFLoadBalancer-PingTimer-" + name,
            true);
    lbTimer.schedule(new PingTask(), 0, pingIntervalSeconds * 1000);
    forceQuickPing();
}

这个setupPingTask方法会在构造方法中被调用。
pingIntervalSeconds的默认值是10s，所以默认情况下每10s会ping一下

这里的PingTask任务里面的逻辑有点乱，最终会调用到根pingerStrategy.pingServers(ping, allServers)，并且依赖返回结果判断，如果该返回结果与之前相同，则不去向 EurekaClient获取注册列表，如果不同则通知ServerStatusChangeListener或
者changeListeners发生了改变，进行更新或者重新拉取。

三 IRule实现的以及具体的选取规则
RoundRobinRule：轮询策略，有一个count记录服务调用次数，然后使用index = count%size 取余的方式，来选取节点。
RoundRule：随机选择，就是随机选取一个。
BestAvailableRule：最大可用策略，先过滤掉出故障的服务实例，然后选择一个并发数量最小的。
WeightedResponseTimeRule: 带有权重的轮询策略
AvailabilityFilteringRule: 先过滤出故障的节点和请求并发量大于一定值的节点，然后再轮询
ZoneAvoidanceRule：区域感知策略
并发数量是怎么统计的？
ILoadBalancer在获取节点数据之后，会把节点信息保存在LoadBalancerStats类的serverStatCache字段中：

private final LoadingCache<Server, ServerStats> serverStatsCache
每个节点对应一个ServerStats对象，记录ServerStats的状态，ServerStats中有个字段记录了访问次数：

@VisibleForTesting
AtomicInteger openConnectionsCount = new AtomicInteger(0);

每次访问服务时，会把这个字段加1，但是这个字段不会无限往上加，一定时间没有加之后会置为0，默认是60s，可以配置：

private static final DynamicIntProperty activeRequestsCountTimeout = 
    DynamicPropertyFactory.getInstance()

.getIntProperty(“niws.loadbalancer.serverStats.activeRequestsCount.effectiveWindowSeconds”, 60 ）