弹性伸缩指标该优先看请求并发，CPU使用率只适合做辅助阈值，两者结合才能避免频繁抖动和资源浪费。
关于弹性伸缩，很多人习惯盯着CPU监控面板，一看超过70%就赶紧加机器，但实战中你会发现，CPU高不一定代表系统真的扛不住，CPU低也不代表服务就绝对安全，业内专家指出，弹性伸缩的本质是为请求提供足够的处理能力，而不是为CPU占用率服务，下面这套判断逻辑,是我在多个生产环境里验证过的。
为什么看CPU容易误判：三个常见陷阱
CPU空闲但请求堆积的典型场景
假设你的服务是IO密集型，比如大量读写数据库或调用外部API，此时线程都在等待网络返回，CPU占用率可能只有20%，但请求队列已经堵了几千条，如果只按CPU扩容，系统会一直处于“假健康”状态,直到超时雪崩。
CPU飙高但请求量平稳的特殊情况
某些业务在凌晨会跑批处理任务，或者某个正则表达式触发灾难性回溯，这时候CPU冲到90%，但前端请求并发量并没有变，如果按CPU缩容，正好把处理批任务的机器缩掉,引发连锁故障。
多实例负载不均导致CPU指标失真
负载均衡算法如果是轮询，不同实例的CPU可能相差30%以上，你盯着平均值做伸缩，实际上一部分机器已经过热，另一部分还在闲置，请求并发指标在网关层统计时更均匀,能直接反映真实压力。
请求并发指标有哪些优势
直接关联用户体验
用户感受到的延迟和超时，本质上是请求排队等待的时间，并发数（也就是正在处理中且未返回的请求数）跟排队长度直接相关，当并发数超过某个阈值，意味着新请求要等待已有请求释放线程，此时无论CPU高不高,都应该扩容。
更平滑地反映短时流量尖峰
以秒杀场景为例，一分钟内可能涌入数千个请求，CPU曲线是逐渐爬升的，但并发数会瞬间跳高，等你看到CPU涨到80%再扩容，往往已经过去两三分钟，用户早就流失了，并发指标的延迟更低,能提前触发扩容动作。
天然适配无状态服务的伸缩逻辑
现代云原生架构下，应用水平扩展的目标是“每个实例处理固定数量的请求”，比如单实例能扛50并发，那么500并发就需要10台机器，按并发数去设伸缩策略，非常直观，而CPU跟业务逻辑耦合度太高，不同代码的CPU消耗差异极大,很难给出统一的经验值。
CPU指标何时仍然有用：辅助角色与兜底机制
用于发现代码级性能劣化
如果请求并发正常，但CPU突然持续走高，大概率是代码出了bug（比如死循环、内存泄漏导致频繁GC），这时候CPU作为健康检查指标是有意义的，可以作为告警项,而不建议直接作为扩缩容触发项。
用于保护宿主机或底层资源
在某些物理机部署场景下，CPU过高会影响同机其他应用，此时CPU可以作为兜底扩缩容策略，防止单台机器被拖垮，但注意，这属于基础设施层面的保护,跟业务容量规划是两码事。
混合策略的推荐配置方法
我通常建议这样设置：
- 主指标：按请求并发数（网关层统计，比如QPS×平均处理时间）设定扩容阈值
- 辅助指标：CPU使用率超过85%持续5分钟，进行额外扩容
- 缩容策略：并发数低于扩容阈值30%持续15分钟，且CPU低于40%，才允许缩容
- 冷却时间：每次伸缩动作后至少等待5分钟再评估下一次动作
这样的组合既避免了CPU误判,又能兜底极端情况。
不同业务场景下弹性伸缩指标怎么选
高并发Web应用：看并发请求数是第一选择
业务场景：电商大促、活动抽奖、信息流接口，这类系统的瓶颈通常在线程池、数据库连接池等有限资源，用并发数能精准反映容量压力，比如Spring Boot默认Tomcat线程池200，你可以直接设置“当前活跃请求数超过150就扩容”的策略,非常符合架构实际。
计算密集型任务：CPU指标优先级更高
业务场景：视频转码、数据分析、图片处理，这类任务没有大量外部IO，请求进入后就是纯CPU计算，此时并发数高反而说明任务堆积，但每个任务的CPU消耗基本固定，用CPU使用率来伸缩更直接，比如CPU达到70%时增加worker实例。
混合型业务：按接口维度拆分伸缩策略
业务场景：一个服务里既有查询接口，又有文件上传接口，建议不要用同一个伸缩策略，而是按照不同的请求路径来统计并发数，比如查询接口并发500触发扩容，上传接口并发100触发扩容（因为上传耗时长、内存占用高），目前主流云平台的弹性伸缩组支持配置多条触发规则,你可以用标签或路径区分。
关于弹性伸缩指标设置的三个实操建议
先压测出单实例的并发承载上限
别凭空拍脑袋，用压测工具（如JMeter、wrk）对你的服务跑一轮压力测试，观察在不同并发数下的响应时间，找到“响应时间明显变长”的拐点，那才是你的真实扩容阈值，很多团队把阈值设在最大承载的60%-70%,留出缓冲。
使用预测式伸缩弥补反应式伸缩的延迟
传统按指标伸缩是“先出问题再扩容”，总会有一段服务劣化的时间，现在云平台（如简米云、酷番云、AWS）都提供预测式伸缩功能，基于历史流量曲线预判未来的请求量，建议把预测式伸缩作为主策略，请求并发指标作为校正策略,两者结合效果最好。
监控数据至少保留30天用于调参
弹性伸缩的阈值不是一次设置终身有效的，你需要定期回看伸缩记录，分析每次扩容是否及时、缩容是否过早，在运维平台上把“并发数”“CPU”“伸缩事件”放在同一个dashboard,每月复盘一次。
Q&A：弹性伸缩指标常见疑问
请求并发和QPS有什么区别，看哪个更准？
QPS是每秒新进入的请求数，并发是当前同时正在处理的请求数，举个例子，QPS是100，如果每个请求耗时1秒，那么并发就是100；如果每个请求耗时0.1秒，并发只有10，对于弹性伸缩来说，并发数更能反映系统压力，因为它直接关联线程占用和队列长度，建议在监控面板上同时展示这两个指标,但触发规则优先使用并发数。
多指标组合会不会导致伸缩频繁？
会，但可以通过“与或逻辑”和“冷却时间”解决，比如设置“并发数超过阈值且CPU超过60%”才扩容，这就是与逻辑，减少误触发，或者设置扩容条件为任一指标满足，但增加冷却时间（比如5分钟），避免两个指标交替波动导致反复伸缩，另外缩容条件一定要比扩容条件严格，比如扩容阈值是80并发,缩容阈值设为30并发且持续20分钟。
没有网关层统计请求并发，怎么办？
如果技术栈里没有独立网关，可以在应用框架层面暴露指标，Spring Boot Actuator提供了http.server.requests指标，可以计算活跃请求数，Nginx可以统计ngx_http_stub_status_module的Active connections，如果这些都难改造，可以临时用接入层的访问日志，分析每秒请求数乘以平均响应时间估算并发，但精度稍差，最稳妥的方式还是改造应用，暴露一个自定义监控端点,用Prometheus采集。
首发原创文章，作者：王坚，如若转载，请注明出处：https://idctop.com/article/622346.html
