📚 课程目录第3章流量（Traffic）指标详解

3. 流量（Traffic）指标详解：定义、建模与阈值设定

流量指标是衡量系统请求压力的第一道防线。在可观测性体系中，流量数据直接反映用户行为、业务负载与系统容量水位。本节将系统讲解 QPS/RPS/TPS 的核心定义、吞吐量建模方法、突发流量识别技术以及阈值设定的工程实践。

这三个指标常被混用，但在不同架构场景下具有明确的语义差异。下表从定义、适用场景与典型计算方式三个维度进行对比：

  工程要点：在微服务架构中，建议同时采集 RPS（入口层）与 TPS（业务层）。RPS 反映系统负载，TPS 反映业务吞吐。当 RPS 与 TPS 出现明显背离时（如 RPS 高但 TPS 低），通常意味着大量请求被拒绝、超时或返回错误，是容量瓶颈的早期信号。

吞吐量建模的目标是建立流量与系统资源（CPU、内存、IO）之间的量化关系，为容量规划与阈值设定提供依据。常用的建模方法包括以下三种：

线性回归模型：基于历史监控数据，拟合 RPS 与 CPU 使用率、内存占用等资源指标之间的线性关系。适用于稳态业务，模型简单，可快速给出容量预估。
排队论模型（M/M/c）：将请求视为到达过程，服务节点视为服务台，通过平均到达率 λ 与平均服务率 μ 计算系统稳态指标（如平均排队长度、平均响应时间）。适用于有明确服务时间的同步调用场景。
压力测试标定法：在预发或灰度环境执行阶梯式压测，记录不同 RPS 下的延迟、错误率与资源消耗，直接绘制吞吐量-延迟曲线。这是最可靠的方法，但需要定期更新。

以下 SVG 图展示了吞吐量建模的核心流程与数据流向：

突发流量（Traffic Spike）是导致系统雪崩的最常见诱因。识别突发流量不能仅依赖固定阈值，需要结合动态基线检测与多维度特征分析。以下是三种主流识别方法：

方法	原理	优势	局限
滑动窗口统计	以秒级粒度统计当前窗口 RPS，与过去 N 个窗口的均值/中位数对比	实现简单，计算开销低	对周期性业务（如整点秒杀）误报率高
同比/环比基线	对比当前时刻与昨日/上周同期的流量值	消除时间周期性影响	需要存储历史基线，对业务增长趋势不敏感
机器学习异常检测	使用 ARIMA、Prophet 或 Isolation Forest 建模流量时序，检测偏离预测区间的点	适应复杂模式，准确率高	需要训练数据与模型维护成本

最佳实践：生产环境建议采用“滑动窗口 + 同比基线”双层检测。第一层用滑动窗口快速捕获秒级突增（如 3 秒内 RPS 翻倍），第二层用同比基线过滤掉已知的周期性高峰（如每日 10:00 的业务高峰），降低误报率。

流量阈值的设定需要兼顾“提前发现”与“避免误报”。以下是经过生产验证的四步设定法：

采集基线数据：连续采集 7~14 天的流量数据，覆盖工作日、周末、业务高峰与低谷时段，构建完整的流量画像。
计算统计特征：按小时粒度计算 P50、P90、P99 分位值以及标准差 σ。通常以 P99 + 3σ 作为“警告阈值”，以 P99 + 5σ 作为“严重阈值”。
引入业务因子：对于已知的大促、秒杀、运营活动时段，将阈值上浮 50%~200%，避免活动期间频繁告警。
动态调整与回测：阈值上线后持续观察告警准确率与召回率，每周回测一次，根据误报/漏报情况微调系数。

以下 SVG 图展示了阈值设定与动态调整的完整闭环：

以下清单总结了流量指标告警配置的核心检查项，可作为 SRE 团队日常巡检与事故复盘的标准参考：

常见陷阱：不要仅依赖单一流量指标。例如，RPS 正常但 TPS 骤降，可能意味着请求被快速拒绝（限流生效），此时系统实际已处于过载状态。务必同时监控 RPS、TPS、错误率与延迟，形成四维交叉验证。