📚 课程目录第4章弹性伸缩基础

4、弹性伸缩基础：水平伸缩与垂直伸缩、基于阈值的伸缩、基于预测的伸缩、基于事件的伸缩

弹性伸缩是服务画像驱动 SLA 落地的核心执行层。没有正确的伸缩基础，任何健康口径量化都只是纸上谈兵。本章从两个维度展开：伸缩模式（水平 vs 垂直）和伸缩触发方式（阈值、预测、事件）。理解这些基础，才能为后续“服务画像-弹性策略映射”建立技术共识。

4.1 水平伸缩与垂直伸缩

伸缩模式决定了资源调整的粒度与速度。下表对比两种模式在 SLA 场景下的关键差异：

对比维度	水平伸缩（Scale Out/In）	垂直伸缩（Scale Up/Down）
操作对象	增加/减少实例数量	增加/减少单实例规格（CPU/内存）
伸缩粒度	整实例（通常 1 个副本）	按规格阶梯（如 2C4G → 4C8G）
生效速度	分钟级（镜像拉取+调度）	秒级（热调整或重启）
SLA 影响	扩容期间请求分布变化，需配合负载均衡	缩容可能触发连接中断，需优雅排空
适用场景	无状态服务、微服务、Web 层	有状态服务、数据库、单机瓶颈
成本模型	线性增长，按实例数计费	阶梯式增长，高规格溢价明显

运维建议：在服务画像中，水平伸缩应作为默认首选模式，因为它与分布式架构的故障域隔离天然匹配。垂直伸缩仅用于无法水平拆分的组件（如单节点数据库），且需设置规格上限以避免单点过大。

下图展示了水平伸缩与垂直伸缩在集群拓扑上的直观差异：

4.2 基于阈值的伸缩

基于阈值的伸缩是最成熟、最广泛使用的触发方式。它通过预设指标上下界，当指标持续越界时触发伸缩动作。核心要素包括：

指标选择：CPU 使用率、内存使用率、请求 QPS、响应延迟 P99、连接数等。
阈值设定：上限触发扩容，下限触发缩容。需设置冷却时间避免抖动。
聚合窗口：通常取 1-5 分钟的平均值或百分位值，过滤瞬时毛刺。
步长策略：每次伸缩的实例数或规格变化量。

常见陷阱：阈值伸缩容易陷入“振荡循环”——指标刚降到下限触发缩容，缩容后负载回升又触发扩容。解决方案：设置合理的冷却时间（Cooldown）和上下阈值之间保留死区（Dead Zone），例如扩容阈值 70%，缩容阈值 30%，中间 30%-70% 为稳定区。

下表给出一个典型 Web 服务的阈值伸缩配置示例：

指标	扩容阈值	缩容阈值	聚合窗口	冷却时间	步长
CPU 使用率	> 75% 持续 3 分钟	< 30% 持续 5 分钟	1 分钟平均值	扩容后 300s / 缩容后 600s	+2 实例 / -1 实例
请求 QPS	> 1000/s 持续 2 分钟	< 300/s 持续 5 分钟	1 分钟 P50	扩容后 180s / 缩容后 300s	+50% 当前实例数
响应延迟 P99	> 500ms 持续 2 分钟	< 200ms 持续 5 分钟	1 分钟 P99	扩容后 120s / 缩容后 600s	+3 实例 / -2 实例

4.3 基于预测的伸缩

基于预测的伸缩利用历史数据训练模型，提前预判未来负载变化，在负载到达之前完成资源准备。它解决了阈值伸缩“被动响应”的滞后问题。

预测伸缩的核心流程：

数据采集：收集至少 14 天以上的历史指标（QPS、CPU、连接数等），按小时/天粒度聚合。
模式识别：识别日周期、周周期、节假日等规律性模式。
模型训练：使用 ARIMA、Prophet、LSTM 等算法生成预测曲线。
策略生成：将预测结果转化为定时伸缩计划或动态调整基线。
反馈修正：对比实际负载与预测值，调整模型参数。

  适用条件：预测伸缩最适合周期性明显的服务，例如：早高峰资讯类应用、晚高峰电商平台、月末结算系统。对于突发性流量（如热点事件），预测伸缩无法覆盖，需配合阈值或事件伸缩兜底。

下图展示预测伸缩与阈值伸缩的时序配合关系：

4.4 基于事件的伸缩

基于事件的伸缩响应特定业务事件或基础设施事件，通常用于处理不可预测的突发流量或计划内变更。事件来源包括：

业务事件：秒杀活动开始、直播开播、大促流量预热、批量任务提交。
基础设施事件：节点故障、AZ 故障、网络分区、自动恢复。
运维事件：版本发布、配置变更、数据库迁移、计划内停机。
外部事件：上游服务降级、下游限流、第三方 API 超时。

事件伸缩通常通过 Webhook 或 消息队列 触发，与 CI/CD 管道、监控告警系统、业务中台集成。典型实现方式：

# 事件伸缩 Webhook 示例（Kubernetes HPA + Prometheus Adapter）
apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: event-driven-hpa
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: web-service
  minReplicas: 5
  maxReplicas: 50
  metrics:
  - type: Object
    object:
      metric:
        name: events_total
      describedObject:
        apiVersion: v1
        kind: Service
        name: event-bus
      target:
        type: Value
        value: "100"  # 每秒事件数超过 100 触发扩容
  behavior:
    scaleUp:
      stabilizationWindowSeconds: 0  # 事件伸缩不设冷却，立即响应
      policies:
      - type: Percent
        value: 200
        periodSeconds: 60
    scaleDown:
      stabilizationWindowSeconds: 300
      policies:
      - type: Pods
        value: 5
        periodSeconds: 60

最佳实践：事件伸缩应作为最高优先级的触发方式，覆盖阈值和预测无法处理的场景。建议为每个事件定义明确的伸缩预案，包括目标实例数、预热策略、优雅排空策略。事件结束后，通过冷却窗口逐步回缩，避免“脉冲式”伸缩。

4.5 三种触发方式的协同策略

在实际生产环境中，三种触发方式并非互斥，而是形成分层协同的伸缩体系：

触发方式	响应速度	适用场景	协同角色
基于事件	秒级	突发流量、计划内变更、故障转移	第一响应层，立即执行
基于阈值	分钟级	常规负载波动、无规律流量	持续监控层，兜底保障
基于预测	小时级（提前规划）	周期性负载、可预见的流量波峰	规划层，提前准备资源

推荐的分层策略：预测伸缩做长期规划，提前调整基线实例数；阈值伸缩做短期调整，应对预测偏差；事件伸缩做紧急响应，处理不可预测的突发。三层配合，才能实现 SLA 要求的“既不过度配置浪费成本，也不配置不足影响可用性”。