27、分布式追踪：Span为何不足及新抽象探索

分布式追踪：Span为何不足及新抽象探索

1. 树状Span追踪的局限

在分布式系统中，对于获取用户动态、个性化推荐和广告等请求，树状Span追踪方法看似是个完美的解决方案，但实际上存在诸多不足。

1.1 图结构而非树结构

当端到端追踪呈现为图结构而非树结构时，问题便会出现。控制流中既包含分叉（一个父Span有多个子Span），也包含合并（一个子Span有多个父Span）。然而，目前的Span要求每个Span最多只能有一个父Span，没有父Span的则为追踪的根。

常见的情况是，多个远程过程调用（RPC）被批量处理为一个后续的RPC。例如，在社交媒体平台的后端，一个时间线请求可能会并行获取多个时间线项目。若其中一些项目需要从同一服务器获取数据，系统可能会将这些请求批量处理为一个RPC。

以下是RPC批量处理导致Span有多个父Span的问题示例：

graph LR
    classDef process fill:#E5F6FF,stroke:#73A6FF,stroke-width:2px;
    X -->|请求| A
    Y -->|请求| A
    Z -->|请求| A
    A -->|批量请求| B

在这种情况下，代表从服务A到服务B调用的Span的父Span难以确定。实际中，这个输出的RPC依赖于所有输入的RPC，但当前的追踪系统无法直接表示这种关系。一种解决方法是选择添加到批量中的第一个或最后一个请求作为父请求，但这会导致妥协树不能正确表示真实的依赖关系。