大型促销期间业务扩容与攻击防护资源联合规划，关键不是把两份容量清单相加，而是确认它们是否争用同一组计算、网络、连接和存储资源。促销流量上涨时，防护规则、流量清洗、日志采集也可能同步增加负载；若只验证业务峰值，可能出现业务实例已扩容、入口或后端反而先到上限的情况。
先画出共享资源链路
按请求经过的顺序列出入口、负载分配、应用实例、缓存、数据库及防护服务，并标明每一环的容量上限、扩容方式和负责人。检查重点不是单个组件的标称规格，而是业务流量与防护流量是否共用资源。
- 计算：流量识别、规则匹配、加密解密、日志解析可能与应用争用CPU和内存。若防护服务与业务部署在同一节点，确认资源限制和优先级；否则防护任务也可能挤压业务进程。
- 网络：入口带宽、跨区链路、负载设备吞吐和流量清洗后的回源带宽是不同环节。核对双向流量、峰值持续时间及单链路故障时的可用余量，不能只看总带宽。
- 连接与存储：扩容应用实例会增加数据库连接池总数。以实例数乘以单实例连接上限估算连接需求，再与数据库允许连接数、运维和后台任务预留量比较。缓存、数据库的磁盘IOPS和日志写入也要纳入。
- 配额与启动速度：云资源配额、地址数量、负载均衡规则数以及新实例启动时间，可能限制弹性伸缩。确认配额申请已生效，并验证扩容后健康检查、缓存预热和连接建立所需时间。
防护能力要按场景核算
容量评估至少拆成正常促销流量、流量突增和恶意请求三类。大流量攻击主要考验入口及清洗能力；频繁建立连接会消耗连接跟踪、负载设备和应用连接池；针对高成本接口的请求，则可能在带宽不高时耗尽应用或数据库资源。三类压力不可用一个“峰值带宽”指标替代。
规划时先用历史同类活动或压测结果估算业务峰值，再叠加合理的突发余量；余量要结合流量波动、扩容耗时和故障切换方式确定，不能套用固定比例。向防护服务提供方确认其覆盖的流量路径、清洗后回源限制、启用策略所需时间及告警联系人。规则越严格，误拦正常用户的风险也越高，应准备可回退的规则版本和人工确认流程。
大促前按步骤完成联合验证
- 建立资源表：记录各组件当前上限、可扩展上限、扩容触发条件、配额和依赖关系；标出共享的CPU、带宽、连接数与存储IO。
- 换算扩容后的连接需求：按最大预期实例数乘以单实例连接池上限，分别核对数据库、缓存及外部依赖的连接能力，并为管理操作和异步任务留出空间。
- 分层压测：先测业务正常路径，再测登录、查询、下单等资源消耗差异明显的路径；随后验证防护规则开启后的延迟、错误率、资源占用和日志写入。压测应在获准的环境与时间窗口内进行。
- 验证故障与回退：演练扩容失败、单实例退出、防护策略误拦及日志存储逼近上限时的处理；确认降级开关、规则回退和告警通知都能实际执行。
- 设置值守阈值：结合基线观察CPU、内存、带宽、连接数、磁盘IO和请求错误变化，按趋势提前处置；阈值应由压测和历史基线确定，而非临时猜测。
常见问题
扩容了应用实例，为什么仍可能无法承接流量？
入口带宽、数据库连接、缓存能力或云资源配额可能先到上限；新实例启动和预热也需要时间。
防护能力是否只需看攻击流量上限？
不够。还要确认清洗后回源能力、连接处理能力、规则生效流程及日志对计算和存储的影响。
没有往年大促数据，如何确定容量？
用业务负责人确认的目标负载开展分层压测，逐步增加并发，记录各层瓶颈，再据此制定扩容和回退条件。
最终应把业务扩容、防护启用和依赖资源放进同一张容量与演练计划中。大型促销期间业务扩容与攻击防护资源联合规划做到链路可量化、冲突可验证、异常可回退，才能减少“前端有容量、后端先耗尽”的风险。