容量规划需以业务指标为核心，如下单qps、p95响应时间、kafka消费延迟等，结合多指标加权、滞后窗口与缓冲水位构建弹性扩缩容逻辑，并通过监控-决策-执行闭环及持续验证实现真正懂业务的自动伸缩。
容量规划在微服务架构中不能只看CPU或内存，而要回归业务本身——比如每秒下单数、API平均响应时间、队列积压量、模型推理吞吐（QPS）等。动态扩容模型的核心，是把业务压力信号翻译成可执行的实例伸缩动作。
识别关键业务指标
先明确哪些指标真正反映服务“忙不忙”：
- 请求类：订单创建QPS、嵌入向量生成TPS、支付回调成功率
- 延迟类：P95响应时间 > 800ms、数据库查询超时率 > 2%
- 队列类：Kafka消费延迟 > 60s、Redis待处理任务数 > 5000
- 业务状态类：未履约订单数持续增长、库存校验失败率突增
这些指标比“CPU使用率75%”更有业务意义。例如GTE模型服务，当/embed接口QPS突破120且P95延迟升至1.2s，就该扩容；单纯看CPU可能还在40%，但用户已感知卡顿。
构建指标到副本数的映射逻辑
避免简单阈值触发（如“QPS>100就加1个Pod”），应建立带缓冲和滞后的弹性规则：
- 设置目标水位线：例如将QPS稳定在单实例承载能力的60%~70%，留出缓冲空间应对突发
- 引入滞后窗口：连续3分钟QPS均值超过阈值才触发扩容，防毛刺误判
- 定义缩容保守策略：负载回落至目标水位线以下后，需等待5分钟确认平稳，再逐步缩容
- 支持多指标加权：例如 (0.4×QPS负载率 + 0.3×P95延迟分位 + 0.3×错误率) > 0.85 → 扩容
打通监控、决策与执行链路
业务指标要能驱动真实扩缩容，需三段闭环：
- 采集层：在服务埋点中直接上报业务维度指标（如embed_count、embed_error_total），用Prometheus抓取，不依赖日志解析
- 决策层：通过Prometheus Adapter暴露自定义指标，供Kubernetes HPA读取；或用KEDA监听Kafka积压量、Redis队列长度等外部信号
- 执行层：HPA调整Deployment副本数后，确保服务支持优雅启停——启动时预热模型/连接池，关闭前 drain 流量并完成正在处理的请求
验证与调优机制
上线后必须持续验证模型有效性：
- 用历史流量回放测试扩容响应时间（从指标越限到新Pod Ready是否≤90秒）
- 观察缩容后是否出现请求失败尖峰（说明缩太急或健康检查配置不合理）
- 每月回顾“扩容触发次数 vs 实际业务高峰吻合度”，校准水位线和窗口参数
- 对低频高价值服务（如风控决策），可叠加定时策略兜底——例如大促前2小时强制预扩容，不依赖实时指标
真正的业务指标驱动扩容，不是让系统更“自动”，而是让伸缩更“懂业务”。
