三、 负载均衡机制

 

1. 常规负载均衡算法

 

在集群负载均衡时，Dubbo提供了多种均衡策略，缺省为weighted random基于权重的随机负载均衡策略。

 

具体实现上，Dubbo提供的是客户端负载均衡，即由Consumer通过负载均衡算法得出需要将请求提交到哪个Provider实例。

  

1) 负载均衡策略

 

目前Dubbo内置了如下负载均衡算法，可通过调整配置项启用。

 

 

Weighted Random

 

• 加权随机，按权重设置随机概率。

 

• 在一个截面上碰撞的概率高，但调用量越大分布越均匀，而且按概率使用权重后也比较均匀，有利于动态调整提供者权重。

 

• 缺点：存在慢的提供者累积请求的问题，比如：第二台机器很慢，但没挂，当请求调到第二台时就卡在那，久而久之，所有请求都卡在调到第二台上。

 

RoundRobin

 

• 加权轮询，按公约后的权重设置轮询比率，循环调用节点。

 

• 缺点：同样存在慢的提供者累积请求的问题。

 

加权轮询过程过程中，如果某节点权重过大，会存在某段时间内调用过于集中的问题。

 

例如ABC三节点有如下权重：{A: 3, B: 2, C: 1}，那么按照最原始的轮询算法，调用过程将变成：A A A B B C。

 

对此，Dubbo借鉴Nginx的平滑加权轮询算法，对此做了优化，调用过程可抽象成下表：

 

 

我们发现经过合计权重（3+2+1）轮次后，循环又回到了起点，整个过程中节点流量是平滑的，且哪怕在很短的时间周期内，概率都是按期望分布的。

 

如果用户有加权轮询的需求，可放心使用该算法。

 

LeastActive

 

• 加权最少活跃调用优先，活跃数越低，越优先调用，相同活跃数的进行加权随机。活跃数指调用前后计数差（针对特定提供者：请求发送数-响应返回数），表示特定提供者的任务堆积量，活跃数越低，代表该提供者处理能力越强。

 

• 使慢的提供者收到更少请求，因为越慢的提供者的调用前后计数差会越大；相对的，处理能力越强的节点，处理更多的请求。

 

ShortestResponse

 

• 加权最短响应优先，在最近一个滑动窗口中，响应时间越短，越优先调用。相同响应时间的进行加权随机。

 

• 使得响应时间越快的提供者，处理更多的请求。

 

• 缺点：可能会造成流量过于集中于高性能节点的问题。

 

这里的响应时间=某个提供者在窗口时间内的平均响应时间，窗口时间默认是30s。

 

ConsistentHash

 

• 一致性Hash，相同参数的请求总是发到同一提供者。

 

• 当某一台提供者挂时，原本发往该提供者的请求，基于虚拟节点，平摊到其它提供者，不会引起剧烈变动。

 

• 算法参见：Consistent Hashing | WIKIPEDIA

 

• 缺省只对第一个参数Hash，如果要修改，请配置

 

• 缺省用160份虚拟节点，如果要修改，请配置

 

2) 配置方式

 

Dubbo支持在服务提供者一侧配置默认的负载均衡策略，这样所有的消费者都将默认使用提供者指定的负载均衡策略，消费者可以自己配置要使用的负载均衡策略，如果都没有任何配置，则默认使用随机负载均衡策略。

 

同一个应用内支持配置不同的服务使用不同的负载均衡策略，支持为同一服务的不同方法配置不同的负载均衡策略。

 

具体配置方式参加以下多语言实现。

 

3) 自定义扩展

 

负载均衡策略支持自定义扩展实现，具体请参见Dubbo官网可扩展性文档。

 

《Apache Dubbo微服务开发从入门到精通》——服务发现与负载均衡——三、 负载均衡机制（2）： https://developer.aliyun.com/article/1224434