3. 流量（Traffic）深度解析：流量指标的定义、QPS/RPS/TPS的区别、流量突增与突降的监控策略

流量（Traffic）是衡量服务系统负载的核心信号，它直接反映了用户对系统的需求强度。在SRE实践中，对流量指标的精准定义与监控，是保障服务稳定性、进行容量规划与弹性伸缩的基础。本节将深入解析流量的本质、核心指标差异以及应对流量突变的监控策略。

3.1 流量指标的定义与核心维度

流量指标描述了系统在单位时间内接收到的请求数量。一个完整的流量定义通常包含以下三个核心维度：

• 请求来源：区分用户请求、内部服务调用、定时任务、外部回调等。
• 请求类型：区分读请求（GET/QUERY）、写请求（POST/PUT/DELETE）、长连接、流式请求等。
• 请求路径：区分不同的API端点、微服务接口或资源路径。

3.2 QPS / RPS / TPS 的区别与适用场景

这三个术语经常被混用，但在严谨的SRE场景下，它们有明确的区别。理解这些差异有助于选择正确的指标来评估服务健康度。

3.3 流量突增与突降的监控策略

流量突变（无论是突增还是突降）都是服务不稳定的重要信号。SRE需要建立分层级的监控策略来应对。

3.3.1 流量突增的监控与应对

流量突增通常由营销活动、热点事件、爬虫攻击或上游服务重试风暴引起。监控策略应聚焦于“快速发现”与“自动防护”。

• 基线对比告警：基于历史同期（如昨日同时段、上周同一天）的流量数据，设定动态阈值。当当前流量超过基线 200% 或 300% 时触发告警。
• 速率限制（Rate Limiting）：在网关层配置基于用户、IP或的速率限制，防止单点流量冲垮后端。
• 自动弹性伸缩：结合容器编排平台（如Kubernetes），配置基于RPS指标的HPA（Horizontal Pod Autoscaler），实现自动扩容。
• 熔断降级：当下游依赖服务因流量突增而响应变慢时，上游服务应主动熔断，避免级联故障。

3.3.2 流量突降的监控与应对

流量突降往往比突增更隐蔽，但同样危险。它可能意味着用户流失、网络分区、DNS解析失败或上游服务故障。

• 零流量告警：对于核心业务接口，设置“连续N分钟流量为0”的告警，这通常是严重故障的标志。
• 同比/环比下降告警：当流量相比历史基线下降超过 50% 或 80% 时触发告警，用于发现非突发性的流量异常。
• 多维度下钻：当总流量下降时，立即按“机房”、“可用区”、“版本”、“运营商”等维度下钻，快速定位是局部故障还是全局问题。
• 健康检查与自动恢复：确保负载均衡器的健康检查机制正常工作。当检测到后端实例流量为0时，自动重启或摘除异常实例。

3.4 流量监控架构图

下图展示了一个典型的流量监控与自动化响应架构，涵盖了从数据采集到策略执行的完整链路。

3.5 流量突变监控策略对比表

下表总结了针对流量突增与突降的不同监控策略及其核心关注点：

3.6 流量指标采集代码示例

以下是一个使用 Prometheus 客户端库（Python）采集 RPS 指标的示例，展示了如何通过标签区分不同维度的流量：

from prometheus_client import Counter, start_http_server
import time

# 定义一个计数器指标，用于统计每秒请求数
# 通过 labels 区分请求方法、路径和状态码
REQUEST_COUNT = Counter(
    'http_requests_total',
    'Total HTTP Requests',
    ['method', 'endpoint', 'status']
)

def process_request(method, endpoint):
    # 模拟请求处理
    status = "200"  # 假设请求成功
    # 增加计数器
    REQUEST_COUNT.labels(method=method, endpoint=endpoint, status=status).inc()

if __name__ == '__main__':
    # 启动 Prometheus HTTP 服务，用于暴露指标
    start_http_server(8000)
    while True:
        # 模拟收到请求
        process_request("GET", "/api/users")
        process_request("POST", "/api/orders")
        time.sleep(0.1)