金融交易链路追踪方案：一笔支付到底慢在哪

支付链路的定位难题

一笔支付从下单、风控、收银台、渠道扣款到对账，可能横跨十几个服务、多个数据库。用户投诉「扣款慢」，客服能给的只有交易号，而研发要顺着十几个服务的日志一点点对时间，常常半小时过去了还没找到慢在哪一跳。

解法是把链路追踪当基础设施来建：从入口到出口，每跳都带同一个 trace id，慢在哪一跳一目了然。

三件事先做对

1. trace id 全链路透传：网关、RPC、消息队列、异步线程池都要透传 trace 上下文，缺一个就断链。消息队列最容易漏——消费端要显式从消息头取回 trace 上下文，而不是新开一个；
2. 关键节点埋点：除了框架自动埋点，业务关键动作（风控决策、渠道调用、对账写库）要打 span，标注成功/失败/耗时；
3. 统一采样策略：正常流量按比例采样（如 10%），但错误和慢交易要 100% 采样——这正是故障排查最需要的数据。

慢交易怎么定义

「慢」要定义成可度量的规则，而不是凭感觉。建议按渠道分档设阈值：

slow-txn:
  pay:     { p95_ms: 800,  alert: 2000 }
  refund:  { p95_ms: 1200, alert: 3000 }
  query:   { p95_ms: 300,  alert: 1000 }

超过 alert 阈值的交易自动打上「慢交易」标签并全量保留 trace，配合告警规则，超过一定比例就通知值班群。这样「慢在哪」和「多慢算慢」都有依据。

一次典型排障

某次凌晨，pos 渠道扣款平均耗时从 350ms 涨到 900ms。按 trace id 检索该渠道交易，发现都卡在「渠道路由」这一跳，往下钻是路由服务里一个第三方 SDK 的同步调用超时。回滚该 SDK 版本后恢复。整个过程从发现到定位不到十分钟。

如果当时没有全链路 trace，只能对着三个服务的日志人肉对时间，运气不好要折腾一晚上。

谁来查、查什么

金融交易数据敏感，trace 的可见范围要按角色收口：

• 值班工程师：只能查自己负责服务的 trace，且敏感字段默认脱敏；
• 业务/客服：只读查看交易状态和耗时概览，看不到堆栈和 SQL；
• 审计/安全：可查任意 trace 的访问记录，谁在何时查了哪笔交易都有审计。

角色权限在平台租户体系里配置，避免「为了排障把敏感数据敞开」。

合规与审计

金融行业对日志有留存和可追溯要求。方案落地时要同时满足：

• 留存：交易链路 trace 按监管要求留存（如至少 6 个月），冷热分层降成本；
• 脱敏：卡号、身份证号等敏感字段在采集端就脱敏，trace 里只留掩码后的值；
• 审计：谁在什么时间查了哪笔交易的 trace，留审计记录，支持等保检查。

落地清单

1. 确认网关、RPC、MQ 三类组件的 trace 透传；
2. 给关键业务动作补 span；
3. 配置错误/慢交易 100% 采样，正常流量按比例采样；
4. 定义慢交易阈值并接告警；
5. 敏感字段脱敏 + 审计留痕 + 留存策略。