客户端负载均衡—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 servers = new ArrayList();
        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 eurekaClientProvider) {
        this.eurekaClientProvider = eurekaClientProvider;
        initWithNiwsConfig(clientConfig);
    }

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

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

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

    private List obtainServersViaDiscovery() {
        List serverList = new ArrayList();

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

        EurekaClient eurekaClient = eurekaClientProvider.get();
        if (vipAddresses!=null){
            for (String vipAddress : vipAddresses.split(",")) {
                // 使用Eureka获取服务列表
                List 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 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);

你可能感兴趣的:(客户端负载均衡—Ribbon)