📚 课程目录第3章 Serverless平台容量调优概述

3. Serverless 平台容量调优概述：弹性伸缩的挑战与关键指标

Serverless 平台的核心承诺是“按需分配、按量计费”，但在实际生产环境中，容量调优远非简单的“有请求就扩容”那么简单。本章将剖析 Serverless 弹性伸缩面临的核心挑战，对比 KEDA 与传统 HPA 的架构差异，并定义容量调优的三大关键指标：QPS、并发与延迟。

3.1 Serverless 弹性伸缩的三大挑战

Serverless 工作负载通常具有突发性强、冷启动敏感、资源粒度细的特点，这给弹性伸缩带来了三个核心挑战：

冷启动延迟：从零副本扩容到第一个 Pod 就绪，通常需要 2-10 秒。如果流量陡增，冷启动会直接拖慢首字节时间（TTFB）。
指标滞后性：基于 CPU/内存的 HPA 指标更新周期为 15-30 秒，对于毫秒级波动的 Serverless 场景，这种滞后会导致“扩了来不及、缩了又突增”的震荡。
并发与资源的非线性关系：QPS 翻倍不一定意味着 CPU 翻倍；高并发下协程切换、连接池竞争可能使资源消耗呈超线性增长。

  💡 关键认知：Serverless 容量调优的本质，是在响应速度（快速扩容避免超时）与资源效率（避免过度预置造成浪费）之间找到动态平衡点。

3.2 KEDA 与传统 HPA 的对比

传统 HPA（Horizontal Pod Autoscaler）基于 Kubernetes 内置的 metrics-server 采集 CPU/内存，而 KEDA 引入了事件驱动架构，能够直接消费外部指标源（如 Kafka Lag、Prometheus 自定义指标、AWS SQS 队列深度）。

对比维度	传统 HPA	KEDA
指标来源	仅 CPU / 内存（metrics-server）	50+ 外部 Scaler（Kafka、RabbitMQ、Prometheus、HTTP 等）
伸缩粒度	最小 1 个 Pod，步长固定	支持 0→N 的从零伸缩，步长可自定义
响应延迟	15-30 秒（指标轮询周期）	秒级（事件驱动触发）
适用场景	稳态、资源密集型服务	突发、事件驱动、消息队列类工作负载
冷启动优化	不支持预热	支持 ScaledObject 的 `minReplicaCount` 与 `cooldownPeriod` 预热策略

📌 版本差异提示：KEDA 2.x 与 3.x 在 Scaler 配置格式、CRD 版本（v1alpha1 → v1alpha2）以及 fallback 机制上存在不兼容变更。本课程后续章节将专门讲解版本迁移中的校验要点。

3.3 容量调优的关键指标

在 Serverless 平台中，容量调优不能只盯着 CPU 使用率。以下三个指标构成了调优的“黄金三角”：

3.3.1 QPS（每秒查询数）

QPS 是衡量系统吞吐量的直接指标。在 KEDA 中，可以通过 prometheus-scaler 或 http-scaler 直接基于 QPS 进行伸缩。调优要点：

设置合理的 QPS 阈值（如单 Pod 目标 QPS = 200），避免频繁扩缩。
结合 cooldownPeriod 防止 QPS 抖动导致 Pod 震荡。

3.3.2 并发（Concurrency）

并发数直接影响 Pod 的资源竞争程度。对于 Go/Node.js 等异步框架，高并发下协程/线程切换开销显著。KEDA 的 kafka-scaler 本质就是基于分区消费并发数（Lag）来触发伸缩。

3.3.3 延迟（Latency）

延迟是用户体验的“生命线”。在容量调优中，延迟通常作为背压信号：当 P99 延迟超过阈值（如 500ms），应立即触发扩容。KEDA 可以通过 Prometheus Scaler 消费延迟指标，实现延迟驱动的弹性伸缩。

⚠️ 常见误区：不要单独使用 QPS 或 CPU 作为伸缩依据。例如：QPS 很低但单个请求计算量大，CPU 可能先飙升；反之，QPS 很高但请求轻量，CPU 可能仍处于低位。建议将三个指标组合成多指标伸缩策略。

3.4 指标组合策略示例

在实际调优中，建议采用“主指标 + 辅助指标”的组合策略。以下是一个基于 KEDA 的 ScaledObject 配置示例，同时监控 QPS 和延迟：

apiVersion: keda.sh/v1alpha2
kind: ScaledObject
metadata:
  name: serverless-app-scaler
spec:
  scaleTargetRef:
    name: my-serverless-app
  triggers:
  - type: prometheus
    metadata:
      serverAddress: http://prometheus.monitoring:9090
      metricName: qps_requests
      query: sum(rate(http_requests_total{app="my-serverless-app"}[1m]))
      threshold: "200"          # 单 Pod 目标 QPS
  - type: prometheus
    metadata:
      serverAddress: http://prometheus.monitoring:9090
      metricName: p99_latency
      query: histogram_quantile(0.99, sum(rate(http_request_duration_seconds_bucket{app="my-serverless-app"}[1m])) by (le))
      threshold: "0.5"          # P99 延迟超过 500ms 触发扩容
  cooldownPeriod: 60
  minReplicaCount: 1
  maxReplicaCount: 20

📐 调优建议：在 KEDA 3.x 中，支持 multipleTriggers 的 activationThreshold 字段，可以设置“激活阈值”避免指标毛刺导致误扩。例如，设置 QPS 激活阈值为 50，低于 50 时不触发伸缩。

3.5 本章小结

Serverless 容量调优的核心在于理解弹性伸缩的挑战（冷启动、指标滞后、非线性资源消耗），并正确选择伸缩工具（KEDA vs HPA）。关键指标 QPS、并发、延迟构成了调优的“黄金三角”，三者需要组合使用，而非孤立看待。下一章将深入讲解 KEDA 的 ScaledObject 配置语法与版本差异。