假设你正在维护一个电商系统的微服务架构：Checkout Service通过REST调用Order Service，Order Service将订单事件发布到Kafka，Fulfillment Service从Kafka消费并落库。某天你发现有些用户完成了支付，但订单始终没有出现在后台——日志看似正常，但订单就是“丢失”了。这类跨服务故障的排查，传统的单机日志已经力不从心。这时就需要引入分布式追踪的两个核心概念：Trace ID和Span。什么是Trace ID与SpanTrace ID是分布式请求的唯一标识。当一个请求进入系统（如HTTP请求），系统会生成一个全局唯一的Trace ID，并随着请求穿越各个服务（通过HTTP头、消息元数据等）。这就像一本护照，在每个服务节点留下记录。Span是Trace中的最小工作单元，代表单个服务内的一个操作（如：处理HTTP请求、查询数据库、调用下游服务）。Span包含名称、开始时间、持续时间、服务名称、标签（状态码、错误信息等）以及父Span的引用。多个Span以嵌套关系形成一棵Trace Tree，完整反映请求的生命周期。示例Trace Tree（来自一个真实的分布式系统）：Trace ID: 6f98c1e2b3a24f59 └── [api-gateway] POST /checkout [950ms] ├── [checkout-service] Validate cart [40ms] ├── [checkout-service] Call OrderService [780ms] │ └── [order-service] Create order record [100ms] │ ├── [order-service] Check inventory [60ms] │ └── [order-service] Save to database [30ms]