Dubbo负载均衡

末蓝、 2023-06-22 08:23 10阅读 0赞

### AbstractLoadBalance ###

在 Dubbo 中，所有负载均衡实现类均继承自 AbstractLoadBalance，该类实现了 LoadBalance 接口，并封装了一些公共的逻辑。

负载均衡的入口在AbstractLoadBalance的select方法。

public abstract class AbstractLoadBalance implements LoadBalance {
        ......
    
        @Override
        public <T> Invoker<T> select(List<Invoker<T>> invokers, URL url, Invocation invocation) {
            if (CollectionUtils.isEmpty(invokers)) {
                return null;
            }
            // 如果 invokers 列表中仅有一个 Invoker，直接返回即可，无需进行负载均衡
            if (invokers.size() == 1) {
                return invokers.get(0);
            }
            // 进行负载均衡，该方法为抽象方法，由子类实现
            return doSelect(invokers, url, invocation);
        }
    
        protected abstract <T> Invoker<T> doSelect(List<Invoker<T>> invokers, URL url, Invocation invocation);
    
        ......
    
    }

### 权重计算 ###

权重计算属于不同负载均衡实现的公共部分，这部分逻辑在父类AbstractLoadBalance中实现。

下面是是权重的计算过程，该过程主要用于用于保证当服务运行时长小于服务预热时间时，对服务进行降权，避免让服务在启动之初就处于高负载状态。服务预热是一个优化手段，与此类似的还有 JVM 预热。主要目的是让服务启动后“低功率”运行一段时间，使其效率慢慢提升至最佳状态。

protected int getWeight(Invoker<?> invoker, Invocation invocation) {
            // 从 url 中获取权重 weight 配置值
            int weight = invoker.getUrl().getMethodParameter(invocation.getMethodName(), WEIGHT_KEY, DEFAULT_WEIGHT);
            if (weight > 0) {
                // 获取服务提供者启动时间戳
                long timestamp = invoker.getUrl().getParameter(REMOTE_TIMESTAMP_KEY, 0L);
                if (timestamp > 0L) {
                    // 计算服务提供者运行时长
                    int uptime = (int) (System.currentTimeMillis() - timestamp);
                    // 获取服务预热时间，默认为10分钟
                    int warmup = invoker.getUrl().getParameter(WARMUP_KEY, DEFAULT_WARMUP);
                    // 如果服务运行时间小于预热时间，则重新计算服务权重，即降权
                    if (uptime > 0 && uptime < warmup) {
                        // 重新计算服务权重
                        weight = calculateWarmupWeight(uptime, warmup, weight);
                    }
                }
            }
            return weight >= 0 ? weight : 0;
        }
    
        static int calculateWarmupWeight(int uptime, int warmup, int weight) {
            // 计算权重，下面代码逻辑上形似于 (uptime / warmup) * weight。
            // 随着服务运行时间 uptime 增大，权重计算值 ww 会慢慢接近配置值 weight
            int ww = (int) ((float) uptime / ((float) warmup / (float) weight));
            return ww < 1 ? 1 : (ww > weight ? weight : ww);
        }

### 负载均衡算法 ###

<table> 
 <tbody> 
  <tr> 
   <td>算法名称</td> 
   <td style="width:573px;">说明</td> 
  </tr> 
  <tr> 
   <td>Random LoadBalance</td> 
   <td style="width:573px;"> <p>随机</p> <p>可以按权重设置随机概率，调用量越大分布月均匀</p> </td> 
  </tr> 
  <tr> 
   <td>RoundRobin LoadBalance</td> 
   <td style="width:573px;"> <p>轮询</p> <p>可以根据权重设置轮询比例。</p> </td> 
  </tr> 
  <tr> 
   <td>LeastActive LoadBalance</td> 
   <td style="width:573px;"> <p>最少活跃调用数</p> <p>根据活跃度进行分配调用，使慢的提供者收到更少的请求，如果活跃数相同则随机调用，活跃数是指调用前后的计数差。</p> </td> 
  </tr> 
  <tr> 
   <td>ConsistentHash LoadBalance</td> 
   <td style="width:573px;"> <p>一致性Hash</p> <p>相同参数的请求总是发到同一提供者，当某台提供者挂掉时，基于虚拟节点，相应的请求会平摊到其它提供者，不会引起剧烈变动。</p> </td> 
  </tr> 
 </tbody> 
</table>

这四种算法在Dubbo中分别对应了RandomLoadBalance、RoundRobinLoadBalance、LeastActiveLoadBalance、ConsistentHashLoadBalance四个类，它们继承于AbstractLoadBalance。

### RandomLoadBalance ###

加权随机负载均衡。

在经过多次请求后，能够将调用请求按照权重值进行“均匀”分配。当然 RandomLoadBalance 也存在一定的缺点，当调用次数比较少时，Random 产生的随机数可能会比较集中，此时多数请求会落到同一台服务器上。这个缺点并不是很严重，多数情况下可以忽略。RandomLoadBalance 是一个简单，高效的负载均衡实现，因此 Dubbo 选择它作为缺省实现。

### RoundRobinLoadBalance ###

加权轮询负载均衡。

所谓轮询是指将请求轮流分配给每台服务器。轮询是一种无状态负载均衡算法，实现简单，适用于每台服务器性能相近的场景下。但现实情况下，我们并不能保证每台服务器性能均相近，这时便需要对轮询过程进行加权，以调控每台服务器的负载。

比如服务器 A、B、C 权重比为 5:2:1。那么在8次请求中，服务器 A 将收到其中的5次请求，服务器 B 会收到其中的2次请求，服务器 C 则收到其中的1次请求。

### LeastActiveLoadBalance ###

最小活跃数负载均衡。

活跃调用数越小，表明该服务提供者效率越高，单位时间内可处理更多的请求。此时应优先将请求分配给该服务提供者。

在具体实现中，每个服务提供者对应一个活跃数 active。初始情况下，所有服务提供者活跃数均为0。每收到一个请求，活跃数加1，完成请求后则将活跃数减1。在服务运行一段时间后，性能好的服务提供者处理请求的速度更快，因此活跃数下降的也越快，此时这样的服务提供者能够优先获取到新的服务请求、这就是最小活跃数负载均衡算法的基本思想。

LeastActiveLoadBalance 在实现上还引入了权重值。举个例子说明一下，在一个服务提供者集群中，有两个性能优异的服务提供者。某一时刻它们的活跃数相同，此时 Dubbo 会根据它们的权重去分配请求，权重越大，获取到新请求的概率就越大。如果两个服务提供者权重相同，此时随机选择一个即可。

### ConsistentHashLoadBalance ###

一致性 hash负载均衡。

首先根据 ip 或者其他的信息为缓存节点生成一个 hash，并将这个 hash 投射到 \[0, 2^32 - 1\] 的圆环上。当有查询或写入请求时，则为缓存项的 key 生成一个 hash 值。然后查找第一个大于或等于该 hash 值的缓存节点，并到这个节点中查询或写入缓存项。如果当前节点挂了，则在下一次查询或写入缓存时，为缓存项查找另一个大于其 hash 值的缓存节点即可。

![format_png][]

这里相同颜色的节点均属于同一个服务提供者，比如 Invoker1-1，Invoker1-2，……, Invoker1-160。这样做的目的是通过引入虚拟节点，让 Invoker 在圆环上分散开来，避免数据倾斜问题。

[format_png]: https://imgconvert.csdnimg.cn/aHR0cDovL2R1YmJvLmFwYWNoZS5vcmcvZG9jcy96aC1jbi9zb3VyY2VfY29kZV9ndWlkZS9zb3VyY2VzL2ltYWdlcy9jb25zaXN0ZW50LWhhc2gtaW52b2tlci5qcGc?x-oss-process=image/format,png