29、分布式追踪的替代方案：Census、Pivot Tracing与Pythia

分布式追踪的替代方案：Census、Pivot Tracing与Pythia

1. 分布式追踪的困境与解决方案

分布式追踪为解决系统问题提供了一种可能的方案。以API A的追踪为例，追踪信息包含了所有必要的内容，顶层跨度表明请求通过API A，子跨度中包含数据库调用的相关信息，同时追踪还涵盖了沿途调用的每个服务的详细信息。通过简单的后处理，可以提取聚合统计信息来回答一些问题。

然而，使用分布式追踪存在一个重大缺点：由于每个被调用的服务都会为追踪添加额外的细节，导致计算开销巨大，因此不可避免地需要对分布式追踪进行采样，而无法对100%的请求进行追踪。在处理指标时，通常关注的是异常值，如处于99%分位数及以上的高延迟请求。但通过采样追踪，可能会错过许多对诊断问题至关重要的请求，从而产生没有高延迟异常值的错误印象。

2. Census：标签传播与本地指标聚合

2.1 Census的工作原理

Census针对上述问题，能够捕获100%请求的指标。它不记录单个追踪信息，因此无需通过采样来处理计算成本。Census的关键在于上下文传播，它会随请求传播上下文，但上下文中不包含追踪ID，而是包含描述用户选择的请求属性的标签。在请求过程中的任何时刻，任何服务都可以向Census上下文写入标签，这些标签会随请求转发到被调用的子服务。

同时，沿途的任何服务都可以记录指标。例如，后端数据库可能会发出API调用的简单计数以及每次调用的延迟。每当组件发出指标时，Census会检查Census上下文中请求的标签，并按标签递增计数器。计数器在本地维护（如在数据库中），仅将聚合指标定期报告给Census后端。

2.2 Cen