一、背景
搜寻举荐算法架构为京东团体所有的搜寻举荐业务提供服务，实时返回处理结果给上游。部门各子系统曾经实现了基于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 RALB
4.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 RR
4.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()4.4.2 曲线剖析
| 负载平衡策略 | 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.深入浅出负载平衡
作者：京东批发 胡沛栋
起源：京东云开发者社区