Dubbo 负载均衡

1、什么是负载均衡？

负载均衡是在支持应用程序的资源池中平均分配网络流量的一种方法。

现代应用程序必须同时处理数百万用户，并以快速、可靠的方式将正确的文本、视频、图像和其他数据返回给每个用户。

为了处理如此高的流量，大多数应用程序都有许多资源服务器，它们之间包含很多重复数据。

负载均衡器是位于用户与服务器组之间的设备，充当不可见的协调者，确保均等使用所有资源服务器。

2、负载均衡的工作原理是什么？

公司的业务总是跑在多台服务器上，这种服务器安排被称为服务器场

用户对应用程序的请求首先转到负载均衡器。然后，负载均衡器会将每个请求路由到服务器场中最适合处理该请求的单个服务器。

3、负载均衡算法

负载均衡算法是一组规则，负载均衡器遵循这些规则来确定最适合每个不同客户端请求的服务器。负载均衡算法分为两个主要类别。

静态负载均衡

静态负载均衡算法遵循固定规则，与当前服务器状态无关。以下是静态负载均衡的示例。

循环法

服务器的 IP 地址通知客户端将请求发往何处。IP 地址是一串很难记住的长数字。为了简单起见，域名系统将网站名称映射到服务器。当您在浏览器中输入 aws.amazon.com 时，请求将首先发送到我们的名称服务器，该服务器会将我们的 IP 地址返回给您的浏览器。

在循环法中，权威性名称服务器（而不是专用硬件或软件）执行负载均衡。该名称服务器轮流或以循环方式返回服务器场中不同服务器的 IP 地址。

*加权循**环法*

在加权循环负载均衡中，您可以根据服务器的优先级或容量为每台服务器分配不同权重。权重较高的服务器将从名称服务器接收更多的传入应用程序流量。

IP 哈希法

在 IP 哈希法中，负载均衡器将对客户端 IP 地址执行名为哈希的数学计算。它将客户端 IP 地址转换为数字，然后将该数字映射到各个服务器。

动态负载均衡

动态负载均衡算法将在分配流量之前检查服务器的当前状态。以下是动态负载均衡算法的一些示例。

最少连接法

连接是客户端与服务器之间的开放通信渠道。当客户端向服务器发送第一个请求时，客户端将进行身份验证，并在彼此之间建立活动连接。在最少连接法中，负载均衡器将检查哪些服务器的活动连接最少，并将流量发送到这些服务器。此方法假定所有连接均要求所有服务器具有相同处理能力。

加权最小连接法

加权最小连接算法假定某些服务器可以处理比其他服务器更多的活动连接。因此，您可以为每台服务器分配不同的权重或容量，负载均衡器会将新的客户端请求发送到按容量计算连接最少的服务器。

最短响应时间法

响应时间是服务器处理传入请求和发送响应所花费的总时间。最短响应时间法会将服务器响应时间与活动连接相结合，以确定最佳服务器。负载均衡器使用此算法来确保为所有用户提供更快的服务。

基于资源的方法

在基于资源的方法中，负载均衡器通过分析当前服务器负载来分配流量。称为代理的专用软件在每台服务器上运行，并计算服务器资源的使用情况，如其计算容量和内存。然后，负载均衡器将先检查代理是否有足够的可用资源，然后再将流量分配给该服务器。

4、Dubbo 内置的负载均衡算法

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

算法	特性	备注
Weighted Random LoadBalance	加权随机	默认算法，默认权重相同
RoundRobin LoadBalance	加权轮询	借鉴于 Nginx 的平滑加权轮询算法，默认权重相同，
LeastActive LoadBalance	最少活跃优先 + 加权随机	背后是能者多劳的思想
Shortest-Response LoadBalance	最短响应优先 + 加权随机	更加关注响应速度
ConsistentHash LoadBalance	一致性哈希	确定的入参，确定的提供者，适用于有状态请求
P2C LoadBalance	Power of Two Choice	随机选择两个节点后，继续选择"连接数"较小的那个节点。
Adaptive LoadBalance	自适应负载均衡	在 P2C 算法基础上，选择二者中 load 最小的那个节点

Dubbo 官方的解释：

Weighted Random

加权随机，按权重设置随机概率。
在一个截面上碰撞的概率高，但调用量越大分布越均匀，而且按概率使用权重后也比较均匀，有利于动态调整提供者权重。
缺点：存在慢的提供者累积请求的问题，比如：第二台机器很慢，但没挂，当请求调到第二台时就卡在那，久而久之，所有请求都卡在调到第二台上。

RoundRobin

加权轮询，按公约后的权重设置轮询比率，循环调用节点
缺点：同样存在慢的提供者累积请求的问题。

加权轮询过程中，如果某节点权重过大，会存在某段时间内调用过于集中的问题。例如 ABC 三节点有如下权重：{A: 3, B: 2, C: 1} 那么按照最原始的轮询算法，调用过程将变成：A A A B B C

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

轮前加和权重	本轮胜者	合计权重	轮后权重（胜者减去合计权重）
起始轮	\	\	`A(0), B(0), C(0)`
`A(3), B(2), C(1)`	A	6	`A(-3), B(2), C(1)`
`A(0), B(4), C(2)`	B	6	`A(0), B(-2), C(2)`
`A(3), B(0), C(3)`	A	6	`A(-3), B(0), C(3)`
`A(0), B(2), C(4)`	C	6	`A(0), B(2), C(-2)`
`A(3), B(4), C(-1)`	B	6	`A(3), B(-2), C(-1)`
`A(6), B(0), C(0)`	A	6	`A(0), B(0), C(0)`

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

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

LeastActive

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

ShortestResponse

加权最短响应优先，在最近一个滑动窗口中，响应时间越短，越优先调用。相同响应时间的进行加权随机。
使得响应时间越快的提供者，处理更多的请求。
缺点：可能会造成流量过于集中于高性能节点的问题。

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

ConsistentHash

一致性 Hash，相同参数的请求总是发到同一提供者。
当某一台提供者挂时，原本发往该提供者的请求，基于虚拟节点，平摊到其它提供者，不会引起剧烈变动。
算法参见：Consistent Hashing | WIKIPEDIA
缺省只对第一个参数 Hash，如果要修改，请配置 <dubbo:parameter key="hash.arguments" value="0,1" />
缺省用 160 份虚拟节点，如果要修改，请配置 <dubbo:parameter key="hash.nodes" value="320" />

P2C Load Balance

Power of Two Choice 算法简单但是经典，主要思路如下：

对于每次调用，从可用的provider列表中做两次随机选择，选出两个节点providerA和providerB。
比较providerA和providerB两个节点，选择其"当前正在处理的连接数"较小的那个节点。

以下是 Dubbo P2C 算法实现提案

Adaptive Load Balance

Adaptive 即自适应负载均衡，是一种能根据后端实例负载自动调整流量分布的算法实现，它总是尝试将请求转发到负载最小的节点。

以下是 Dubbo Adaptive 算法实现提案

5、配置方式

服务端服务级别

xml 复制代码

<dubbo:service interface=".." loadbalance="roundrobin"/>

服务端方法级别

xml 复制代码

<dubbo:service interface="..">

    <dubbo:method name=".." loadbalance="roundrobin"/>

</dubbo:service>

消费端服务级别

xml 复制代码

<dubbo:reference interface=".." loadbalance="roundrobin"/>

消费端方法级别

xml 复制代码

<dubbo:reference interface="..">

    <dubbo:method name=".." loadbalance="roundrobin"/>

</dubbo:reference>

服务端注解方式

java 复制代码

@DubboService(loadbalance="..")
public class UserServiceImpl implements UserService {}

消费者端注解方式

java 复制代码

@DubboReference(loadbalance="..")
private UserService userService