引言：时间异常是分布式系统协调问题的信号
在分布式系统中，时间既是协调工具，也是混乱的源头。服务依赖时间戳来排序操作、检测延迟、推断状态。当这些假设被打破——比如一个请求看似成功，但其效果未在预期时间窗口内出现——我们就很可能遇到了时间异常。时间异常表现为延迟、乱序、重复重试或跨服务时间戳不匹配，它们很少直接抛出异常，却常常是更严重的协调问题的前兆。
本文将用一个真实的排查案例，展示如何通过组合工具追溯一笔“消失”的1欧元支付，并提炼出可复用的排查方法论。
案例背景：巴黎厕所1欧元支付丢失
故事起源于一位支付工程师接到的看似最琐碎的工单：“调查丢失交易，丢失1欧元。”交易发生在巴黎某公共厕所的POS终端，金额虽小，但工程师们并未轻视——如果系统能静默丢失1欧元，也同样能轻易丢失10000欧元。
POS终端向客户显示了“支付成功”消息，也的确向支付处理器发送了授权请求。但后端支付服务中却找不到这笔交易的任何记录。交易似乎离开POS后就消失了。
下文将描述一个简化的支付系统架构，以聚焦排查过程而非系统设计：POS -> API网关 -> 支付处理服务 -> 数据库/消息队列。
排查步骤一：检查POS日志与分布式追踪
第一步：确认POS日志
工程师先检查了POS终端日志：终端确实发送了授权请求，日志中记录了请求时间与状态。POS没问题。
第二步：分布式追踪
利用基于OpenTelemetry和Jaeger的分布式追踪（类似于第12章介绍的方案），工程师搜索与POS设备请求关联的trace ID。在健康交易中，应能看全链trace：
POS -> API网关 -> 支付处理服务 -> 数据库写入
但此处trace在支付处理服务处戛然而止，没有下游span记录：
Trac
