广告在线模型系统负载均衡策略实践

一、背景简介

1.1、现状

•实际生产环境中，复杂业务系统对分布式服务集群架构的依赖。

•服务集群异质化节点的容器化部署，机器性能超卖现象不可避免、性能不均情况时有发生。

•服务集群各硬件组件出错率不可避免[1]，上层业务相关的应用软件系统需考虑容错设计。

•大促流量分布变化难以准确预见，系统服务稳定性与机器资源成本之间需进行妥善权衡。

1.2、问题

•集群内负载不均，整体资源利用率低。

•单节点过载容易触发集群整体扩容。

•节点偶发硬件（CPU、网卡、内存等）异常影响业务服务整体可用率。

•大促等分布多变的线上流量容易导致集群服务稳定性问题。

1.3、需求

设计合理的负载均衡策略（LB）来提高服务集群的资源利用率和服务稳定性，以有效应对大促复杂多变的流量对系统服务的冲击。

二、理论基础

2.1、通用负载均衡问题

负载均衡是提高系统资源利用率和并行计算性能的一个关键技术，可分为静态和动态两类。如果负载可以在运行之前确定并事先将负载划分，则属于静态负载均衡问题；若只能在运行时测量负载并动态确定负载划分，则属于动态负载均衡（DLB）问题。

对于给定的一个包含计算和通讯的任务集合，以及一组通过一定拓扑连接起来的计算机，求解任务到计算机的一个映射，使得求解该问题的时间最小，这就是负载均衡的目标[2]。

2.2、负载均衡策略汇总

2.2.1、分布式策略

实现分布式的负载均衡可有多种策略，其中一个基本策略就是近邻法。在该策略中，每个处理器和相邻处理器交换负载，实现和相邻处理器间的负载均衡，并经过多次迭代达到全局负载均衡。它主要包括扩散法、维交换法（DEM）和梯度法（GM）。

2.2.2、集中式策略

在集中式策略中，每个处理器的计算负载和通讯发送到一个指定的处理器，该处理器负责收集、处理全局的负载信息，并做出全局的负载均衡决策。

2.2.3、混合/层次策略

为了最小化负载均衡开销，一些负载均衡方法重在研究如何根据层次拓扑结构来构建一个层次树的问题。利用层次树进行多级负载均衡，根据层次化的网络结构将处理器划分为多个组（均衡域），由这些均衡域组织成一个层次结构。在层次结构中的每一层，相邻的域间进行负载均衡，并且从底层至上层，在每层执行相同的域间负载均衡过程，最后在根节点完成全局的负载均衡。

2.3、负载均衡算法层级

2.3.1、系统级负载均衡

•DNS负载均衡

DNS负载均衡是一种使用DNS（域名系统）来分散到达特定网站的流量的方法。基本上，它是通过将一个域名解析到多个IP地址来实现的。当用户试图接入这个域名时，DNS服务器会根据一定的策略选择一个IP地址返回给用户，以此来实现网络流量的均衡分配。

•Nginx负载均衡

Nginx是一种高效的Web服务器/反向代理服务器，它也可以作为一个负载均衡器使用。在负载均衡配置中，Nginx可以将接收到的请求分发到多个后端服务器上，从而提高响应速度和系统的可靠性。Nginx是负载均衡比较常用的方案。

•LVS/F5+Nginx

Nginx一般用于七层负载均衡，其吞吐量是有一定限制的，如果网站的请求量非常高，还是存在性能问题。为了提升整体吞吐量，会在DNS和Nginx之间引入接入层，如使用LVS（软件负载均衡器)、F5（硬件负载均衡器）可以做四层负载均衡，即首先DNS解析到LVS/F5，然后LVS/F5转发给Nginx，再由Nginx转发给后端真实服务器。

2.3.2、应用级负载均衡

•Ribbon负载均衡

Ribbon是一个开源的、基于HTTP和TCP的客户端负载均衡工具，它提供了一个简单的、基于配置的负载均衡策略，其通过在客户端上运行来选择最佳的服务器。Ribbon提供了多种负载均衡策略，如随机、轮询、最少活跃调用等，可以根据实际需求选择合适的策略。当客户端连接到服务器后，Ribbon会根据服务器的响应速度、负载情况等因素进行评估，并动态调整选择的服务器。这种方式可以实现更灵活的负载均衡，提高系统的可用性和性能。

•Dubbo负载均衡

Dubbo是一种高性能的分布式服务框架，它提供了一套完整的服务治理解决方案。其中，负载均衡是Dubbo框架的重要特性之一，它可以帮助我们实现服务调用的负载均衡，提高系统的性能和可靠性。通过配置文件或编程方式，我们可以基于Dubbo框架在多个服务提供者之间灵活地进行请求分发，以实现请求的负载均衡。具体地，其提供了多种负载均衡策略，包括随机、轮询、最少活跃调用等。

三、方案实践

3.1、模型系统负载均衡策略演进历程

图3-1. 在线模型系统服务常见架构

3.1.1、常见负载均衡策略

•静态负载均衡技术

◦轮询（Round Robin）、随机（Random）等；

◦处理策略简单、时效性高，但依赖集群节点同质化假设。

•动态负载均衡技术

◦最小链接数（Least Connections）、最低时延（Locality Aware）等；

◦基于节点相关状态信息反馈，实时调整分流策略，进而达到期望指标的均衡。

3.1.2、演进一：LB策略适配服务集群业务特点

•在线特征服务集群

◦在线广告业务场景：User & Sku数量庞大、特征类型丰富。

◦集群Cache机制保证特征处理时效性，并降低相关依赖服务（如：SKU服务集群）请求压力。

◦LB策略需保证一定的Cache命中率：基于用户PIN的一致性Hash策略[3] 。

•模型预估服务集群

◦在线推理过程对请求之间透明，常规随机Random策略即可。

3.1.3、演进二：LB策略引入"可用率"目标，增强服务稳定性

•问题现象

◦集群单节点异常，个别异常节点可用率影响集群整体可用率。

◦线上突发流量变化，影响服务稳定性，甚至导致服务不可用，服务集群缺乏自动防护。

•策略升级

◦静态策略 → 动态策略：引入集群节点实时可用率统计指标。

◦服务可用率指标直接控制节点流量分配、请求降级/恢复：（1）可用率低于集群平均可用率阈值节点减少分流比例；（2）集群平均可用率低于阈值，开启降级防护，并周期性尝试降级恢复。

3.1.4、演进三：LB策略添加"异构硬件利用率"（CPU/GPU）目标，提高资源利用率

•问题现象

◦集群异质化节点部署，各节点资源利用不均。

◦集群木桶效应严重，个别节点性能受限触发集群整体扩容。

•策略升级

◦单目标策略 → 多目标分级策略：进一步添加集群节点CPU/GPU资源利用统计指标。

◦服务可用率指标为主，CPU/GPU资源利用率指标为辅。在服务可用率满足的条件下，进一步调节流量分配比例，实现集群CPU/GPU资源利用率的最大化。

3.1.5、演进四：LB实现框架统一，支撑广告系统全链路算力的最优调度

•问题现象

◦模型系统内部各模块LB框架各异，维护开发成本较高。

◦模型系统内、外服务之间的不同LB框架无法复用，阻碍广告系统全链路算力的最优化实现。

•策略升级

◦模块化重构LB策略相关逻辑实现，并统一LB框架，进而打通模型系统内、外服务之间的算力孤岛。

3.1.6、总结

•生产环境复杂多变，进而要求LB策略的设计对系统影响稳定且结果可预见。

•业务服务指标和集群性能指标之间相互影响，单目标均衡策略无法两者兼顾。

•多目标均衡策略必然引入成倍的决策复杂度：k（均衡目标数）* n（C端集群）*m（S端集群）。

•多目标均衡分级：不同目标间相互耦合，难以兼顾！总需要有一个主目标作为兜底。

•均衡目标与均衡策略之间的适配&兼容：（1）多目标（CPU+可用率）、多负载均衡策略（Random、ConsistentHash）适配简单；（2）新LB策略对旧LB均衡策略的兼容性（CPU均衡对一致性Hash原则的兼容性）。

3.2、"服务可用率+资源利用率"双目标联合均衡LB策略

该策略以服务可以率目标为兜底，基于待优化资源利用率目标的期望取值，将任意时刻整个集群的所有节点划分为 "负反馈列表（refuse list） " 和 "正反馈列表（accept list） " 两部分，且节点实际取值与期望取值之间的数值差异表征了当前节点在该优化目标上的"均衡度"。同时，负反馈列表中的节点采用减少分流比例策略，正反馈列表中的节点则增加分流比例，而分流策略的具体变化比例由当前节点的均衡度来决定。