一、背景

搜索推荐算法架构为京东集团所有的搜索推荐业务提供服务，实时返回处理结果给上游。部门各子系统已经实现了基于 CPU 的自适应限流，但是 Client 端对 Server 端的调用依然是 RR 轮询的方式，没有考虑下游机器性能差异的情况，无法最大化利用集群整体 CPU，存在着 Server 端 CPU 不均衡的问题。

京东广告部门针对其业务场景研发的负载均衡方法很有借鉴意义，他们提出的 RALB (Remote Aware Load Balance) 算法能够提升下游服务集群机器 CPU 资源效率，避免 CPU 短板效应，让性能好的机器能够处理更多的流量。我们将其核心思想应用到我们的系统中，获得了不错的收益。

本文的结构如下：

1.RALB 简介

◦简单介绍了算法的原理。

2. 功能验证

◦将 RALB 负载均衡技术应用到搜索推荐架构系统中，进行功能上的验证。

3. 吞吐测试

◦主要将 RALB 和 RR 两种负载均衡技术做对比。验证了在集群不限流和完全限流的情况下，两者的吞吐没有明显差异。在 RR 部分限流的情况下，两者吞吐存在着差异，并且存在着最大的吞吐差异点。对于 RALB 来说，Server 端不限流到全限流是一个转折点，几乎没有部分限流的情况。

4. 边界测试

◦通过模拟各种边界条件，对系统进行测试，验证了 RALB 的稳定性和可靠性。

5. 功能上线

◦在所有 Server 端集群全面开启 RALB 负载均衡模式。可以看出，上线前后，Server 端的 QPS 逐渐出现分层，Server 端的 CPU 逐渐趋于统一。

二、RALB 简介

RALB 是一种以 CPU 均衡为目标的高性能负载均衡算法。

2.1 算法目标

1. 调节 Server 端的 CPU 使用率，使得各节点之间 CPU 相对均衡，避免 CPU 使用率过高触发集群限流

2.QPS 与 CPU 使用率成线性关系，调节 QPS 能实现 CPU 使用率均衡的目标

2.2 算法原理2.2.1 算法步骤

1. 分配流量的时候，按照权重分配（带权重的随机算法，wr）

2. 收集 CPU 使用率：Server 端通过 RPC 反馈 CPU 使用率（平均 1s）给 Client 端

3. 调权：定时（每 3s）根据集群及各节点上的 CPU 使用率（窗口内均值）调节权重，使各节点 CPU 均衡

2.2.2 指标依赖

编号

指标

作用

来源

1

IP

可用 IP 列表

服务注册发现和故障屏蔽模块进行维护

2

实时健康度

IP 可用状态实时变化，提供算法的边界条件

RPC 框架健康检查功能维护

3

历史健康度

健康度历史值，用于判断 ip 故障及恢复等边界条件

指标 2 的历史值

4

动态目标（CPU 使用率）

提供均衡算法的最直接目标依据

Server 端定时统计，RPC 框架通过 RPC 返回

5

权重 weight

实时负载分发依据

算法更新

2.2.3 调权算法2.2.4 边界处理

边界 1：反馈窗口（3s）内，如果下游 ip 没被访问到，其 CPU 均值为 0，通过调权算法会认为该节点性能极好，从而调大权重

边界 2：网络故障时，RPC 框架将故障节点设为不可用，CPU 和权重为 0；网络恢复后，RPC 框架将 IP 设置为可用，但是权重为 0 的节点分不到流量，从而导致该节点将一直处于不可用状态

处理：权重的更新由定时器触发，记录节点的可用状态，当节点从不可用恢复为可用状态时，给定一个低权重，逐步恢复

2.3 落地关键

既要快又要稳，在任何情况下都要避免陷入僵局和雪崩，尤其要处理好边界条件

算法要点:

1. 公式中各依赖因子的更新保持独立的含义和更新机制，以维护算法的可靠和简洁

◦IP 列表的更新由服务注册发现和 RPC 框架共同保证

◦RPC 更新 CPU

2. 注意边界值的含义，边界值的含义需要区分连续值

◦CPU = 0，表示未知，不表示 CPU 性能好

◦w = 0，表示不会被分配流量，只有在不可用的情况下才为 0；可用情况下，应该至少有一个较小的值，保证仍能触发 RPC，进而可以更新权重

3. 算法更新权重，不要依赖 RPC 触发，而应该定时更新

三、功能验证3.1 压测准备

Module

IP

CPU

Client 端

10.173.102.36

8

Server 端

11.17.80.238

8

11.18.159.191

8

11.17.191.137

8

3.2 压测数据

指标

RR 负载均衡

RALB 负载均衡

QPS

Server 端的 QPS 均衡

从上图可以看出，Server 端的 QPS 出现分层

CPU

CPU 表现也比较均匀，维持在 10% 左右，不过相比于 RALB，节点间 CPU 差距大些

****

Server 端 CPU 表现均匀，均维持在 10% 左右

TP99

延时稳定，存在一些差异

延时稳定，存在些微差异，相对 RR 小一些

由于机器性能差距不大，所以压测的 CPU 效果并不明显，为了使 CPU 效果更明显，给节点”11.17.80.238“施加起始的负载 (即无流量时，CPU 使用率为 12.5%）

指标

LA 负载均衡

RR 负载均衡

RALB 负载均衡

QPS

 QPS 极不均匀，而且流量倾斜严重，会出现流量全集中在一个节点上的现象

 QPS 均匀

QPS 出现明显分层，其中 QPS 出现变化，是因为对 “权重最大调整比例 “进行了两次调整（1.5 → 2.0 → 2.5） 11.17.80.238：125 → 96 → 79 11.18.159.191：238 → 252 → 262 11.17.191.137：239 → 254 → 263

CPU

 CPU 不是 LA 均衡的目标，所以跟 QPS 趋势一致，全集中单个节点上

 CPU 出现明显分层，11.17.80.238 的 CPU 明显高于其他节点

 1、刚开始压测，11.17.80.238 的 CPU 高于其他两个节点，因为 “权重最大调整比例 “为 1.5（相对于 base，固定值为 10000），达到了调整极限 2、“权重最大调整比例 “调整为 2.0，节点间的差距变小 3、“权重最大调整比例 “调整为 2.5，节点间的差距进一步变小

TP99

 承接流量的节点延时是稳定的，由于存在节点接受的流量很低（几乎没有），这些节点的延时看起来波动就比较大，不过 LA 对于延时的效果应该是稳定的，因为大部分请求是以比较均衡的延时得到处理的。

 延时稳定，存在些微差异

延时稳定，存在些微差异，相对 RR 小一些

3.3 压测结论

经过压测，RR 和 LA 均存在 CPU 不均衡的问题，会因为机器资源的性能差异，而导致短板效应，达不到充分利用资源的目的。

RALB 是以 CPU 作为均衡目标的，所以会根据节点的 CPU 实时调整节点承接的 QPS，进而达到 CPU 均衡的目标，功能上验证是可用的，CPU 表现符合预期。

四、吞吐测试4.1 压测目标

RALB 是一种以 CPU 使用率作为动态指标的负载均衡算法，能很好地解决 CPU 不均衡的问题，避免 CPU 短板效应，让性能好的机器能够处理更多的流量。因此，我们期望 RALB 负载均衡策略相比于 RR 轮询策略能够得到一定程度的吞吐提升。

4.2 压测准备

Server 端 100 台机器供测试，Server 端为纯 CPU 自适应限流，限流阈值配置为 55%。

4.3 压测数据

通过压测在 RALB 和 RR 两种负载均衡模式下，Server 端的吞吐随着流量变化的趋势，对比两种负载均衡策略对于集群吞吐的影响。

4.3.1 RALB4.3.1.1 吞吐数据

下表是 Server 端的吞吐数据，由测试发压 Client 端，负载均衡模式设置为 RALB。在 18:17Server 端的状况接近于刚刚限流。整个压测阶段，压测了不限流、部分限流、完全限流 3 种情况。

时间

17:40

17:45

17:52

18:17

18:22

总流量

2270

1715

1152

1096

973

处理流量

982

1010

1049

1061

973

被限流量

1288

705

103

35

0

限流比例

56.74%

41%

8.9%

3.2%

0%

平均 CPU 使用率

55%

55%

54%

54%

49%

4.3.1.2 指标监控

Server 端机器收到的流量按性能分配，CPU 保持均衡。

QPS

CPU

4.3.2 RR4.3.2.1 吞吐数据

下表是 Server 端的吞吐数据，由测试发压 Client 端，负载均衡模式设置为 RR。在 18:46 Server 端的整体流量接近于 18:17 Server 端的整体流量。后面将重点对比这两个关键时刻的数据。

时间

18:40

18:46

19:57

20:02

20:04

20:09

总流量

967

1082

1149

1172

1263

1314

处理流量

927

991

1024

1036

1048

1047

被限流量

40

91

125

136

216

267

限流比例

4.18%

8.4%

10.92%

11.6%

17.1%

20.32%

平均 CPU 使用率

45%（部分限流）

51%（部分限流）

53%（部分限流）

54%（接近全部限流）

55%（全部限流）

55%（全部限流）

4.3.2.2 指标监控

Server 端收到的流量均衡，但是 CPU 有差异。

QPS

CPU

4.4 压测分析4.4.1 吞吐曲线

根据 4.3 节的压测数据，进行 Server 端吞吐曲线的绘制，对比 RALB 和 RR 两种负载均衡模式下的吞吐变化趋势。

import matplotlib.pyplot as pltimport numpy as np       x = [0,1,2,3,4,5,6,7,8,9,9.73,10.958,11.52,17.15,22.7]y = [0,1,2,3,4,5,6,7,8,9,9.73,10.61,10.49,10.10,9.82]  w = [0,1,2,3,4,5,6,7,8,9.674,10.823,11.496,11.723,12.639,13.141,17.15,22.7]z = [0,1,2,3,4,5,6,7,8,9.27,9.91,10.24,10.36,10.48,10.47,10.10,9.82]  plt.plot(x, y, 'r-o')plt.plot(w, z, 'g-o')plt.show()

负载均衡策略

RALB

RR

阶段一：所有机器未限流

接收 QPS = 处理 QPS，表现为 y =x 的直线

接收 QPS = 处理 QPS，表现为 y =x 的直线

阶段二：部分机器限流

不存在 RALB 根据下游 CPU 进行流量分配，下游根据 CPU 进行限流，理论上来讲，下游的 CPU 永远保持一致。所有的机器同时达到限流，不存在部分机器限流的情况。 所以在图中，不限流与全部机器限流是一个转折点，没有平滑过渡的阶段。

RR 策略，下游的机器分配得到的 QPS 一致，由于下游根据 CPU 进行限流，所以不同机器限流的时刻有差异。 相对于 RALB，RR 更早地出现了限流的情况，并且在达到限流之前，RR 的吞吐是一直小于 RALB 的。

阶段三：全部机器限流

全部机器都达到限流阈值 55% 之后，理论上，之后无论流量怎样增加，处理的 QPS 会维持不变。图中显示处理的 QPS 出现了一定程度的下降，是因为处理限流也需要消耗部分 CPU

RR 达到全部限流的时间要比 RALB 更晚。在全部限流之后，两种模式的处理的 QPS 是一致的。

4.5 压测结论

临界点：吞吐差异最大的情况，即 RALB 模式下非限流与全限流的转折点。

通过上述分析，可以知道，在 RALB 不限流与全部限流的临界点处，RR 与 RALB 的吞吐差异最大。

此时，计算得出 RALB 模式下，Server 集群吞吐提升 7.06%。

五、边界测试

通过模拟各种边界条件，来判断系统在边界条件的情况下，系统的稳定性。

边界条件

压测情形

压测结论

下游节点限流

CPU 限流

惩罚因子的调整对于流量的分配有重要影响

QPS 限流

符合预期

下游节点超时

Server 端超时每个请求，固定 sleep 1s

请求持续超时期间分配的流量基本为 0

下游节点异常退出

Server 端进程被杀死直接 kill -9 pid

杀死进程并自动拉起，流量分配快速恢复

下游节点增减

Server 端手动 Jsf 上下线

jsf 下线期间不承接流量

Server 端重启 stop + start

正常反注册、注册方式操作 Server 端进程，流量分配符合预期

六、功能上线

宿迁机房 Client 端上线配置，在所有 Server 端集群全面开启 RALB 负载均衡模式。可以看出，上线前后，Server 端的 QPS 逐渐出现分层，Server 端的 CPU 逐渐趋于统一。

上线前后 Server 端 QPS 分布

上线前后 Server 端的 CPU 分布

参考资料

1. 负载均衡技术

2. 深入浅出负载均衡

作者：京东零售 胡沛栋

来源：京东云开发者社区