根源是容量预估不足叠加负载均衡接入不当，需直击负载均衡器容量、后端节点真实承载力、上下游弹性边界三大断层，并核查重试放大、动态失衡应对及SLA协同等隐性缺口。

大促期间服务雪崩，若根源是容量预估不足叠加负载均衡接入不当，问题往往藏在“看起来正常”的配置背后。不是设备没扛住，而是流量分发机制和资源水位之间严重错配。排查要跳过表象告警（比如502、高延迟），直击三个关键断层：负载均衡器自身容量、后端节点实际承载能力、以及上下游协同的弹性边界。

看负载均衡器是否成了“第一道瓶颈”

很多团队只盯着后端服务CPU或响应时间，却忽略CLB/Nginx本身也有吞吐极限。尤其四层负载均衡（如TCP转发）在连接数、新建连接速率、带宽三方面极易打满。

• 查CLB监控中的“新建连接数/秒”和“并发连接数”，对比其规格上限（例如腾讯云CLB共享型实例默认仅支持1万并发连接）；
• 检查Nginx的worker_connections和events.use配置，确认是否启用epoll且数值足够支撑峰值QPS × 平均连接保持时长；
• 观察健康检查失败率突增是否发生在流量刚起峰时——这常意味着LB节点已无法及时完成探活，开始误判后端失活并错误摘除节点，进一步加剧剩余节点压力。

验后端节点真实处理能力是否被“平均化掩盖”

轮询或加权轮询策略默认假设所有实例性能一致，但大促前扩容的机器可能配置相同、环境不同：新节点未预热、JVM未完成GC调优、磁盘IO受宿主机干扰、甚至混部了日志采集等旁路任务。

• 不只看CPU平均值，重点比对各节点的P95响应时间、线程池活跃线程数、数据库连接池使用率——差异超2倍就属异常；
• 用jstack或arthas thread抓取高负载节点的线程快照，确认是否卡在DB连接获取、远程调用等待或锁竞争上；
• 回溯扩容记录：新增实例是否与老实例共用同一数据库连接池配置？若未独立设置maxOpenConns，新实例上线反而稀释了连接资源。

查流量再分配机制能否应对“动态失衡”

静态策略（如IP哈希、固定权重）在大促中非常危险。用户行为突变、缓存击穿、慢SQL爆发都会让某些节点瞬间成为热点，而传统LB无法感知应用层水位。

• 确认是否启用了基于实时指标的动态调度，例如Nginx Plus的least_time、Envoy的least_request或自研LB对接APM的延迟反馈；
• 检查健康检查间隔和失败阈值：若设为“连续3次失败才摘除”，而实际慢请求耗时已达10秒，那该节点在被摘除前已持续拖垮整个集群8–10秒；
• 验证熔断降级是否生效：当某节点P99飙升至2秒以上，上游网关是否触发自动降级，而非继续转发并重试三次。

复盘容量模型是否漏掉了“放大系数”

很多容量预估只算了接口QPS，却忽略了重试、级联超时、连接复用率下降等隐性放大因子。一次慢查询引发的重试风暴，可让数据库实际承接请求量翻3–5倍。

• 统计大促前压测中“重试请求占比”，结合线上监控确认真实重试率（如网关层X-Retry-Count头）；
• 检查下游依赖的SLA是否同步升级：若订单服务预估1万QPS，但它调用的会员服务只按3千QPS扩容，那会员服务就是隐藏瓶颈；
• 用链路追踪工具（如SkyWalking）拉出故障时段的全链路瀑布图，定位哪一跳的平均耗时增幅最大、且该跳的子调用数是否异常激增——这往往是容量缺口的起点。