容量规划需为突发流量预留弹性空间，通过业务语义驱动的多级扩缩容、分层资源池（预留/弹性/兜底）、缓存与队列前置缓冲及可观测闭环调优，实现毫秒级确定性响应。
容量规划不能只盯着“平时用多少”，而要为“突然多十倍”留出反应空间。突发流量不是靠临时加机器扛过去的，而是靠提前设计好的弹性伸缩策略，在毫秒级内自动响应。
基于业务指标的动态扩缩容触发
光看CPU或内存容易误判。比如缓存击穿时CPU可能不高，但数据库连接池已满；又比如消息积压时QPS没爆，但订单创建延迟飙升。所以伸缩策略必须融合业务语义：
- 设置多级触发条件：基础层（CPU＞75%持续2分钟）+ 业务层（订单队列积压＞5000条 或 支付超时率＞3%）
- 不同模块用不同指标：网关层按QPS扩容，搜索服务按ES查询延迟，库存服务按Redis热点Key失败率
- 避免抖动：加入冷静期（如扩容后5分钟内不缩容）和步长控制（单次最多增20%实例）
分层资源池：预留+弹性+兜底三段式配置
把资源当成水坝来设计——日常用水靠主库（预留），洪峰来时开闸放水（弹性），极端情况启用蓄洪区（兜底）：
- 冷备资源池：提前部署30%空闲Pod或ECS，保持镜像就绪、连接池预热，10秒内可承接流量
- 公有云弹性通道：与云厂商API打通，当本地资源池耗尽，自动调用跨可用区或跨云资源（如华东节点不足时调度华北闲置实例）
- 降级兜底实例：配置低配但功能完整的“瘦实例”，仅运行核心链路（如下单、支付），关闭推荐、评论等非关键模块
缓存与队列前置：让流量“慢下来、匀开来”
伸缩再快也有延迟，真正扛住第一波冲击的是架构缓冲层：
- 静态资源全量接入CDN，设置智能路由，把80%用户请求拦截在边缘节点
- 热点数据预热：大促前2小时将SKU详情、价格、库存等写入Redis集群，并启用本地缓存（Caffeine）做二级保护
- 所有写操作进消息队列（如RocketMQ），用削峰填谷方式平滑后端压力，峰值吞吐可提升3–5倍
可观测驱动的闭环调优
伸缩不是设完阈值就完事。每次流量波动后，必须回溯验证策略有效性：
- 记录每次扩容/缩容的时间、触发指标、新增实例数、后续5分钟QPS变化
- 对比预测模型输出与实际峰值偏差，每月更新LSTM流量预测参数
- 对频繁触发缩容的服务，检查是否存在内存泄漏或连接未释放——伸缩只是表象，根因才是关键
弹性不是让系统变“软”，而是让它在压力下依然保持确定性响应。真正的容量规划，是把不确定性装进确定的规则里。
