直播开播后请求量突然上升，第一反应往往是增加服务器。但如果瓶颈在接入链路、攻击流量没有拦截，或应用依赖已经饱和，单纯扩容只会让资源消耗更快。规划高流量直播平台的抗攻击入口与弹性扩容，要先区分哪些流量应挡在入口，哪些工作负载确实需要增加计算资源。
误区一：把扩容当成抗攻击手段
弹性扩容适合应对真实观众带来的合法请求增长；它不能替代网络层和应用层防护。大量无效连接或重复请求若未经筛选就进入应用，自动扩容可能不断新增实例，却仍无法消除入口带宽、连接数或下游服务的压力。
可按层次布防：用内容分发网络（CDN）承接可缓存的直播页面、图片和静态资源；通过具备清洗能力的接入服务吸收异常流量；在应用入口设置请求速率限制、连接上限和异常请求规则。对必须实时返回、不能缓存的接口，则要单独设置保护阈值，避免把静态资源的缓存策略误套到业务请求上。
误区二：只盯 CPU，忽略真正的瓶颈
CPU 使用率并不能代表直播服务的整体负载。视频分发可能受出口带宽或并发连接数限制，互动功能可能卡在数据库连接、消息队列积压或第三方服务响应上。若只按 CPU 触发扩容，可能出现 CPU 不高、用户仍然卡顿的情况；反过来，慢请求堆积也可能抬高 CPU，导致错误扩容。
扩容指标应与用户体验和关键资源共同观察，例如请求延迟、错误率、活跃连接、队列长度、带宽使用率及依赖服务的连接池占用。使用 Kubernetes 的团队可通过 Horizontal Pod Autoscaler（HPA）按 CPU 或自定义指标调整 Pod 副本，但仍需检查节点是否有余量，以及新增副本能否及时接入流量。
误区三：默认实例一加就能马上接流量
新实例启动、加载配置、建立连接和完成健康检查都需要时间。若扩容触发得太晚，观众可能已经遇到卡顿；若流量一降就立刻缩容，下一波请求又会造成反复启动。冷启动时间、峰值持续长度和实例规格会影响所需缓冲，不能用一个固定数字适用于所有平台。
把扩容策略拆成可验证的步骤
- 盘点容量：分别记录入口带宽、应用并发、关键依赖的安全余量，并找出先达到限制的环节。
- 设置预热：依据以往开播时段提前保留基础容量；突发活动可在计划开始前预扩容，避免完全依赖事后自动扩展。
- 配置伸缩边界：设定最小、最大副本数和扩缩容冷却时间。上限应受节点、数据库连接数和预算共同约束，而不是只看应用本身。
- 演练峰值与故障：在测试环境逐步增加并发，观察延迟、错误率和依赖资源；同时验证入口防护开启后，正常观众仍能观看和互动。
- 准备降级：依赖过载时，按业务优先级暂停非关键功能或降低更新频率，并保留必要的直播播放与状态反馈。
误区四：只测开播瞬间，不测持续高峰
短时压力测试通过，不代表长时间直播稳定。持续负载可能暴露连接未释放、缓存增长或队列处理能力不足等问题。演练应覆盖突发爬升、稳定高峰和流量回落；同时观察缩容后是否引发延迟反弹。采用源站保护时，也要核对缓存未命中和回源请求的承载能力，否则入口流量转发到源站后，仍可能形成新的瓶颈。
复盘时记录触发扩容的指标、实例就绪时间、峰值期间的错误与延迟，以及被保护的依赖服务。由此调整阈值和容量边界，比盲目提高最大实例数更有效。归根结底，高流量直播平台的抗攻击入口与弹性扩容应分别解决流量筛选和资源供给问题，再通过演练验证两者衔接是否可靠。
常见问题
入口已经有 CDN，还需要扩容吗？
需要视业务而定。CDN 能减轻可缓存内容的回源压力，但互动接口、鉴权和其他动态请求仍由应用及其依赖处理。
扩容阈值应该设多少？
没有适用于所有平台的固定值。应根据压测结果、实例就绪时间、用户体验指标和依赖上限设定，并在演练后调整。
遇到疑似攻击时，是否应关闭自动扩容？
不宜一概而论。应先启用入口限流和异常流量处置，再根据真实业务负载决定是否扩容；同时设置资源上限，避免无效请求持续推高成本。