大促时流量上涨不一定都是攻击：秒杀开场、直播引流和恶意请求可能同时发生。电商大促期间的抗攻击架构设计，重点不是把所有机器堆到最大，而是识别流量入口、保护关键交易路径，并在过载时保住下单和支付等核心功能。
先分清压力来自哪里
先用历史活动记录和压测结果估算正常峰值，再观察请求来源、请求频率、响应时间、错误比例及服务器资源。若入口流量暴增、业务请求特征异常，优先考虑流量清洗与入口防护；若流量基本真实，但数据库连接、库存扣减或订单服务先饱和，应先优化应用链路和容量。两类情况常会并存，不能只凭访问量判断。
五种架构方案，按瓶颈组合
1. CDN 缓存与静态资源分离
把图片、商品详情页中的可缓存内容和前端静态文件交由 CDN 分发，动态库存、购物车和结算请求仍回源处理。适合商品浏览量远高于下单量的活动。优点是减少源站压力、改善远距离访问；缺点是缓存规则不当会展示过期信息。活动前确认可缓存内容与实时数据边界，并准备快速刷新策略。
2. DDoS 清洗与入口分层
当风险包括大流量冲击或来源分散的异常请求，可使用云服务商或专业网络服务提供的 DDoS 清洗能力，将清洗后的流量转发至业务入口。它能在应用服务器之前处理部分网络层冲击，但无法替代业务侧识别异常下单，也不能保证所有应用请求都被拦截。采购前核对清洗触发方式、覆盖网络范围、切换流程和故障联系人。
3. 多可用区部署与弹性扩容
将无状态应用分布到多个可用区，配合自动扩容应对持续增长的正常流量。适合业务已有成熟监控、服务可横向扩展的团队。优点是单点故障影响较小；缺点是数据库、连接池或第三方依赖可能先成为瓶颈，扩容也需要时间。按压测结果设置扩容触发条件，并确认配额、镜像启动时间和数据库连接上限。
4. 排队、限流与降级
秒杀入口可采用排队页或令牌机制控制进入速率；对非核心推荐、评论等功能限流或暂时降级，把资源留给登录、下单和支付。消息队列适合异步处理通知、积分等非即时任务，但库存校验和支付状态仍须明确一致性规则。该方案能削峰，却会增加等待和系统复杂度，需设计超时、重复提交处理和失败告警。
5. 多地域容灾
对不能长时间中断、且团队具备跨地域运维能力的业务，可将服务部署到多个地域，并预先演练流量切换和数据恢复。优点是降低单地域故障影响；缺点是成本更高，数据同步、库存一致性和切换决策更复杂。若仅需应对短时峰值，先做好单地域多可用区与备份，通常比仓促搭建双活更实际。
按业务条件落地
- 列出核心链路：浏览、登录、库存校验、下单、支付，并标注每一步依赖的服务和数据。
- 用接近活动流量的压测找出先饱和的组件；同时验证异常流量下入口清洗、限流和告警是否按预期工作。
- 按瓶颈选组合：浏览压力大先做 CDN；网络冲击风险高先落实清洗；应用容量不足再扩容；突发请求集中则增加排队和降级。
- 活动前演练扩容、回滚、故障切换及客服沟通，明确谁能执行流量切换、谁负责恢复。
电商大促期间的抗攻击架构设计应从风险和业务优先级出发，而非一次性照搬全套方案。预算有限时先保护入口、核心交易链路和恢复能力；有跨地域运维经验且中断代价高，再投入多地域容灾。
常见问题
流量大就一定是攻击吗？
不一定。对照活动节奏、请求特征和后端资源表现综合判断，营销带来的真实流量也会压垮薄弱服务。
只扩服务器够不够？
不够。数据库、连接池或第三方服务可能先到上限；应先定位瓶颈，再验证扩容后的整条链路。
排队会影响转化吗？
可能会增加等待，但在系统过载时，明确告知等待状态通常比页面持续报错更可控。适合集中秒杀等突发场景，不宜无差别应用于所有业务。
小团队优先做什么？
先梳理核心链路、启用合适的入口防护与静态内容分发，再通过压测确定扩容和降级方案；不要在缺少演练能力时直接追求复杂双活。