弹性伸缩在做什么
弹性伸缩按负载信号自动增减实例数，目标是在流量上升时补上容量、在低峰时收回成本。它的效果取决于三件事是否匹配：指标能不能及时反映真实负载、扩容速度能不能追上流量爬升、以及下游（数据库、第三方配额）能不能承接同步增长的连接与请求。指标选错或扩容太慢，伸缩反而会制造新的抖动。
基本信息
| 指标 | 队列深度与并发数通常比 CPU 更贴近服务负载，CPU 受 GC 与 IO 等待干扰 |
|---|---|
| 节奏 | 冷却时间与稳定窗口用来防抖动；步长兼顾快速响应与成本 |
| 准备 | 镜像与依赖预热、配置拉取时间决定新实例何时可用 |
| 边界 | 为下游连接数、第三方配额与许可证设置伸缩上限 |
典型使用场景
- 日常峰谷明显的业务：白天扩容、夜间缩容，控制常态成本
- 异步任务积压：按队列深度扩容 worker，处理完自动缩回
- 大促前预热：提前把最小实例数调高，避免峰值时来不及扩容
- 依赖限速场景：按下游配额上限约束最大实例数，防止打满对方
- 批处理与在线服务混跑：批处理任务按队列伸缩，不挤占在线容量
伸缩指标对照
| 指标 | 优点 | 注意 |
|---|---|---|
| CPU 使用率 | 采集简单、平台默认支持 | 受 GC、IO 等待与预热期干扰，容易误判 |
| 请求并发数 | 贴近在线服务负载形态 | 需按实例归一化，避免大实例被低估 |
| 队列深度或积压时长 | 直接反映待处理工作量 | 不适合无队列的同步链路 |
| 自定义业务指标 | 最贴合业务语义，如待处理订单数 | 需自建采集与上报链路，注意延迟 |
HPA 示例（按队列深度扩容）
HPA 示例（按队列深度扩容）
apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
name: order-worker
spec:
scaleTargetRef:
apiVersion: apps/v1
kind: Deployment
name: order-worker
minReplicas: 2
maxReplicas: 20
metrics:
- type: Pods
pods:
metric:
name: queue_depth
target:
type: AverageValue
averageValue: "50"
behavior:
scaleUp:
stabilizationWindowSeconds: 60
scaleDown:
stabilizationWindowSeconds: 300实施要点
- 实测扩容时延：从指标越阈到实例可服务，要短于流量爬升时间，否则峰值期间永远追不上
- 为依赖方设伸缩上限：数据库连接数、第三方调用配额与许可证同样会随实例增长
- 缩容比扩容保守：缩容窗口设得更长，并配合优雅下线，避免请求打到正在退出的实例
- 保留容量底座：高频业务设最小实例数，避免归零后冷启动拖慢首次请求
- 把伸缩事件与延迟曲线一起看，判断是容量不足还是指标滞后
伸缩主要调整无状态层：数据库、缓存与会话层的容量瓶颈靠架构（分片、读写分离、共享会话存储）与预案解决，单纯加应用实例只会把压力传导到下游。
指标滞后会引发震荡：采集周期长、平滑窗口短时，实例数会随噪声反复上下，既浪费成本也让负载波动传导到下游。