3. 延迟模型构建：服务依赖图、调用链拓扑、延迟分布模型、异常检测基线
延迟根因分析，说白了就是一场「找凶手」的游戏。但你不能凭空猜，得先画出现场地图、理清人物关系、摸清每个人的行为规律。这就是我常说的——模型先行。
这一章，我们聊聊怎么搭起这四根柱子：服务依赖图、调用链拓扑、延迟分布模型、异常检测基线。没有它们，你连延迟从哪冒出来的都不知道。
3.1 服务依赖图：你的系统长什么样？
我刚接手一个大型电商平台时，第一件事就是问团队：「你们有服务依赖图吗？」结果大家面面相觑。后来我花了两周，硬是从配置中心和调用日志里拼出了一张图——嗯，那图乱得像一团毛线球。
服务依赖图，本质上是一个有向图。每个节点是一个服务，每条边表示一次 RPC 调用或消息投递。它的核心价值在于：让你一眼看出「谁依赖谁」「谁可能是瓶颈」。
构建依赖图的三种主流方式：
- 静态解析：从代码配置、服务注册中心（如 Consul、Nacos）拉取依赖声明。优点是准，缺点是只能反映「设计时」的关系。
- 动态追踪：基于分布式追踪系统（如 Jaeger、Zipkin）采集运行时调用关系。这是我最推荐的方式——它反映的是「运行时」的真实情况。
- 流量嗅探：在网络层面抓包分析。适合无法侵入代码的遗留系统，但噪音大。
我个人习惯把依赖图分成三层：入口层（网关、BFF）、业务层（订单、支付、库存）、基础设施层（数据库、缓存、消息队列）。这样分层后，延迟问题一出现，你就能快速定位到「是哪一层出了幺蛾子」。
一个小技巧：依赖图不是画完就完事的。我建议每周自动更新一次，对比前后差异。有一次我发现某个服务突然多依赖了三个下游，一问才知道是某位同事偷偷加了调用——这就是「依赖腐化」的苗头。
3.2 调用链拓扑：从请求到响应的完整路径
服务依赖图是静态的，而调用链拓扑是动态的。它记录了一次请求从进入系统到返回结果，经过了哪些服务、每个环节花了多少时间。
为什么需要它？因为延迟往往不是均匀分布的。你想想看，一次请求可能经过 10 个服务，但 90% 的时间都耗在其中一个上。没有调用链，你只能瞎猜。
构建调用链拓扑，核心是Trace ID和Span ID的传播。每个服务在收到请求时，生成一个 Span，记录开始时间、结束时间、状态。所有 Span 通过 Trace ID 串联起来，就形成了一条完整的调用链。
// 一个典型的 Span 结构（简化版）
{
"traceId": "abc123",
"spanId": "span-001",
"parentSpanId": "span-000",
"serviceName": "order-service",
"operationName": "createOrder",
"startTime": 1700000000000,
"endTime": 1700000000150,
"duration": 150,
"tags": {
"http.method": "POST",
"http.status_code": 200
}
}我记得有一次线上告警说「下单接口 P99 延迟飙升到 5 秒」。我打开调用链拓扑一看，发现每次请求都会调用一个「会员等级计算」服务，而这个服务又去查了一个慢查询数据库。问题出在哪？一目了然。
避坑指南：我曾经遇到过采样率设置过高导致存储爆炸的问题。分布式追踪系统默认 100% 采样，在高并发下一天能产生 TB 级数据。建议生产环境采用自适应采样——正常流量下采样 1%，异常时自动提升到 100%。
3.3 延迟分布模型：别只看平均值
「平均延迟 50ms，系统很健康！」——这话我听过太多次了。但真相是，平均值会骗人。你想想看，如果 99% 的请求是 10ms，1% 的请求是 4 秒，平均值才 50ms 左右。但那个 1% 的用户，体验已经崩了。
所以，我只看百分位延迟：P50、P90、P99、P999。它们能告诉你延迟的真实分布。
| 百分位 | 含义 | 典型阈值（参考） |
|---|---|---|
| P50 | 一半请求比这个值快 | 50ms |
| P90 | 90% 的请求比这个值快 | 100ms |
| P99 | 99% 的请求比这个值快 | 300ms |
| P999 | 99.9% 的请求比这个值快 | 1s |
构建延迟分布模型，我常用的方法是直方图。把延迟按区间分桶（比如 0-10ms、10-50ms、50-100ms……），然后统计每个桶里的请求数。这样你就能看到延迟的「形状」——是集中在低延迟区，还是拖了一条长长的尾巴。
一个实用的经验：如果 P99 和 P50 差距超过 10 倍，说明系统存在严重的「长尾延迟」问题。这时候别去优化那 50% 的请求，而是去抓那 1% 的异常。
我习惯把延迟分布模型做成热力图，横轴是时间，纵轴是延迟，颜色深浅表示请求量。一眼就能看出延迟在什么时间段恶化——是高峰期？还是某个版本上线后？
3.4 异常检测基线：什么是「不正常」？
没有基线，你连「异常」都定义不了。基线就是系统在「正常」状态下的行为模式。
构建基线，我分三步走：
- 收集历史数据：至少 7 天的延迟数据，包含工作日和周末。我建议保留 30 天，因为有些周期性模式需要更长时间才能显现。
- 提取周期性特征：延迟通常有日周期（白天高、凌晨低）和周周期（工作日高、周末低）。用 STL 分解或 Prophet 模型把趋势、周期、残差分开。
- 设定动态阈值：别用固定阈值（比如「延迟超过 200ms 就告警」）。我推荐用移动平均 + 3σ，或者更鲁棒的MAD（中位数偏差）方法。
# 一个简单的动态基线计算（伪代码）
def compute_baseline(historical_data):
# 按小时聚合，计算每个小时的平均值和标准差
hourly_stats = {}
for hour in range(24):
values = [d for d in historical_data if d.hour == hour]
hourly_stats[hour] = {
'mean': mean(values),
'std': std(values)
}
return hourly_stats
def is_anomaly(current_value, hour, baseline):
# 如果当前值超过均值 + 3 倍标准差，视为异常
threshold = baseline[hour]['mean'] + 3 * baseline[hour]['std']
return current_value > threshold避坑指南：我曾经直接用 3σ 做基线，结果在双十一当天告警刷屏——因为流量暴涨导致延迟升高，但那是「预期内的异常」。后来我加了业务指标联动：如果 QPS 同时升高，延迟升高可能是正常的；如果 QPS 没变但延迟飙升，那才是真问题。
还有一个坑：基线不是一成不变的。系统在演进，用户行为在变化，基线也得跟着更新。我建议每天凌晨自动重新计算基线，并保留版本历史。这样如果某天基线「漂移」了，你还能回溯对比。
3.5 四者如何协同？
这四块模型不是孤立的。它们的关系是这样的：
- 服务依赖图告诉你「谁和谁有关联」
- 调用链拓扑告诉你「一次请求具体走了哪条路」
- 延迟分布模型告诉你「延迟到底长什么样」
- 异常检测基线告诉你「什么时候算出了事」
当告警触发时，你从依赖图找到可疑路径，用调用链定位具体节点，用延迟分布模型判断问题的严重程度，最后用基线确认这是否是真正的异常。这一套组合拳打下来，根因分析就不再是「大海捞针」了。
嗯，模型建好了，下一步就是怎么用这些模型去做根因分析。不过那是后面章节的事了。这一章的内容，够你回去好好梳理一下自己的系统了。