负载均衡本身不扩容，弹性伸缩需后端计算单元联动监控与策略；必须自动绑定伸缩组与服务器组，启用健康检查和动态加权，分层设置伸缩阈值并预留热备资源。
面对突发性流量暴增，负载均衡接入本身不直接扩容资源，它只是流量的“分发员”；真正的弹性伸缩必须由后端计算单元（如ECS实例、容器服务）配合监控与策略联动来完成。关键在于让负载均衡能感知后端变化，并把新流量准确导过去，同时避免旧节点过载或新节点未就绪就承接请求。
负载均衡需与伸缩组自动绑定
以阿里云SLB/NLB为例，不能手动增删后端服务器。必须将负载均衡的服务器组与弹性伸缩组关联——伸缩组扩容出新ECS实例后，系统自动将其注册为后端；缩容时也自动摘除。这样确保流量始终只打到健康、已就绪的节点上。
- 创建伸缩组时，在“网络与安全组”页签下勾选“自动添加至负载均衡服务器组”
- 确认NLB/SLB已开启“健康检查”，检查路径、端口、超时时间需与应用实际启动状态匹配（例如Spring Boot应用需等Actuator端点就绪后再通过健康检查）
- 避免使用“最小空闲连接数”类策略——突发流量下，新实例可能因冷启动延迟尚未建立足够连接，导致权重被误判偏低
用动态加权替代静态轮询
普通轮询或IP哈希在突增场景下容易放大不均衡：刚扩容的实例CPU尚低，但轮询会均分请求，而它可能还没加载完缓存或JVM预热完毕。应启用支持实时指标反馈的动态加权机制。
- Docker MCP网关可基于CPU、内存、延迟每5–10秒重算权重，高延迟实例自动降权
- Kubernetes中可用KEDA或Prometheus Adapter，结合HPA v2实现按QPS或队列长度伸缩，并通过Service + EndpointSlice将权重映射到Ingress控制器（如Nginx Ingress）
- 若用传统SLB，可搭配云监控+函数计算（FC）写自定义脚本：当某后端ECS平均响应时间＞800ms持续2分钟，临时调低其权重至10（默认100），待恢复后再回调
伸缩决策要兼顾“快响应”和“防抖动”
告警阈值设得太低，小波动就扩容，造成资源浪费；设得太高，又错过黄金响应窗口。建议分层设置触发条件，并引入冷却期与滞后判断。
- 一级响应（快）：CPU > 85% 持续90秒 → 扩容1台（应对瞬时尖峰）
- 二级响应（稳）：QPS > 基线均值×3 且错误率 > 2% 持续3分钟 → 扩容3台（确认是真实业务增长）
- 所有扩容动作后强制设置5分钟冷却期，防止连续触发；缩容则延长至15分钟，避免刚回落就回收资源
预留“热备缓冲”降低冷启动影响
容器或ECS从创建到可服务通常有10–60秒延迟。全靠告警触发再扩容，用户已感知卡顿。更优做法是保持少量“常驻热备”资源。
- 伸缩组最小实例数设为2，而非1——其中1台始终运行，仅承担低优先级任务（如日志聚合），CPU空闲率维持在30%以下，随时可接管主流量
- 容器镜像中启用JVM TieredStopAtLevel=1 + 类预加载，或使用GraalVM Native Image缩短启动时间
- 对关键API接口启用SLB的“连接池复用”和“长连接保持”，减少新建连接开销
