客户端负载均衡—Ribbon

一 Ribbon执行一次负载均衡的过程

如果我们要使用Ribbon做负载均衡，只需要使用LoadBalancerClient即可：

<T> T execute(String serviceId, LoadBalancerRequest<T> 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<T extends Server> {
    public List<T> getInitialListOfServers();
    public List<T> 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 * 10);