金融交易系统：用全链路追踪定位一笔订单的耗时瓶颈

一笔订单为什么慢

金融系统里最经典的问题：用户说「下单很慢」，但到底慢在哪？网关？风控？账户？清算？数据库？没有链路追踪，只能靠日志逐层猜，一条链路跨十几个服务，人工排查要半天。

全链路追踪的价值，是把一笔交易从头到尾每个环节的耗时串成一条链，一眼看到瓶颈在哪一段——也看到它不在哪一段。

交易链路的关键指标

金融场景对可观测性的要求比普通业务更严：

• 耗时：不是平均耗时，而是 P99/P999 分位。平均值会把极少数慢请求淹没掉，而这些慢请求往往来自你最值钱的用户。
• 成功率：下单成功率、支付成功率，按渠道、按卡类型拆开看。
• 关联性：一笔交易要能关联到具体用户、订单号、商户号，排查时能反查。

OBSERVE 支持在 span 上打业务标签（order_id、user_id、merchant_id），让技术链路和业务实体挂钩。这一步把「某个请求慢了」变成「商户 7 的订单 884213 卡在风控查询」。

定位一次真实故障

一个交易团队的真实案例（脱敏后）：

现象是「每天 14:00 左右下单成功率掉 1 个点」。看监控，14:00 的 P99 耗时从 300ms 飙到 4s，但只在个别渠道出现。

排查过程：

1. 按时间窗口过滤 14:00 前后的 trace，筛选 success=false 的交易。
2. 对比慢交易和正常交易的 span 耗时分布，发现慢交易都卡在「风控查询」这一 span，耗时 3.5s。
3. 顺藤摸瓜看风控服务的日志，发现 14:00 有定时任务在刷缓存，导致连接池打满。
4. 把定时任务错峰到凌晨，问题消失。

整个过程从「发现异常」到「定位根因」不到 30 分钟，靠的就是 trace 里完整记录了每个 span 的耗时和错误。没有追踪，第 2 步——知道是卡在风控而不是网关或数据库——就得靠一天的人肉翻日志。

怎么打点才有用

1. 入出口都要埋：网关、RPC 框架、DB、MQ、缓存、第三方接口，每一跳都要 span。缺一跳，链中间就多一个盲点。
2. 带上业务 ID：order_id、user_id 打进 span 属性，别只留技术字段。
3. 错误要标记：异常时把异常类型和堆栈写进 span 事件，而不是只记一条日志。
4. 采样要有策略：全量采集贵，但金融交易不能只采 1%。建议对 success=false 的交易 100% 采集，成功的按 10% 采样。

给金融团队的建议

• 别只看平均耗时，P99 才是用户体验的真相，P999 才是最坏情况的真相。
• 把 trace id 写进业务日志和用户投诉工单，用户报障时能直接定位到他那笔交易。
• 核心链路（下单、支付、清算）单独建 Dashboard，P1 告警阈值按 P99 而不是平均值设。