3. Latency 测量方法：客户端测量 vs 服务端测量，端到端延迟与组件延迟
在可观测性工程中，延迟（Latency）的测量方式直接决定了 SLO 的准确性。同一个请求，从客户端视角和服务端视角测量出的延迟可能相差数倍。本章深入剖析两种测量范式的本质差异，并拆解端到端延迟与组件延迟的构成关系，为后续门限设定提供测量基础。
3.1 客户端测量 vs 服务端测量
客户端测量反映的是用户真实体验，包含网络传输、DNS 解析、TLS 握手、排队等待等全部环节；服务端测量仅覆盖请求到达服务器后的处理时间。两者之间的差值称为“网络与传输开销”。
| 对比维度 | 客户端测量 | 服务端测量 |
|---|---|---|
| 测量位置 | 浏览器、移动 App、API 调用方 | 负载均衡器、应用服务器、中间件 |
| 包含范围 | 网络延迟 + 服务端处理 + 响应传输 | 仅服务端处理（含队列等待） |
| 典型指标 | First Byte (TTFB), Page Load, Apdex | p50/p95/p99 服务端响应时间 |
| 对 SLO 的意义 | 直接反映用户体验，适合用户面 SLO | 反映系统健康度，适合运维面 SLO |
| 干扰因素 | 客户端性能、网络抖动、缓存命中 | 服务端资源争用、GC、连接池耗尽 |
关键认知： 客户端测量是 SLO 的“真相来源”，服务端测量是故障排查的“手术刀”。两者不可互相替代，必须同时采集并建立关联。
3.2 端到端延迟与组件延迟
端到端延迟（End-to-End Latency）是指从客户端发出请求到收到完整响应的总耗时。组件延迟（Component Latency）是指请求在单个服务、数据库、缓存或中间件中的停留时间。两者构成“分解-聚合”关系：
- 端到端延迟 = Σ(组件延迟) + Σ(网络跳转延迟) + 序列化/反序列化开销
- 组件延迟的累加值通常小于端到端延迟，因为存在并行处理和流水线重叠。
- 端到端延迟的异常升高，往往由某个组件延迟的“长尾”引发。
实战建议： 在 SLO 门限设定时，先确定端到端延迟的容忍上限（如 500ms），再按比例分解到各组件（如 API Gateway 100ms、业务服务 200ms、数据库 100ms、网络预留 100ms）。
3.3 两种测量方法的架构对比
下图展示了客户端测量与服务端测量的数据采集路径差异，以及端到端延迟与组件延迟的对应关系。
3.4 测量方法选型决策矩阵
在实际 SRE 工作中，选择哪种测量方法取决于监控目标和系统架构。以下矩阵帮助团队快速决策：
| 场景 | 推荐测量方法 | 理由 |
|---|---|---|
| 用户面 SLO 监控 | 客户端测量（RUM/APM） | 直接反映真实用户体验，包含网络与设备差异 |
| 服务健康度告警 | 服务端测量（Prometheus/OTel） | 排除网络干扰，精准定位服务瓶颈 |
| 容量规划与压测 | 服务端测量 + 组件延迟分解 | 识别各组件瓶颈，指导扩缩容决策 |
| 故障排查与根因分析 | 端到端追踪（分布式 Tracing） | 关联客户端与服务端数据，定位长尾组件 |
| 第三方 API 依赖监控 | 客户端测量（调用方视角） | 无法控制第三方服务端，只能从调用方测量 |
3.5 端到端延迟与组件延迟的关联分析
下图展示了一个典型请求的延迟瀑布图（Waterfall），清晰呈现端到端延迟如何由多个组件延迟叠加而成。
3.6 测量方法选择的最佳实践
常见陷阱： 仅依赖服务端测量来制定用户面 SLO。服务端 p99 为 200ms 时，客户端 p99 可能已达 800ms，导致 SLO 达标但用户投诉不断。必须建立客户端到服务端的延迟映射关系。
- 双轨采集： 同时部署 RUM（客户端）和 APM（服务端），通过 Trace ID 关联两端数据。
- 网络基线化： 定期测量客户端与服务端之间的网络 RTT，作为延迟分解的固定偏移量。
- 组件延迟预算： 在 SLO 设定阶段，将端到端延迟目标按比例分配到各组件，形成“延迟预算表”。
- 异常检测联动： 当端到端延迟升高时，自动触发组件延迟的对比分析，快速定位瓶颈组件。
- 测量覆盖验证： 定期检查是否所有关键路径都被客户端和服务端测量覆盖，避免“测量盲区”。
工具推荐： OpenTelemetry 的分布式追踪天然支持端到端与组件延迟的关联分析。配合 Prometheus 的 Histogram 指标，可以同时输出客户端和服务端的延迟分布，为 SLO 门限设定提供完整数据基础。