前阵子在帮一个朋友排查网关抖动问题聊到负载均衡时他随口问了一句“咱这轮询用得挺好啊为什么要搞那么复杂” 我当时笑了笑回了一句“等你遇到一个节点被慢查询堵死、其他节点闲得发慌的时候你就明白了。”负载均衡说白了就一件事把进来的流量合理地分给后面一堆节点去处理。但“合理”这两个字才是真正麻烦的地方。市面上成熟的负载均衡器——不管是用 Nginx 做七层转发、用数据库中间件做读写分离还是在微服务网关里挑实例——内置策略翻来覆去就那几种但每种策略背后都有它的适用边界和隐含假设。这篇文章我打算把常用策略一次性捋清楚再重点聊聊一个很多人卡住的问题当内置策略都不够用的时候怎么设计一套自己的策略如果你是刚接触网关、微服务或者高可用架构的新人这篇能帮你建立对负载均衡策略的完整认知如果你已经在用 Nginx、网关或自研代理但总觉得流量分配“差点意思”这篇里关于自定义策略的设计方法和踩坑经验应该能给你一些直接能用的思路。1. 常用负载均衡策略全盘点原理、适用场景与典型坑点1.1 轮询与加权轮询最基础的平权方案轮询Round Robin是所有策略里最直觉的一种请求按顺序轮流发给每个后端节点A、B、C、A、B、C循环往复。它最大的优点就是简单不需要关心节点当前状态也不需要额外采集数据只要节点列表不变分发就是绝对公平的。加权轮询Weighted Round Robin是它的升级版。现实中后端节点很少规格完全一致可能是8核16G和4核8G混着部署或者新老机器混用。这时候给每个节点配一个权重比如新机器weight3老机器weight1调度器按权重比例分配流量让算力大的节点多接请求。但轮询和加权轮询有一个共同的问题它们都是静态策略调度时完全不看节点实际状态。就算某个节点已经CPU跑满了、内存快爆了轮询照样会把新请求送过来该卡还是卡该超时还是超时。所以这类策略更适合后端节点处理能力均衡、请求耗时可预测的场景比如纯静态文件服务、无状态计算任务。这里补充一个容易踩坑的小细节加权轮询不同实现方式的“平滑性”差别很大。有的实现是纯概率式加权每次都按权重比例随机挑有的是平滑加权轮询比如Nginx的实现。平滑加权轮询的目的是避免短时间内同一个高权重节点被连续集中命中如果自己实现加权轮询千万别粗暴地“先发给权重最大的节点N次再发给下一个”那样会在单节点上制造明显的流量毛刺。1.2 最少连接与加权最少连接动态感知的调度最少连接Least Connections开始引入“动态”的概念了调度器会记录每个后端节点当前活跃连接数新请求到达时优先发给活跃连接数最少的节点。这个策略在处理长连接、请求处理时间差异大的场景下比轮询均衡得多因为它是真正在看“谁现在最闲”。不过最少连接有一个隐蔽的坑——连接数少不等于负载低。举个例子A节点上只有1个连接但这是个复杂的SQL聚合查询可能要跑两秒钟B节点上挂着5个连接但全是Redis的快速读写每个只需要几毫秒。按最少连接策略调度器会不停地把新请求塞给A节点结果A节点越积越多响应越来越慢。如果后端是数据库中间件或者复杂业务服务这个坑会踩得非常惨。加权最少连接Weighted Least Connections在这个思路上加上了权重维度在算“谁最闲”的时候把节点能力差异也考虑进去。但仍然没有解决刚才那个问题——它看的是“数量”而不是“压力”。连接数这个指标太粗糙只能当入门级动态策略来用。1.3 IP哈希与一致性哈希会话保持与扩容难题IP哈希IP Hash的做法是对客户端IP做哈希计算把特定IP的请求固定映射到同一个后端节点。典型场景是会话保持早期很多应用把用户会话存在单机内存里没有做Session共享如果同一个用户每次请求落到不同节点登录态就丢了。IP哈希能用最简单的方式解决这个问题——同一个用户永远打同一个节点。但IP哈希有三个天生缺陷IPv4地址网段分布不均匀某些大流量来源会集中在一个网段或一个IP上比如公司出口NAT哈希之后可能把大量流量都砸向同一个节点直接把它打爆。移动互联网环境下客户端IP频繁变化Wi-Fi切4G、弱网重连等会话保持效果大打折扣。节点增减会导致映射关系大规模失效普通哈希取模的方式节点从3个变成4个时大部分流量都会被重新映射到新节点如果节点上有本地缓存命中率会骤降。一致性哈希Consistent Hashing就是为了解决最后这个问题出现的。它的核心是构建一个哈希环节点和请求都映射到环上每个请求由顺时针遇到的第一个节点处理。节点变化时只需要迁移环上相邻区间的数据影响范围大大缩小。这也是很多缓存中间件和自研网关在节点路由上的默认选择。不过一致性哈希也不是银弹——它只能保证“哈希结果的稳定性”并不保证“节点之间的负载均衡”。如果节点在环上分布不均匀照样会出现某几个节点接走大量请求的情况所以工程实践里一般会引入虚拟节点技术给每个真实节点在环上多放几百个影子节点来抹平分布差异。1.4 响应时间与自适应类策略让数据说话再往下走就是一边调度一边收集反馈数据的策略了。最快响应时间Fastest Response Time会统计每个节点最近一段时间处理请求的平均响应时间新请求优先交给响应最快的节点。它的理念很直接响应快说明现在闲交给它处理整体体验最好。这类策略的实际效果依赖于统计数据的可靠性。如果统计窗口太短抖一下就频繁切换目标如果窗口太长又不能及时反映节点当前状态。实践中一般会配合滑动窗口和最低采样数来避免“样本太少但是数据看起来很好”的情况。一些商业负载均衡器还支持自适应策略把节点的CPU、内存、磁盘IO、网络带宽、当前连接数、平均响应时间全部汇总成一个综合负载指标再按指标倒序分发流量。这种策略最理想但对监控数据采集的完整度要求也最高。我在下面整理了一张对比表把常用策略放在一起对照着看会非常直观策略名称核心原理是否动态典型适用场景最容易踩的坑轮询依次轮流分发否同配置无状态服务节点负载不均时仍然硬塞加权轮询按权重比例分发否集群节点规格混合权重分配拍脑袋不够准最少连接优先发给活跃连接最少节点是HTTP长连接、数据库连接池连接数≠真实负载IP哈希按来源IP固定映射否会话保持大网段IP导致单点热点一致性哈希哈希环路由否分布式缓存、路由寻址环分布不均匀需虚拟节点最快响应时间统计历史响应耗时是接口RT差异大的业务统计窗口不合理导致调度抖动2. 内置策略的四个典型翻车场景为什么需要自定义讲了这么多内置策略的“坑”有些人可能会想那我把这些策略组合着用不就行了比如外层用IP哈希做会话保持内层再用最少连接动态分发。这种做法在简单场景下确实能解决问题但当你面对的是真实生产环境时组合内置策略通常解决不了“调度意图”层面的问题。下面分享四个我之前实际遇到过的场景看完你就能理解为什么一定要走到自定义这一步。2.1 翻车场景一轮询把流量打到了热点节点某次我负责的一个业务集群做了垂直拆分把接口分成了普通查询和重度计算两类。当时CLB容器负载均衡默认配的是加权轮询所有节点权重一样。结果每天下午业务高峰集群里总有一两个节点CPU冲到90%以上其他节点却只有30%。查了半天才发现重度计算接口虽然只占总量的20%但它独占资源轮询策略把这些重计算请求相对均匀地撒给了所有节点——这本身没问题——但是重计算请求一旦落到某个节点上该节点的资源占用会瞬间飙升而轮询完全感知不到仍然继续往这个热点节点塞新请求。这个场景要的不是“哪种策略更均衡”而是要让调度器能识别并避开正在过载的节点内置策略里没有一种直接提供这个能力。2.2 翻车场景二最少连接被慢请求拖垮另外一次是在数据库代理场景。我们用最少连接策略做读写分离中间件假设后面挂了6个数据库实例。上线初期一切正常后来某天DBA在其中一个实例上跑了一个超长的分析任务占用了大量连接资源。按最少连接的逻辑这个实例因为“空闲连接”最多反而成了首选目标新请求继续涌入直接把业务拖垮了。问题根源在于**最少连接只是连接数量的守恒不是资源耗用的守恒。**数据库连接池里的连接数量恒定不代表每个连接承载的负载是恒定的——一个跑两分钟的慢查询和一个跑两毫秒的快查询在“连接数”这个指标上没有任何区别。只有引入真实的资源指标比如活跃线程数、当前查询耗时、锁等待时间等才能反映实例的真实压力而这些指标负载均衡器默认是拿不到的必须通过扩展链路自己去采集。2.3 翻车场景三IP哈希在移动网络下的尴尬还有一个经典场景是移动端API网关客户端通过公网访问。一开始我们想用IP哈希做最简单的会话保持但上线后很快就发现问题大量用户来自运营商NAT网关后的同一个出口IP这些IP在哈希表上可能恰好落在同一个节点直接把那个节点打到CPU满载。更麻烦的是用户切网Wi-Fi切5G、飞行模式恢复后IP就变了会话保持目标也没达到。这里核心矛盾是IP哈希假设“一个IP是一个稳定的客户端”但真实网络环境里这个假设经常不成立。这种情况要么换用基于Cookie、Token等业务标识的会话保持方案要么就需要自定义一个策略——比如对IP先做一层预处理截取C段、配合端口哈希等再把业务标识作为附属维度一起参与调度。2.4 翻车场景四统一策略无法表达业务优先级最让我决定“必须自定义”的一次经历是一个混合业务场景的网关同一套网关既要转发线上交易接口延迟敏感如果后端出问题必须立刻切流量又要转发批量离线任务对延迟不太敏感但要求尽量不丢。统一用最少连接离线任务会把连接数低但CPU其实快被打满的节点选走等到真实交易请求过来时节点已经无力处理。这类场景的关键词是**“多优先级感知”**。调度策略需要知道流量的来源与业务等级VIP客户请求应当优先路由到低负载节点普通请求可以接受稍差一点的服务离线任务则要主动避开繁忙节点。这个意图无法用任何单一内置策略完整表达只能通过自定义策略在调度算法里加入“业务等级权重”和“按等级差异化打分”的逻辑。3. 自定义策略的设计框架从业务目标到打分函数聊完了为什么需要自定义下面进入正题该怎么做。自定义负载均衡策略没有想象中那么玄它的本质其实就是三步——定目标、采指标、算选择。把这三件事想清楚自定义策略就成了一大半。3.1 先把目标说清楚很多人在设计自定义策略下手第一步就错了他们急着去写算法、调参却忘了先回答一个问题你到底想让调度器优化什么目标选项通常绕不开这几个最小化平均响应时间让每个请求都快。最小化长尾延迟P99让最慢的那批请求也可控。最大化整体吞吐量在资源有限的情况下尽量多处理请求。成本优先优先使用便宜的节点比如竞价实例贵节点兜底。稳定性优先宁可牺牲一点平均性能也要避免任何单节点过载。目标不同自定义方向的差别非常大。想做成本优先你的打分函数里就要给便宜节点加较大权重贵节点只有当便宜节点全满时才被选到想做P99优化你就要重点采集响应延迟的分位数而不是平均值还要设计快速熔断机制。如果一上来就想着“综合一下”最后往往什么都优化不好。我习惯的做法是在写第一行代码之前先输出一句明确的调度策略描述比如“在交易流量高峰期优先将请求调度到CPU使用率低于60%、最近5分钟平均RT小于200ms的节点并在节点连续3次健康检查失败时快速摘除”。这句话写清楚了后面的所有设计都是围绕它展开的。3.2 指标采集、归一化与滑动窗口目标确定之后下一步是确定调度器能看到哪些指标。常见可选指标包括CPU使用率直接反映计算资源压力。内存使用率内存吃紧往往伴随GC频繁或OOM风险。活跃连接数反映并发处理压力。平均响应时间RT反映服务自身处理能力和队列积压情况。队列长度衡量请求在节点上排队等待的时间。带宽/磁盘IOIO密集场景下比CPU更有代表性。但不同指标的量纲完全不同——CPU是0到100的百分数RT可能是几十到几千毫秒连接数可能是几个到几百个。如果直接拿这些数字做加权求和最后一定是量纲大的指标主导全部决策。所以自定义策略里几乎一定会做一次归一化处理。最简单的归一化是线性归一化把指标映射到0到1区间(当前值 - 最小值) / (最大值 - 最小值)。但线性归一化对离群值非常敏感如果一个节点的RT飙到5000ms其他节点都是200ms最高值一来所有节点的归一化结果都会变得很极端。更稳的办法是用百分位映射比如把RT的历史数据先画出P50、P90、P99然后根据当前RT落在哪个区间打分落在P99以上直接给最低分甚至标记为不健康。这种打分方式对异常值更鲁棒。还有一个新手容易忽略的点指标采样的时间粒度。如果你从监控系统拿到的节点CPU利用率是5分钟粒度的平均值用它来做毫秒级的调度决策相当于拿着昨天的天气预报决定今天出门穿不穿外套——数据早就过时了。更合理的做法是让节点Agent每隔几秒上报一次当前状态调度器端再对这些散点做滑动窗口平滑比如取最近30秒的均值既滤掉了瞬时抖动又能保证数据新鲜度。3.3 打分公式与加权随机选择当多个指标都归一化好之后就可以设计打分公式了。预设一个最简单的场景我们要避免高CPU、高RT的节点同时兼顾连接数。打分逻辑可以这样写def calculate_score(node): # node.cpu_normalized: 0~1越大压力越大 # node.rt_normalized: 0~1越大响应越慢 # node.conn_normalized: 0~1越大连接数越多 load_score (0.5 * node.cpu_normalized 0.3 * node.rt_normalized 0.2 * node.conn_normalized) # 希望选中压力小的节点所以取负相关 return 1.0 - load_score这个公式表达的意思非常清楚CPU压力权重最高0.5响应时间次之0.3连接数参考一下0.2。拿到每个节点的得分之后怎么选择很多人第一反应是“选得分最高的那个”。但在实践中最好不要做最大者通吃因为这样会造成少量得分最高的节点被集中打满流量反而引发新的热点。更稳定的做法是加权随机得分高的节点获得更高的被选概率但得分略低的节点也有一定概率被选中。这样流量分配会呈现一种自然的概率分布既偏向好节点又不至于把所有鸡蛋放在一个篮子里。3.4 兜底与降级设计自定义策略最容易翻车的环节不在策略本身而在策略失效时你怎么办。举个例子如果你采集指标的Agent挂了或者节点上报接口超时导致所有节点的指标数据都为空这时候你的打分公式怎么算我见过不少实现直接把这类节点当成0分处理结果就是所有流量都被打到一个节点上直接雪崩。正确的做法是为“数据缺失”设置独立的降级路径当某个节点指标数据缺失或过期超过阈值时把它从候选集合中临时摘除或者给它一个保守的默认分数比如所有节点得分的平均值而不是默认给0分。同样的道理也适用于健康检查。如果你依赖HTTP健康检查来摘除故障节点健康检查本身也有误报概率。在关键场景里我会把健康检查和调度策略分开处理健康检查只负责“硬摘除”明显不可用的节点立刻下线调度打分只负责“软避让”压力大的节点降低被选概率。这样一个节点即使被打出低分也还保留一点概率接收流量不至于因为监控误报导致节点完全空转。4. 三条可落地的自定义实现路径方法框架搭好之后最常被问的问题就是我到底应该在哪里写我的自定义策略这一节我给出三条实际可落地的路径按实施成本从低到高排列你可以根据自己的技术栈选。4.1 路径一OpenResty Lua快速定制如果你已经在用Nginx或OpenResty做七层网关那么最轻量级的自定义方式就是写在OpenResty的balancer_by_lua阶段。这个阶段允许你完全接管upstream节点的选择逻辑不再局限于Nginx自带的round_robin、least_conn等指令。下面是一段简化示例展示了如何在OpenResty里自定义一个简单的加权随机均衡器权重来自后端节点上报的活跃连接数-- balancer_by_lua_block 中调用 local nodes { { pool backend_a, conn 12, capacity 100 }, { pool backend_b, conn 5, capacity 100 }, { pool backend_c, conn 80, capacity 100 }, } local function score(node) -- 连接数越低得分越高 return math.max(0.1, 1 - node.conn / node.capacity) end -- 计算所有节点的得分比例然后按比例随机选 local total_weight 0 for _, n in ipairs(nodes) do n.weight score(n) total_weight total_weight n.weight end local r math.random() * total_weight local cursor 0 local selected_pool for _, n in ipairs(nodes) do cursor cursor n.weight if r cursor then selected_pool n.pool break end end -- 选中之后设置当前请求要转发的upstream peer if selected_pool then ngx_balancer.set_current_peer(selected_pool) end这个实现里的核心逻辑是节点连接数越少、离容量上限越远得分就越高被选中的概率也越大。真正落地时conn指标通常来源于一个共享缓存比如ngx.shared.DICT由后端的Agent或采集任务定时写入。OpenResty方案的最大优点是不用改后端任何代码纯网关层改造上线风险低非常适合快速验证自定义策略的效果。需要注意的一点balancer_by_lua是在每个请求的upstream选择阶段执行的里面的逻辑必须足够轻量。不要在现网请求链路上做重计算、不要远程调用Redis获取指标每条请求都访问Redis会把Redis拖垮。正确的姿势是让采集器定时把节点状态同步到一个共享内存字典Lua代码只从共享内存里读、做纯内存计算整个过程控制在微秒级别。4.2 路径二网关/框架扩展点如果业务跑在Java技术栈用的又是Spring Cloud这样自带负载均衡的微服务框架那更自然的做法是在客户端负载均衡器层面扩展。Spring Cloud中的LoadBalancer接口就是设计给开发者做自定义的——你可以实现自己的ReactiveLoadBalancer拿到当前可用的服务实例列表然后按自己的逻辑挑一个实例返回。这类扩展的实现思路依然是那套“打分加权随机”的办法。我写过的一个简化版本是服务实例的元数据里带了权重配置和实时的CPU水位客户端在做服务发现时拿到这些数据然后走一遍打分逻辑即可。因为客户端负载均衡是拿注册中心里的实例列表来选的它天然就能感知到实例的心跳状态配合自定义权重就能实现非常灵活的调度策略。Dubbo这类RPC框架也提供类似的SPI扩展点很多团队在内部就是通过自定义LoadBalance来做到按机房优先、按调用链级别优先级路由的。如果你已经在框架里做了服务注册发现优先使用框架提供的扩展点而不是再架设一层独立的网关——不然两层负载均衡叠加理解和排查问题的成本都会翻倍。4.3 路径三自研调度器完整实现如果现有的网关、框架都无法满足你的场景比如调度逻辑极度特殊、需要依赖一套深度定制的指标体系那最后一条路就是自己写一个独立的调度器。这个调度器最基本的能力就是拿到所有节点状态根据策略算出一个目标节点再把结果返回给上层调用方。下面给出一个完整的、可直接跑通的最小调度器核心实现用的Python伪代码风格方便理解class Node: def __init__(self, node_id, cpu, rt, conn, healthyTrue): self.node_id node_id self.cpu cpu # 0~100 self.rt rt # 毫秒 self.conn conn self.healthy healthy class CustomBalancer: def __init__(self, nodes, window_size30): self.nodes nodes self.window_size window_size self.rt_history {n.node_id: [] for n in nodes} def normalize(self, value, low, high): # 线性归一化并做边界裁剪 if high low: return 0.0 return max(0.0, min(1.0, (value - low) / (high - low))) def safe_rt(self, node): # 如果某个节点没有RT历史数据用所有节点的平均RT兜底 if len(self.rt_history[node.node_id]) 0: all_rt [self.rt_history[n.node_id] for n in self.nodes] all_rt [x for sublist in all_rt for x in sublist] if not all_rt: return 500 # 完全冷启动给一个保守值 return sum(all_rt) / len(all_rt) recent self.rt_history[node.node_id][-self.window_size:] return sum(recent) / len(recent) def score(self, node): if not node.healthy: return 0.0 cpu_score 1 - self.normalize(node.cpu, 0, 100) rt_score 1 - self.normalize(self.safe_rt(node), 0, 5000) conn_score 1 - self.normalize(node.conn, 0, 1000) # 权重CPU最重要RT其次连接数参考 return 0.5 * cpu_score 0.3 * rt_score 0.2 * conn_score def choose(self): scores [self.score(n) for n in self.nodes] total sum(scores) if total 0: # 兜底全部不可用或全为0分时随机选一个健康的 import random healthy_nodes [n for n in self.nodes if n.healthy] return random.choice(healthy_nodes or self.nodes).node_id import random r random.uniform(0, total) cursor 0 for n, s in zip(self.nodes, scores): cursor s if r cursor: return n.node_id return self.nodes[-1].node_id这份代码里有两个值得留意的设计一是safe_rt函数在节点没有任何历史RT数据时会退回使用全集群平均RT避免冷启动节点被当成“零RT”而疯狂接流量二是choose的最后兜底逻辑当所有节点都不可用时返回一个随机健康候选宁可短暂分配错误也不能让整个请求链路空转。这两个细节在自研调度器里几乎是必备的安全阀。5. 上线前的实测与避坑清单自定义策略写完之后不要立刻推到生产环境。我在这个环节踩过的坑说几个有代表性的。5.1 指标新鲜度决定策略上限有一次我把节点CPU数据采集频率设置为每分钟一次策略在压测环境表现很好但上线后经常看到有节点被打满另一些却在闲置。后来发现原因很简单压测环境机器少、指标刷新快一旦上了生产机器增多、上报间隔变长调度器看到的CPU数据已经滞后了一分钟。在这期间某个节点可以接收大量请求瞬间冲到100%但调度器还拿着旧数据把它当最优节点继续猛推流量。解决方案是把采集周期压缩到5秒一报同时调度端对超过10秒没有更新的节点临时降权。宁可少接一点流量也不能拿过期数据做决策。5.2 冷启动与默认值新扩容一个节点进入集群时它的RT历史是空的连接数是0CPU也是0。很多自定义策略会把这个节点当成“完美节点”呼啦一下把所有流量都切过去结果新节点被瞬时打瘫。正确的做法是为新节点加一个冷启动保护期比如前两分钟只给它分配正常流量的20%同时用一个保守默认分数参与打分而不是最高分。等它积累了足够的状态数据之后再逐步恢复它的正常权重。这个思想和熔断很像没有足够数据做决策时永远选择最保守的方案。5.3 全链路压测与对照验证上线之前至少做两个验证一是用生产流量的录制回放做全链路压测对比默认策略和自定义策略下的吞吐量、P99延迟、节点CPU均衡度二是在灰度环境里做A/B对照——把集群的一半流量走默认策略一半走自定义策略观察一段时间。其次压测过程中要故意模拟故障把某节点直接kill掉、把某个节点CPU压到满负荷看自定义策略是否能快速感知并避开故障节点。我习惯把自定义策略的调度决策全部打日志哪怕是A/B阶段。这样一旦出问题可以直接回放每一个请求当时被哪个节点接收、为什么选这个节点、当时集群状态是什么样。有这层数据兜底排查问题会快很多。最后再分享一条我对自定义策略的个人看法能用内置策略解决的场景尽量别自定义。自定义意味着你要自己维护指标采集、逻辑计算、兜底降级、故障容忍这一整套链路复杂度是指数级上升的。只有当业务意图确实无法用现有策略表达比如多优先级调度、资源感知路由、跨节点成本优化才值得走自定义这条路。但如果真走到了这一步按照“定目标、采指标、打分选节点、加兜底”这个框架来做整个事情不会失控——这也是我自己踩过一遍坑之后沉淀下来的经验。
前阵子在帮一个朋友排查网关抖动问题聊到负载均衡时他随口问了一句“咱这轮询用得挺好啊为什么要搞那么复杂” 我当时笑了笑回了一句“等你遇到一个节点被慢查询堵死、其他节点闲得发慌的时候你就明白了。”负载均衡说白了就一件事把进来的流量合理地分给后面一堆节点去处理。但“合理”这两个字才是真正麻烦的地方。市面上成熟的负载均衡器——不管是用 Nginx 做七层转发、用数据库中间件做读写分离还是在微服务网关里挑实例——内置策略翻来覆去就那几种但每种策略背后都有它的适用边界和隐含假设。这篇文章我打算把常用策略一次性捋清楚再重点聊聊一个很多人卡住的问题当内置策略都不够用的时候怎么设计一套自己的策略如果你是刚接触网关、微服务或者高可用架构的新人这篇能帮你建立对负载均衡策略的完整认知如果你已经在用 Nginx、网关或自研代理但总觉得流量分配“差点意思”这篇里关于自定义策略的设计方法和踩坑经验应该能给你一些直接能用的思路。1. 常用负载均衡策略全盘点原理、适用场景与典型坑点1.1 轮询与加权轮询最基础的平权方案轮询Round Robin是所有策略里最直觉的一种请求按顺序轮流发给每个后端节点A、B、C、A、B、C循环往复。它最大的优点就是简单不需要关心节点当前状态也不需要额外采集数据只要节点列表不变分发就是绝对公平的。加权轮询Weighted Round Robin是它的升级版。现实中后端节点很少规格完全一致可能是8核16G和4核8G混着部署或者新老机器混用。这时候给每个节点配一个权重比如新机器weight3老机器weight1调度器按权重比例分配流量让算力大的节点多接请求。但轮询和加权轮询有一个共同的问题它们都是静态策略调度时完全不看节点实际状态。就算某个节点已经CPU跑满了、内存快爆了轮询照样会把新请求送过来该卡还是卡该超时还是超时。所以这类策略更适合后端节点处理能力均衡、请求耗时可预测的场景比如纯静态文件服务、无状态计算任务。这里补充一个容易踩坑的小细节加权轮询不同实现方式的“平滑性”差别很大。有的实现是纯概率式加权每次都按权重比例随机挑有的是平滑加权轮询比如Nginx的实现。平滑加权轮询的目的是避免短时间内同一个高权重节点被连续集中命中如果自己实现加权轮询千万别粗暴地“先发给权重最大的节点N次再发给下一个”那样会在单节点上制造明显的流量毛刺。1.2 最少连接与加权最少连接动态感知的调度最少连接Least Connections开始引入“动态”的概念了调度器会记录每个后端节点当前活跃连接数新请求到达时优先发给活跃连接数最少的节点。这个策略在处理长连接、请求处理时间差异大的场景下比轮询均衡得多因为它是真正在看“谁现在最闲”。不过最少连接有一个隐蔽的坑——连接数少不等于负载低。举个例子A节点上只有1个连接但这是个复杂的SQL聚合查询可能要跑两秒钟B节点上挂着5个连接但全是Redis的快速读写每个只需要几毫秒。按最少连接策略调度器会不停地把新请求塞给A节点结果A节点越积越多响应越来越慢。如果后端是数据库中间件或者复杂业务服务这个坑会踩得非常惨。加权最少连接Weighted Least Connections在这个思路上加上了权重维度在算“谁最闲”的时候把节点能力差异也考虑进去。但仍然没有解决刚才那个问题——它看的是“数量”而不是“压力”。连接数这个指标太粗糙只能当入门级动态策略来用。1.3 IP哈希与一致性哈希会话保持与扩容难题IP哈希IP Hash的做法是对客户端IP做哈希计算把特定IP的请求固定映射到同一个后端节点。典型场景是会话保持早期很多应用把用户会话存在单机内存里没有做Session共享如果同一个用户每次请求落到不同节点登录态就丢了。IP哈希能用最简单的方式解决这个问题——同一个用户永远打同一个节点。但IP哈希有三个天生缺陷IPv4地址网段分布不均匀某些大流量来源会集中在一个网段或一个IP上比如公司出口NAT哈希之后可能把大量流量都砸向同一个节点直接把它打爆。移动互联网环境下客户端IP频繁变化Wi-Fi切4G、弱网重连等会话保持效果大打折扣。节点增减会导致映射关系大规模失效普通哈希取模的方式节点从3个变成4个时大部分流量都会被重新映射到新节点如果节点上有本地缓存命中率会骤降。一致性哈希Consistent Hashing就是为了解决最后这个问题出现的。它的核心是构建一个哈希环节点和请求都映射到环上每个请求由顺时针遇到的第一个节点处理。节点变化时只需要迁移环上相邻区间的数据影响范围大大缩小。这也是很多缓存中间件和自研网关在节点路由上的默认选择。不过一致性哈希也不是银弹——它只能保证“哈希结果的稳定性”并不保证“节点之间的负载均衡”。如果节点在环上分布不均匀照样会出现某几个节点接走大量请求的情况所以工程实践里一般会引入虚拟节点技术给每个真实节点在环上多放几百个影子节点来抹平分布差异。1.4 响应时间与自适应类策略让数据说话再往下走就是一边调度一边收集反馈数据的策略了。最快响应时间Fastest Response Time会统计每个节点最近一段时间处理请求的平均响应时间新请求优先交给响应最快的节点。它的理念很直接响应快说明现在闲交给它处理整体体验最好。这类策略的实际效果依赖于统计数据的可靠性。如果统计窗口太短抖一下就频繁切换目标如果窗口太长又不能及时反映节点当前状态。实践中一般会配合滑动窗口和最低采样数来避免“样本太少但是数据看起来很好”的情况。一些商业负载均衡器还支持自适应策略把节点的CPU、内存、磁盘IO、网络带宽、当前连接数、平均响应时间全部汇总成一个综合负载指标再按指标倒序分发流量。这种策略最理想但对监控数据采集的完整度要求也最高。我在下面整理了一张对比表把常用策略放在一起对照着看会非常直观策略名称核心原理是否动态典型适用场景最容易踩的坑轮询依次轮流分发否同配置无状态服务节点负载不均时仍然硬塞加权轮询按权重比例分发否集群节点规格混合权重分配拍脑袋不够准最少连接优先发给活跃连接最少节点是HTTP长连接、数据库连接池连接数≠真实负载IP哈希按来源IP固定映射否会话保持大网段IP导致单点热点一致性哈希哈希环路由否分布式缓存、路由寻址环分布不均匀需虚拟节点最快响应时间统计历史响应耗时是接口RT差异大的业务统计窗口不合理导致调度抖动2. 内置策略的四个典型翻车场景为什么需要自定义讲了这么多内置策略的“坑”有些人可能会想那我把这些策略组合着用不就行了比如外层用IP哈希做会话保持内层再用最少连接动态分发。这种做法在简单场景下确实能解决问题但当你面对的是真实生产环境时组合内置策略通常解决不了“调度意图”层面的问题。下面分享四个我之前实际遇到过的场景看完你就能理解为什么一定要走到自定义这一步。2.1 翻车场景一轮询把流量打到了热点节点某次我负责的一个业务集群做了垂直拆分把接口分成了普通查询和重度计算两类。当时CLB容器负载均衡默认配的是加权轮询所有节点权重一样。结果每天下午业务高峰集群里总有一两个节点CPU冲到90%以上其他节点却只有30%。查了半天才发现重度计算接口虽然只占总量的20%但它独占资源轮询策略把这些重计算请求相对均匀地撒给了所有节点——这本身没问题——但是重计算请求一旦落到某个节点上该节点的资源占用会瞬间飙升而轮询完全感知不到仍然继续往这个热点节点塞新请求。这个场景要的不是“哪种策略更均衡”而是要让调度器能识别并避开正在过载的节点内置策略里没有一种直接提供这个能力。2.2 翻车场景二最少连接被慢请求拖垮另外一次是在数据库代理场景。我们用最少连接策略做读写分离中间件假设后面挂了6个数据库实例。上线初期一切正常后来某天DBA在其中一个实例上跑了一个超长的分析任务占用了大量连接资源。按最少连接的逻辑这个实例因为“空闲连接”最多反而成了首选目标新请求继续涌入直接把业务拖垮了。问题根源在于**最少连接只是连接数量的守恒不是资源耗用的守恒。**数据库连接池里的连接数量恒定不代表每个连接承载的负载是恒定的——一个跑两分钟的慢查询和一个跑两毫秒的快查询在“连接数”这个指标上没有任何区别。只有引入真实的资源指标比如活跃线程数、当前查询耗时、锁等待时间等才能反映实例的真实压力而这些指标负载均衡器默认是拿不到的必须通过扩展链路自己去采集。2.3 翻车场景三IP哈希在移动网络下的尴尬还有一个经典场景是移动端API网关客户端通过公网访问。一开始我们想用IP哈希做最简单的会话保持但上线后很快就发现问题大量用户来自运营商NAT网关后的同一个出口IP这些IP在哈希表上可能恰好落在同一个节点直接把那个节点打到CPU满载。更麻烦的是用户切网Wi-Fi切5G、飞行模式恢复后IP就变了会话保持目标也没达到。这里核心矛盾是IP哈希假设“一个IP是一个稳定的客户端”但真实网络环境里这个假设经常不成立。这种情况要么换用基于Cookie、Token等业务标识的会话保持方案要么就需要自定义一个策略——比如对IP先做一层预处理截取C段、配合端口哈希等再把业务标识作为附属维度一起参与调度。2.4 翻车场景四统一策略无法表达业务优先级最让我决定“必须自定义”的一次经历是一个混合业务场景的网关同一套网关既要转发线上交易接口延迟敏感如果后端出问题必须立刻切流量又要转发批量离线任务对延迟不太敏感但要求尽量不丢。统一用最少连接离线任务会把连接数低但CPU其实快被打满的节点选走等到真实交易请求过来时节点已经无力处理。这类场景的关键词是**“多优先级感知”**。调度策略需要知道流量的来源与业务等级VIP客户请求应当优先路由到低负载节点普通请求可以接受稍差一点的服务离线任务则要主动避开繁忙节点。这个意图无法用任何单一内置策略完整表达只能通过自定义策略在调度算法里加入“业务等级权重”和“按等级差异化打分”的逻辑。3. 自定义策略的设计框架从业务目标到打分函数聊完了为什么需要自定义下面进入正题该怎么做。自定义负载均衡策略没有想象中那么玄它的本质其实就是三步——定目标、采指标、算选择。把这三件事想清楚自定义策略就成了一大半。3.1 先把目标说清楚很多人在设计自定义策略下手第一步就错了他们急着去写算法、调参却忘了先回答一个问题你到底想让调度器优化什么目标选项通常绕不开这几个最小化平均响应时间让每个请求都快。最小化长尾延迟P99让最慢的那批请求也可控。最大化整体吞吐量在资源有限的情况下尽量多处理请求。成本优先优先使用便宜的节点比如竞价实例贵节点兜底。稳定性优先宁可牺牲一点平均性能也要避免任何单节点过载。目标不同自定义方向的差别非常大。想做成本优先你的打分函数里就要给便宜节点加较大权重贵节点只有当便宜节点全满时才被选到想做P99优化你就要重点采集响应延迟的分位数而不是平均值还要设计快速熔断机制。如果一上来就想着“综合一下”最后往往什么都优化不好。我习惯的做法是在写第一行代码之前先输出一句明确的调度策略描述比如“在交易流量高峰期优先将请求调度到CPU使用率低于60%、最近5分钟平均RT小于200ms的节点并在节点连续3次健康检查失败时快速摘除”。这句话写清楚了后面的所有设计都是围绕它展开的。3.2 指标采集、归一化与滑动窗口目标确定之后下一步是确定调度器能看到哪些指标。常见可选指标包括CPU使用率直接反映计算资源压力。内存使用率内存吃紧往往伴随GC频繁或OOM风险。活跃连接数反映并发处理压力。平均响应时间RT反映服务自身处理能力和队列积压情况。队列长度衡量请求在节点上排队等待的时间。带宽/磁盘IOIO密集场景下比CPU更有代表性。但不同指标的量纲完全不同——CPU是0到100的百分数RT可能是几十到几千毫秒连接数可能是几个到几百个。如果直接拿这些数字做加权求和最后一定是量纲大的指标主导全部决策。所以自定义策略里几乎一定会做一次归一化处理。最简单的归一化是线性归一化把指标映射到0到1区间(当前值 - 最小值) / (最大值 - 最小值)。但线性归一化对离群值非常敏感如果一个节点的RT飙到5000ms其他节点都是200ms最高值一来所有节点的归一化结果都会变得很极端。更稳的办法是用百分位映射比如把RT的历史数据先画出P50、P90、P99然后根据当前RT落在哪个区间打分落在P99以上直接给最低分甚至标记为不健康。这种打分方式对异常值更鲁棒。还有一个新手容易忽略的点指标采样的时间粒度。如果你从监控系统拿到的节点CPU利用率是5分钟粒度的平均值用它来做毫秒级的调度决策相当于拿着昨天的天气预报决定今天出门穿不穿外套——数据早就过时了。更合理的做法是让节点Agent每隔几秒上报一次当前状态调度器端再对这些散点做滑动窗口平滑比如取最近30秒的均值既滤掉了瞬时抖动又能保证数据新鲜度。3.3 打分公式与加权随机选择当多个指标都归一化好之后就可以设计打分公式了。预设一个最简单的场景我们要避免高CPU、高RT的节点同时兼顾连接数。打分逻辑可以这样写def calculate_score(node): # node.cpu_normalized: 0~1越大压力越大 # node.rt_normalized: 0~1越大响应越慢 # node.conn_normalized: 0~1越大连接数越多 load_score (0.5 * node.cpu_normalized 0.3 * node.rt_normalized 0.2 * node.conn_normalized) # 希望选中压力小的节点所以取负相关 return 1.0 - load_score这个公式表达的意思非常清楚CPU压力权重最高0.5响应时间次之0.3连接数参考一下0.2。拿到每个节点的得分之后怎么选择很多人第一反应是“选得分最高的那个”。但在实践中最好不要做最大者通吃因为这样会造成少量得分最高的节点被集中打满流量反而引发新的热点。更稳定的做法是加权随机得分高的节点获得更高的被选概率但得分略低的节点也有一定概率被选中。这样流量分配会呈现一种自然的概率分布既偏向好节点又不至于把所有鸡蛋放在一个篮子里。3.4 兜底与降级设计自定义策略最容易翻车的环节不在策略本身而在策略失效时你怎么办。举个例子如果你采集指标的Agent挂了或者节点上报接口超时导致所有节点的指标数据都为空这时候你的打分公式怎么算我见过不少实现直接把这类节点当成0分处理结果就是所有流量都被打到一个节点上直接雪崩。正确的做法是为“数据缺失”设置独立的降级路径当某个节点指标数据缺失或过期超过阈值时把它从候选集合中临时摘除或者给它一个保守的默认分数比如所有节点得分的平均值而不是默认给0分。同样的道理也适用于健康检查。如果你依赖HTTP健康检查来摘除故障节点健康检查本身也有误报概率。在关键场景里我会把健康检查和调度策略分开处理健康检查只负责“硬摘除”明显不可用的节点立刻下线调度打分只负责“软避让”压力大的节点降低被选概率。这样一个节点即使被打出低分也还保留一点概率接收流量不至于因为监控误报导致节点完全空转。4. 三条可落地的自定义实现路径方法框架搭好之后最常被问的问题就是我到底应该在哪里写我的自定义策略这一节我给出三条实际可落地的路径按实施成本从低到高排列你可以根据自己的技术栈选。4.1 路径一OpenResty Lua快速定制如果你已经在用Nginx或OpenResty做七层网关那么最轻量级的自定义方式就是写在OpenResty的balancer_by_lua阶段。这个阶段允许你完全接管upstream节点的选择逻辑不再局限于Nginx自带的round_robin、least_conn等指令。下面是一段简化示例展示了如何在OpenResty里自定义一个简单的加权随机均衡器权重来自后端节点上报的活跃连接数-- balancer_by_lua_block 中调用 local nodes { { pool backend_a, conn 12, capacity 100 }, { pool backend_b, conn 5, capacity 100 }, { pool backend_c, conn 80, capacity 100 }, } local function score(node) -- 连接数越低得分越高 return math.max(0.1, 1 - node.conn / node.capacity) end -- 计算所有节点的得分比例然后按比例随机选 local total_weight 0 for _, n in ipairs(nodes) do n.weight score(n) total_weight total_weight n.weight end local r math.random() * total_weight local cursor 0 local selected_pool for _, n in ipairs(nodes) do cursor cursor n.weight if r cursor then selected_pool n.pool break end end -- 选中之后设置当前请求要转发的upstream peer if selected_pool then ngx_balancer.set_current_peer(selected_pool) end这个实现里的核心逻辑是节点连接数越少、离容量上限越远得分就越高被选中的概率也越大。真正落地时conn指标通常来源于一个共享缓存比如ngx.shared.DICT由后端的Agent或采集任务定时写入。OpenResty方案的最大优点是不用改后端任何代码纯网关层改造上线风险低非常适合快速验证自定义策略的效果。需要注意的一点balancer_by_lua是在每个请求的upstream选择阶段执行的里面的逻辑必须足够轻量。不要在现网请求链路上做重计算、不要远程调用Redis获取指标每条请求都访问Redis会把Redis拖垮。正确的姿势是让采集器定时把节点状态同步到一个共享内存字典Lua代码只从共享内存里读、做纯内存计算整个过程控制在微秒级别。4.2 路径二网关/框架扩展点如果业务跑在Java技术栈用的又是Spring Cloud这样自带负载均衡的微服务框架那更自然的做法是在客户端负载均衡器层面扩展。Spring Cloud中的LoadBalancer接口就是设计给开发者做自定义的——你可以实现自己的ReactiveLoadBalancer拿到当前可用的服务实例列表然后按自己的逻辑挑一个实例返回。这类扩展的实现思路依然是那套“打分加权随机”的办法。我写过的一个简化版本是服务实例的元数据里带了权重配置和实时的CPU水位客户端在做服务发现时拿到这些数据然后走一遍打分逻辑即可。因为客户端负载均衡是拿注册中心里的实例列表来选的它天然就能感知到实例的心跳状态配合自定义权重就能实现非常灵活的调度策略。Dubbo这类RPC框架也提供类似的SPI扩展点很多团队在内部就是通过自定义LoadBalance来做到按机房优先、按调用链级别优先级路由的。如果你已经在框架里做了服务注册发现优先使用框架提供的扩展点而不是再架设一层独立的网关——不然两层负载均衡叠加理解和排查问题的成本都会翻倍。4.3 路径三自研调度器完整实现如果现有的网关、框架都无法满足你的场景比如调度逻辑极度特殊、需要依赖一套深度定制的指标体系那最后一条路就是自己写一个独立的调度器。这个调度器最基本的能力就是拿到所有节点状态根据策略算出一个目标节点再把结果返回给上层调用方。下面给出一个完整的、可直接跑通的最小调度器核心实现用的Python伪代码风格方便理解class Node: def __init__(self, node_id, cpu, rt, conn, healthyTrue): self.node_id node_id self.cpu cpu # 0~100 self.rt rt # 毫秒 self.conn conn self.healthy healthy class CustomBalancer: def __init__(self, nodes, window_size30): self.nodes nodes self.window_size window_size self.rt_history {n.node_id: [] for n in nodes} def normalize(self, value, low, high): # 线性归一化并做边界裁剪 if high low: return 0.0 return max(0.0, min(1.0, (value - low) / (high - low))) def safe_rt(self, node): # 如果某个节点没有RT历史数据用所有节点的平均RT兜底 if len(self.rt_history[node.node_id]) 0: all_rt [self.rt_history[n.node_id] for n in self.nodes] all_rt [x for sublist in all_rt for x in sublist] if not all_rt: return 500 # 完全冷启动给一个保守值 return sum(all_rt) / len(all_rt) recent self.rt_history[node.node_id][-self.window_size:] return sum(recent) / len(recent) def score(self, node): if not node.healthy: return 0.0 cpu_score 1 - self.normalize(node.cpu, 0, 100) rt_score 1 - self.normalize(self.safe_rt(node), 0, 5000) conn_score 1 - self.normalize(node.conn, 0, 1000) # 权重CPU最重要RT其次连接数参考 return 0.5 * cpu_score 0.3 * rt_score 0.2 * conn_score def choose(self): scores [self.score(n) for n in self.nodes] total sum(scores) if total 0: # 兜底全部不可用或全为0分时随机选一个健康的 import random healthy_nodes [n for n in self.nodes if n.healthy] return random.choice(healthy_nodes or self.nodes).node_id import random r random.uniform(0, total) cursor 0 for n, s in zip(self.nodes, scores): cursor s if r cursor: return n.node_id return self.nodes[-1].node_id这份代码里有两个值得留意的设计一是safe_rt函数在节点没有任何历史RT数据时会退回使用全集群平均RT避免冷启动节点被当成“零RT”而疯狂接流量二是choose的最后兜底逻辑当所有节点都不可用时返回一个随机健康候选宁可短暂分配错误也不能让整个请求链路空转。这两个细节在自研调度器里几乎是必备的安全阀。5. 上线前的实测与避坑清单自定义策略写完之后不要立刻推到生产环境。我在这个环节踩过的坑说几个有代表性的。5.1 指标新鲜度决定策略上限有一次我把节点CPU数据采集频率设置为每分钟一次策略在压测环境表现很好但上线后经常看到有节点被打满另一些却在闲置。后来发现原因很简单压测环境机器少、指标刷新快一旦上了生产机器增多、上报间隔变长调度器看到的CPU数据已经滞后了一分钟。在这期间某个节点可以接收大量请求瞬间冲到100%但调度器还拿着旧数据把它当最优节点继续猛推流量。解决方案是把采集周期压缩到5秒一报同时调度端对超过10秒没有更新的节点临时降权。宁可少接一点流量也不能拿过期数据做决策。5.2 冷启动与默认值新扩容一个节点进入集群时它的RT历史是空的连接数是0CPU也是0。很多自定义策略会把这个节点当成“完美节点”呼啦一下把所有流量都切过去结果新节点被瞬时打瘫。正确的做法是为新节点加一个冷启动保护期比如前两分钟只给它分配正常流量的20%同时用一个保守默认分数参与打分而不是最高分。等它积累了足够的状态数据之后再逐步恢复它的正常权重。这个思想和熔断很像没有足够数据做决策时永远选择最保守的方案。5.3 全链路压测与对照验证上线之前至少做两个验证一是用生产流量的录制回放做全链路压测对比默认策略和自定义策略下的吞吐量、P99延迟、节点CPU均衡度二是在灰度环境里做A/B对照——把集群的一半流量走默认策略一半走自定义策略观察一段时间。其次压测过程中要故意模拟故障把某节点直接kill掉、把某个节点CPU压到满负荷看自定义策略是否能快速感知并避开故障节点。我习惯把自定义策略的调度决策全部打日志哪怕是A/B阶段。这样一旦出问题可以直接回放每一个请求当时被哪个节点接收、为什么选这个节点、当时集群状态是什么样。有这层数据兜底排查问题会快很多。最后再分享一条我对自定义策略的个人看法能用内置策略解决的场景尽量别自定义。自定义意味着你要自己维护指标采集、逻辑计算、兜底降级、故障容忍这一整套链路复杂度是指数级上升的。只有当业务意图确实无法用现有策略表达比如多优先级调度、资源感知路由、跨节点成本优化才值得走自定义这条路。但如果真走到了这一步按照“定目标、采指标、打分选节点、加兜底”这个框架来做整个事情不会失控——这也是我自己踩过一遍坑之后沉淀下来的经验。
平方复杂度无法被常规优化消除｜TaoToken 统一 Key 通道实测)
