Tracezip：不丢 Trace，如何降低分布式追踪成本？在微服务系统中，一次用户请求可能依次经过网关、鉴权、订单、库存、支付和数据库等多个组件。分布式追踪通过 Trace 和 Span 还原完整调用链，是定位延迟、异常传播和跨服务故障的重要手段。但追踪越完整，成本越高。大量 Span 会增加服务端序列化、网络传输、后端接收以及长期存储的压力。面对这一矛盾，生产系统通常选择采样：只保留部分 Trace，以可观测性的损失换取成本下降。论文Tracezip: Efficient Distributed Tracing via Trace Compression提出了另一条路线：先利用 Span 之间的重复信息进行在线无损压缩，再把压缩结果传输到追踪后端。它试图做到的不是“更聪明地丢数据”，而是“用更少的数据表达完整 Trace”。采样为什么不够？常见追踪采样主要有两类。头部采样在请求刚进入系统时作出决定，实现简单、开销较低，但此时尚不知道请求最终是否超时或失败，可能直接漏掉关键异常。尾部采样会先采集完整调用链，再依据延迟、状态码等信息决定是否保留。它更容易捕获异常，却无法消除 Span 生成、序列化、传输和后端接收阶段的开销。Tracezip并不替代采样，而是解决采样之前的数据成本。因此，它可以与头部采样或尾部采样组合使用。Trace 数据为什么适合压缩？一个 Span 通常包含操作名称、Trace ID、Span ID、时间戳、服务地址、协议、状态和业务属性等字段。其中，ID和时间戳通常持续变化，但许多环境与操作字段会反复出现，例如：service.name = order-service db.system = mysql server.address = db01 status = success论文对多个微服务和基础组件的 Trace 进行了统计，发现不少场景中约70%的键值对具有较高重复性。通用压缩算法也能利用局部重复，但其观察窗口有限，而且通常要在 Span 完成序列化后才能处理。Tracezip选择在数据结构层直接识别跨 Span 的全局重复模式。核心设计：Span Retrieval TreeTracezip引入了 Span Retrieval Tree，简称SRT。它是一种类似前缀树的结构，用一条树路径表示多个 Span 共同拥有的一组键值对。完整 Span = 公共字段 + 局部字段 压缩 Span = SRT路径编号 + 局部字段值公共字段在论文中称为 universal fields，例如服务名称、数据库类型和固定状态；Span ID、时间戳等高变化字段则属于 local fields。公共字段进入SRT，局部字段只保留字段名，每条压缩记录发送其实际值。