29、分布式追踪的替代方案解析

分布式追踪的替代方案解析

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

分布式追踪为某些问题提供了一种可能的解决方案。以 API A 的追踪为例，它能记录数据库调用次数和每次调用的延迟等必要信息。顶层跨度表明请求通过 API A 进入，子跨度中包含数据库调用的详细信息，同时追踪中还会包含沿途调用的每个服务的详细信息。通过简单的后处理，可以提取聚合统计信息来回答一些问题。

然而，使用分布式追踪存在一个重大缺点。由于每个被调用的服务都会为追踪添加额外的细节，这意味着会产生额外的开销，因此不可避免地需要对分布式追踪进行采样，而不是追踪每个请求。由于巨大的计算开销，无法对 100% 的请求进行追踪。在处理指标时，通常会关注异常值，例如应用程序在罕见但重要的边缘情况下的表现。但通过采样追踪，可能会错过许多对诊断问题最重要的请求，从而给人一种根本不存在高延迟异常值的错觉。

2. Census 方案

2.1 标签传播与本地指标聚合

Census 针对这一特定用例，能够捕获 100% 请求的指标。它不记录单个追踪，因此无需使用采样来处理计算成本。Census 的关键在于上下文传播，它会随请求传播上下文，但这些上下文不包含追踪 ID，而是包含描述用户选择的请求属性的标签。在请求过程中的任何时候，任何服务都可以向 Census 上下文写入标签，例如 API A 和 API B 可以分别写入 “API A” 或 “API B” 的标签，这些标签会随请求在 Census 上下文中转发给被调用的子服务。

除了标签，沿途的任何服务都可以记录指标。例如，后端数据库可能会发出 API 调用的简单计数以及每次调用的延迟。每当组件发出指标时，Census 会检查 C