弹性伸缩指标不能二选一，CPU使用率衡量计算负载，请求并发数衡量入口流量，更合理的方案是按业务类型搭配使用这两类信号。先别急着在控制台里只勾一个指标，下面这部分会讲清楚为什么单一指标会在关键时刻掉链子，以及怎么组合才不出事。
弹性伸缩指标怎么看：CPU使用率与请求并发数对比
CPU使用率代表算力消耗，但响应慢半拍
CPU使用率这个参数,几乎每个云厂商控制台都有，它反映的是服务器在单位时间内的运算资源占用，对计算密集型的任务，比如视频转码、数据处理、批量渲染，CPU上涨的曲线能直接映射到负载变化。
问题在于CPU使用率是个“事后指标”，从业务请求进来，到CPU曲线爬坡，再到触发伸缩动作，中间存在不小的时间差，假如你的应用平时CPU只有30%，某次促销流量瞬间翻倍，CPU从30%涨到85%需要一定时间，而等到超过阈值再去启动一台新的云主机，新机器初始化又要等1-3分钟，等它真正能扛流量时，原本那台机器可能已经超负荷运行了好一阵子。
另一个坑是CPU使用率容易被“稀释”，举个例子，一个应用在单核机器上，每秒1000个请求就把CPU跑满，但如果用户都是访问缓存文件，每秒5000个请求CPU也不一定高，这时以CPU为唯一指标，伸缩策略基本失灵。
请求并发数贴近用户视角，但没法反映请求成本
请求并发数通常来自负载均衡或网关的七层连接统计,比CPU更贴近流量入口，看起来更直接，一些线上故障，譬如接口被爬虫刷量、短时间抢购，并发数会先于CPU拉响警报。
可并发数只管“量”，不管“难度”，一个图片请求和一个复杂的报表查询，在负载均衡看来都是“一次请求”，但后端消耗的CPU和内存差距可能是几十倍，如果业务里偶尔会有慢SQL、外部接口超时等状况，所有请求都会被卡住，连接数蹭蹭往上涨，但CPU利用率可能反而下降，因为线程都在等待。
业内共识认为,把这两类指标当作互相独立的条件，而不是对立面，才能覆盖更多的异常场景。
| 对比维度 | CPU使用率 | 请求并发数 |
|---|---|---|
| 反映本质 | 算力饱和度 | 流量到达量 |
| 响应速度 | 滞后，跟随负载变化 | 即时，流量尖刺无延迟 |
| 适合场景 | 计算密集、批处理任务 | 网关、API服务、Web入口 |
| 明显缺陷 | 被静态请求稀释 | 失真于重请求场景 |
| 典型扩容条件 | 阈值持续2-3分钟 | 并发数超过容量预估 |
弹性伸缩按并发数配置的适用场景，以及CPU适合的判断标准
首先明确一个基础概念,“弹性伸缩是什么”，它本质上是云平台根据预设指标自动增加或减少实例数量的机制，指标选得对，它是省成本利器；选得不对，它就是烧钱机器。
适合以CPU为核心的业务
计算密集型业务是最容易判断的,比如离线报表、数据清洗、机器学习推理、视频编码，这类任务的特点是CPU占用和任务量保持单调关系，任务多，CPU必然高；CPU不高，说明任务压力不大，在这种场景里，把CPU阈值设在60%-80%之间比较稳妥，低于60%扩得太早浪费钱，高于80%扩得太晚容易丢请求。
还有一类是中间件实例,比如Kafka、Redis集群，它们的CPU使用率和客户端吞吐量有强关联，也可以沿用类似的逻辑。
适合以并发为核心的业务
反过来看,网络转发、API网关、消息推送这类型服务，CPU常年不高，但也不能忽视扩容，很多突发流量其实是一瞬间的连接堆积，比如早上九点大量员工同时打卡，此时并发数明显上升，但CPU使用率可能还在20%徘徊，如果盯着CPU，等它涨上去，网关早就因为连接数太多而拒绝服务了。
这类业务的判断标准很简单：实例规格里的连接数上限和带宽上限才是寿命瓶颈，参考并发数来扩容，比CPU更贴合实际。
云主机与容器弹性伸缩指标选择的实操差异
主机层：用预测值弥补指标滞后
对于云主机,简米云、酷番云、华为云都提供了“目标跟踪伸缩”或“预测式伸缩”功能，原理不是等指标超阈值，而是根据历史数据预测未来一段时间的负载曲线，设置的时候，可以只用CPU作为目标，但系统会参考负载均衡的请求速率、并发连接数来调整计划，如果只选了普通定时策略，最好把上报指标周期设置为1分钟，统计窗口拉到5分钟，避免瞬时毛刺导致误扩。
容器层：K8s HPA天然支持多指标组合
Kubernetes的HPA（HorizontalPodAutoscaler）允许在一条规则里同时引用CPU、内存和自定义Metrics，这个能力非常实用，因为业务同时暴露CPU和并发特征时，就可以用“或”来处理。
一条基于双指标的HPA策略示例
- Pod平均CPU使用率,阈值70%
- Ingress每秒请求数,阈值2000
- 触发逻辑：任一指标连续2个周期（120秒）超过阈值的50%则触发评估
- 缩容条件：两个指标都低于阈值50%，持续5分钟
这样配置的价值在于,CPU扛不住时立即扩；流量猛增但CPU还没反应过来时，也能靠并发信号提前拉起实例。
对于云原生的用户,建议把可观测性数据纳入K8s自定义指标，比如P99延迟，一旦P99延迟超过500ms，说明后端已经处理不过来，此时无论CPU如何都应当扩容，这就是多指标组合带来的底气。
弹性伸缩指标监控的最佳实践：多指标确认与冷却策略
扩缩容判断逻辑不能一致
扩和缩要使用两套逻辑,扩容要“宁快勿慢”，缩容要“宁慢勿快”，具体落地时，建议用“或”触发扩容，用“与”触发缩容。
举个例子：电商活动大促时，并发高但CPU低，如果扩容条件写的是“CPU大于80%”，那这次活动大概率会挂，但如果写的是“CPU大于80%或并发大于5000”，机器能及时补齐，反过来，缩容时如果并发跌下去了，但CPU还维持在70%，就不能缩，只有两者都低于较低值，比如CPU低于30%且并发低于2000，持续10分钟，才考虑回收实例。
冷却时间和统计窗口是防抖的关键
伸缩动作执行后,需要设置冷却时间，冷却时间太短，新实例未注册到负载均衡时，监控数据仍然偏高，会重复触发扩容；冷却时间太长，流量回落时又无法及时缩容。
建议云主机场景设置300秒冷却时间,容器场景依据Pod启动速度缩短到60-120秒，不要用瞬时值作为触发条件，用1分钟平均值或3分钟平均值做判断，能过滤掉不少监控噪声。
弹性伸缩指标怎么设置比较合理：常见问题解答
CPU使用率高但请求并发数低，通常是什么原因？
说明业务里存在耗时较高的计算请求,比如大量数据聚合、图片滤镜处理或加密算法，这种情况下需要扩容，主要看CPU，并适当关注任务队列长度，给缩容留出更长的观察窗口。
并发数高但CPU低，还要不要扩容？
要扩,并发高意味着负载均衡和网关的连接压力大，不扩容可能导致连接数打满、请求排队，最终演变成雪崩，扩容时优先加网关或接入层节点，不必急着扩展后端计算资源。
弹性伸缩价格如何？按量付费会不会成本太高？
弹性伸缩功能本身不收费,收取的是新创建实例的实际运行费用，想控制成本，可以把普通按量付费实例和抢占式实例混用，抢占式实例承担可容忍中断的批处理流量，价格更低，对于日常流量稳定的业务，配合定时策略也能同时兼顾高峰扩容和成本预算。
最后的结论很明确：别再问“CPU和并发哪个更合理”，两个指标各有各的反应半径，核心是把当前业务的数据特征摸清楚，再实施“或触发扩容、与触发缩容”的组合策略，这样既不会错过流量尖峰，也不会在业务低谷时白白浪费钱。