应用副本增加后，数据库连接更多，接口却没有明显改善，说明瓶颈可能不在应用实例数量。自动扩容需要知道依据什么指标扩、扩出来的能力是否真的可用。
先定位限制吞吐的环节
区分应用 CPU、连接池等待、数据库锁与外部接口配额。若共享下游已经饱和，增加副本可能放大竞争。扩容策略应与整条业务路径的容量上限一起设计。
指标要能反映真实需求
CPU 适用于部分场景，但 I/O 等待和队列任务未必能仅由 CPU 表达。选择自定义或外部指标时，要说明来源、延迟、缺失行为和维护责任，避免复杂指标链本身成为盲点。
扩容不是瞬间完成
新实例需要调度、拉取镜像、启动和就绪，缓存预热也可能影响初期表现。突发流量下，容量预留与流量控制仍然重要。缩容同样需要考虑在途请求与后台工作。
验收扩缩容全过程
用可控流量观察触发时间、实例就绪、下游消耗和回落过程。成功标准是业务质量保持在约定范围，而不是副本曲线发生了变化。
常见问题：副本上限应该尽量放大吗？
需要受预算、节点和下游容量约束；无边界扩容可能把局部压力变成更大范围的故障。
技术参考：Kubernetes：水平自动扩缩容。具体接口与配置请结合使用版本核对。
将评估落实到你的系统
如果你的团队正遇到类似问题，可以从一条关键业务路径开始，整理现状、证据与约束，通过系统架构诊断明确优先级、候选方案和验证范围。