容量规划核心是构建持续感知、预测、响应的闭环系统，依赖压测基线、多维指标驱动、分层伸缩及闭环验证。
容量规划在云原生环境下，核心不是“一次性算准”，而是构建一个能持续感知、预测和响应负载变化的闭环系统。弹性伸缩组（如K8s中的HPA+Cluster Autoscaler，或云厂商的AS伸缩组）是这个闭环的执行层，但它的有效运行依赖于前置的可观测性、合理的指标定义和与业务节奏对齐的策略设计。
先建好观测基线：压测出真实容量水位
没有基线的伸缩是盲调。必须通过全链路压测，摸清关键服务在不同并发下的响应时间、错误率和资源消耗拐点。例如，某订单服务在2000 QPS时P95延迟突破800ms、CPU达75%，这就是它的实际容量瓶颈。这个数据要沉淀为伸缩策略里的目标值（比如HPA设averageValue: 70% CPU），而不是拍脑袋定50%或80%。
- 压测需覆盖典型业务场景（如秒杀、查单、下单），不只是单接口
- 结果要标注“稳态区间”和“过载临界点”，后者直接决定maxReplicas和扩容触发阈值
- 把压测报告和容量基线纳入CI/CD流水线，每次发版后自动回归验证
用多维指标驱动伸缩，别只看CPU
CPU利用率适合通用型服务，但对IO密集、内存敏感或事件驱动型应用容易误判。真正反映业务压力的，往往是请求速率、队列长度、处理延迟等自定义指标。
- Web服务优先用requests per second（通过Prometheus rate计算）——比CPU更能体现真实负载
- 消息消费类服务看pending message count或consumer lag
- 量子计算网关这类特殊服务，需接入quantum_queue_length等领域指标
- 所有自定义指标必须经prometheus-adapter注入HPA，确保单位一致、采样稳定
分层伸缩：负载层+资源层协同联动
单一维度伸缩有局限。理想状态是Pod副本数（HPA）和节点数量（Cluster Autoscaler或云厂商AS）形成配合：
- HPA负责秒级应对流量波动：当QPS超阈值，5秒内从3副本扩到8副本
- Cluster Autoscaler负责兜底：当新扩Pod因节点资源不足而Pending，1~2分钟内自动加购节点
- 设置HPA的minReplicas略高于日常均值（如日常400 QPS用4副本，min设为3），避免空闲时全缩容导致冷启动抖动
- 云厂商伸缩组中，最大实例数（maxSize）应≥压测得出的峰值所需节点数，预留10%缓冲防突发
闭环验证与持续迭代
伸缩策略上线后必须验证效果，否则只是纸上谈兵。重点看三类数据：
- 响应及时性：流量突增后，从指标超标到副本增加完成是否在30秒内（HPA默认同步周期15秒+调度时间）
- 资源利用率：扩缩后平均CPU是否稳定在60%~75%，长期低于50%说明策略偏保守，高于85%则可能缩容过猛
- 业务稳定性：扩缩期间错误率是否上升、P99延迟是否跳变——若出现，需检查就绪探针配置或应用优雅启停逻辑
每次大促或版本变更后，基于实际监控数据反向修正压测模型和伸缩阈值，让容量规划真正活起来。
