4. 弹性伸缩基础:水平伸缩 vs 垂直伸缩、弹性伸缩的触发条件
弹性伸缩是云原生架构下实现成本效率平衡的核心手段。本章从伸缩模式与触发条件两个维度,建立服务画像驱动容量规划的基础认知。
4.1 水平伸缩 vs 垂直伸缩
两种伸缩模式在资源粒度、生效速度、架构影响和成本模型上存在本质差异。下表从关键维度进行对比:
| 对比维度 | 水平伸缩(Scale-Out/In) | 垂直伸缩(Scale-Up/Down) |
|---|---|---|
| 资源粒度 | 实例数量(副本数) | 单实例规格(vCPU / 内存) |
| 生效速度 | 分钟级(启动新实例 + 注册发现) | 秒级(热迁移 / 在线调整) |
| 架构要求 | 无状态设计、分布式会话、共享存储 | 单体友好,无额外架构约束 |
| 上限约束 | 受集群配额 / 子网 IP 限制,理论上可无限扩展 | 受物理机 / 虚拟机规格上限约束 |
| 成本模型 | 线性增长,按需付费,适合突发流量 | 阶梯式增长,大规格实例单价更高 |
| 典型场景 | Web 服务、API 网关、无状态微服务 | 数据库、有状态中间件、批处理作业 |
关键结论:水平伸缩是云原生弹性伸缩的首选模式,垂直伸缩作为补充手段用于有状态组件或无法快速水平扩展的场景。服务画像应优先评估服务的无状态化程度,以确定伸缩模式。
下图展示了两种伸缩模式在资源池中的直观差异:
4.2 弹性伸缩的触发条件
触发条件是弹性伸缩策略的核心决策因子。根据数据来源和计算方式,触发条件可分为以下四类:
4.2.1 基于 CPU 利用率的触发
最传统且广泛使用的指标。适用于计算密集型服务,如批处理、视频转码、科学计算。
- 推荐阈值:目标利用率 60%–75%,扩容阈值 75%–85%,缩容阈值 30%–45%
- 注意事项:CPU 突刺(Spike)可能导致频繁抖动,建议配合 冷却时间(Cooldown) 和 聚合窗口(Evaluation Periods) 使用
- 局限性:对 I/O 密集型或内存密集型服务不敏感,容易产生误判
4.2.2 基于内存利用率的触发
适用于内存密集型服务,如缓存服务、内存数据库、实时计算引擎。
- 推荐阈值:扩容阈值 75%–85%,缩容阈值 40%–55%
- 注意事项:内存回收存在延迟,缩容策略应设置更长的稳定窗口,避免频繁缩容导致 OOM
- 局限性:Java 等语言堆内存管理复杂,GC 行为可能导致指标失真
4.2.3 基于请求量的触发
适用于 Web 服务、API 网关、消息队列消费者等流量驱动型服务。通常以 QPS(每秒请求数)、RPS(每秒请求数) 或 并发连接数 为指标。
| 指标类型 | 典型扩容阈值 | 典型缩容阈值 | 适用场景 |
|---|---|---|---|
| QPS / RPS | 单实例 QPS 上限的 70%–80% | 单实例 QPS 上限的 30%–40% | Web 服务、API 网关 |
| 并发连接数 | 单实例最大连接数的 60%–75% | 单实例最大连接数的 25%–35% | 长连接服务、WebSocket |
| 请求延迟(P99) | 超过 SLA 延迟阈值的 80% | 低于 SLA 延迟阈值的 50% | 延迟敏感型服务 |
最佳实践:请求量指标应结合 服务画像中的容量基准(如单实例最大 QPS)进行归一化处理,避免因实例规格差异导致阈值失效。
4.2.4 基于自定义指标的触发
当基础指标无法准确反映服务负载时,需要引入业务层面的自定义指标。常见实现方式包括:
- 队列深度:消息队列积压数量,适用于异步处理服务
- 连接池使用率:数据库连接池 / 线程池的活跃比例
- 业务吞吐量:每分钟订单数、每分钟交易量
- 自定义业务指标:如视频转码队列长度、AI 推理请求排队数
自定义指标通常通过以下方式接入弹性伸缩系统:
# 示例:Prometheus Adapter 配置自定义指标
apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
name: queue-worker-hpa
spec:
scaleTargetRef:
apiVersion: apps/v1
kind: Deployment
name: queue-worker
minReplicas: 2
maxReplicas: 20
metrics:
- type: Pods
pods:
metric:
name: queue_depth_per_pod
target:
type: AverageValue
averageValue: 50
- type: Resource
resource:
name: cpu
target:
type: Utilization
averageUtilization: 70
避坑提示:自定义指标采集链路较长(业务埋点 → 指标聚合 → 弹性控制器),存在 指标延迟 和 数据丢失 风险。建议设置 冗余触发策略,如同时监控队列深度和 CPU 利用率,避免单一指标失效导致服务过载。
下图展示了四种触发条件在弹性伸缩决策中的协同关系:
4.3 触发条件组合策略
单一指标触发存在盲区,生产环境推荐采用 多指标组合策略:
| 组合模式 | 逻辑关系 | 适用场景 | 示例 |
|---|---|---|---|
| AND 模式 | 所有指标均超过阈值才触发 | 避免误扩容,成本敏感场景 | CPU > 80% AND 请求延迟 > 500ms |
| OR 模式 | 任一指标超过阈值即触发 | 高可用优先,快速响应场景 | CPU > 85% OR 队列深度 > 100 |
| 加权模式 | 多指标加权评分后决策 | 复杂业务,需要精细控制 | 0.4×CPU + 0.3×QPS + 0.3×延迟 |
| 预测模式 | 基于历史数据预测未来负载 | 周期性流量,提前扩容 | 预测未来 5 分钟 QPS 超过阈值 |
服务画像驱动建议:在服务画像中标注 主导指标(Primary Metric)和 辅助指标(Secondary Metric)。例如,对于 CPU 密集型服务,CPU 利用率作为主导指标,请求延迟作为辅助指标;对于 I/O 密集型服务,则应将队列深度或磁盘吞吐量作为主导指标。