分布式追踪后端对比：Jaeger、Zipkin与Tempo

可视化演示

展示Jaeger Agent Collector Query Storage组件链路、索引型与非索引型存储架构对查询的影响、以及Jaeger Zipkin Tempo三大后端在存储与查询能力的对比。

三大后端初识

在天工市的物流行业，有三家风格迥异的快递分拣中心。第一家是“城市邮局”Zipkin，2012 年由 Twitter 开源，用 Java 写成，是追踪界的元老——像一位资深的邮政局长，规矩多、流程稳，很多老牌企业（如阿里的鹰眼早期）都受过它的启发。第二家是“极速快运”Jaeger，由 Uber 在 2017 年捐给 CNCF，用 Go 语言打造，主打高性能和云原生，像一支装备精良的机动分队。第三家是“云仓一体”Tempo，由 Grafana Labs 在 2021 年推出，背靠 Grafana 全家桶，像一座直接连通云厂商大仓库的智能物流中心。

这三家的共同目标完全一致：接收来自各微服务的 Span（追踪片段），按照 Trace ID 把它们拼成完整的调用链，并提供查询界面。但它们面对同一个问题时——“如何在海量运单中快速找到想要的那张？”——给出了截然不同的答案。

要理解答案的差异，先得明白一个核心概念：Span 是链路追踪的最小单元，记录了一次跨服务调用的名称、耗时、父级关系等元数据；Trace 则是若干 Span 按树形结构组成的完整请求轨迹。如果把一次用户请求比作一趟“接力赛”，Trace 就是整场比赛的录像，Span 则是每个运动员单独佩戴的 GPS 记录仪。

理解了 Span 的数据结构，就好比看懂了快递面单上的每一个格子。接下来，我们走进三家分拣中心的“仓库重地”，看看它们各自的存放哲学。

存储架构对比

老周跟着 Zipkin 的邮政局长走进仓库，看到一排排整齐的货架——这是 Elasticsearch 集群。每一个 Span 被当作一份 JSON 文档存入 ES，靠倒排索引撑起查询。这种方式像在传统仓库里给每件包裹建立“索引卡片”，查询灵活，但索引的建立和维护要吃掉大量磁盘和内存。“老牌邮局”的这套玩法虽然成熟，运维 ES 集群却像伺候一位挑剔的老爷。

Jaeger 的仓库则提供了两种货架可选：支持 Cassandra 和 Elasticsearch。Cassandra 是列式存储，擅长海量写入，适合超大规模场景；ES 则与 Zipkin 类似，便于多维检索。Jaeger 让客户按需选择，就像快运公司让你选“走陆运还是空运”。但请注意，Cassandra 运维门槛高，ES 又在高基数标签下容易臃肿——两种选择各有隐形成本。

Tempo 的“仓库”最另类——它几乎没有自己的索引，直接把 Span 数据压缩后丢进对象存储（S3、GCS 或阿里云 OSS）。这就像一家不建货架的仓库，把所有包裹按“运单号”直接堆进成本极低的云仓。它不做复杂的索引，想要检索 Trace 时，用 Trace ID 算出对象存储的路径，直接取出对应文件。

存储架构的分野，直接决定了查询时的体验。接下来我们看看，三家分拣中心的“查件柜台”分别怎么工作。

查询机制对比

在 Zipkin 的查件柜台，工作人员会先问你：“寄件服务叫什么？收件操作叫什么？”然后对着 ES 的索引卡片逐一翻找。它的查询模型是“服务名 + 操作名 + 时间范围”的组合检索，能够找到符合条件的所有 Trace。但问题在于，当数据量大时，这种“翻卡片”的方式响应变慢；而且 Zipkin 早期不支持标签（Tags）深度过滤，定位一个“失败支付”具体发生在哪一跳，往往要人工逐个排查。

Jaeger 的查询柜台明显更先进。它允许你用标签直接筛选，比如 error=true 或者 http.status_code=500，然后基于这些 KV 组合快速定位目标链路。这相当于在快递面单上做了“多层索引卡”，既支持服务维度检索，也支持标签维度过滤。代价就是每写入一个 Span，都要同步更新这些标签索引，产生“写放大”。

Tempo 的取件方式干脆利落——柜台只问一个问题：“运单号（Trace ID）是多少？”你只要给出 Trace ID，它直接去对象存储里精确取件，速度快得惊人。它不擅长做“条件模糊搜索”，但 Grafana 生态的 Tempo 通常搭配 Loki（日志）和 Prometheus（指标）一起工作：先用日志或指标锁定一个有问题的 Trace ID，再交给 Tempo 精确拉取完整链路。

查件方式的差异决定了各自的适用场景。那么这三家分拣中心在“日常运营”中，谁更省人省力？我们看看部署与性能这盘棋。

部署与性能

如果用一个词总结 Zipkin 的部署体验，那就是“重”。它需要你自建 ES 集群，生产环境至少 3 节点起步；用 Java 写的服务端内存占用高，启动慢，但社区资料多，出了问题网上到处有解药。对于没有专职 ES 运维的中小团队，这像养了一只食量巨大的看门犬。

Jaeger 的部署轻盈不少。官方提供 All-in-One 模式用于测试，生产环境可拆分为 collector、query、agent 三组件，每个都是无状态的 Go 二进制，内存占用远低于 Java 系。配合 Kubernetes Operator，一个 YAML 就能拉起整套系统。不过它的性能同样受存储后端制约——写入 Cassandra 时吞吐高，写入 ES 时则受索引瓶颈限制。

Tempo 的部署最“云里云气”。后端存储直接用云厂商的对象存储，无需维护任何索引集群。它的查询组件是可选的无状态微服务，按需伸缩。这种架构下，Tempo 几乎可以把运维成本降到最低，但代价是查询体验需要依赖 Grafana 生态的配合才能完整体现。

现在你心里大概有数了：没有绝对的优劣，只有匹配度的问题。那到底该选哪家？我们进入选型决策指南。

选型决策指南

老周把三家分拣中心的情况列成了一张表，开始按自己的条件做排除法。第一步看技术栈亲和性：如果团队已经是 Java 主导、ES 运维成熟，选 Zipkin 顺理成章；如果公司全面云原生化、Go 微服务为主，Jaeger 如鱼得水；如果已经重度拥抱 Grafana（Loki + Prometheus + Grafana），那 Tempo 是必然之选，因为它与 Grafana 的 UI 无缝集成。

第二步看规模与预算。小规模（日均 Trace 百万级以下）用 Zipkin 的 ES 方案最稳妥，开发资源好找；中大规模（日均千万级）且预算有限，Tempo 的对象存储路线能省下惊人的存储成本；追求极致查询性能与标签过滤能力、预算充足，Jaeger + Cassandra 是硬核选择。

第三步看团队运维能力。Zippkin 需要你懂 ES、Jaeger 需要你懂 Cassandra（如果选它）或 ES、Tempo 几乎不需要你懂存储运维，但要求你理解对象存储与 Grafana 生态。最后还要考虑可观测性整合度：Tempo 与 Prometheus 的“指标→链路”跳转体验业内有口皆碑，Zipkin 则相对封闭。

选型定下来只是开始。真正让老周睡不着觉的，是如何把正在运行的链路数据从旧系统搬到新系统，不能断、不能丢、不能影响业务。这就要说到迁移与落地了。

迁移与落地

老周的团队原本用的是 Zipkin，现在决定转向 Tempo 已降低存储成本。迁移第一步是协议兼容——庆幸的是，Zipkin 的客户端（如 Brave、Zipkin 官方库）可以通过 Zipkin 兼容 API 直接把 Span 数据发给 Jaeger 或 Tempo。Tempo 内置了 Zipkin API 的接收端点，这意味着老周根本不用改业务代码，只需要把数据上报的地址从 Zipkin 服务器指向 Tempo，老系统就能“无缝换轨”。

第二步是接入 OpenTelemetry（OTel）做统一收口。OTel 是一个与厂商无关的遥测标准，它的 SDK 支持导出到 Jaeger、Zipkin、Tempo 等所有主流后端。老周的做法是：在应用层统一埋点 OTel，由 OTel Collector 作为“总转运站”，按需把数据同时发给新旧两个后端做“双写”。双写期间对比两边数据完整性，验证新系统没问题后再逐步减少向旧系统的流量，直到完全切换。

最后一步是风险管控。老周在设计方案时特意加了一条“开关”：通过 OTel Collector 的动态配置，可以随时把新后端从数据流中摘除，避免新系统故障拖垮业务。同时，老周在 Tempo 上配置了采样策略——全量生产流量的 10% 双写，验证通过后再放大到 100%。这个过程，就像给高铁换轨，先把列车引到临时便道，确认无误后再拆除旧轨。

至此，老周对三家分拣中心从仓库到柜台再到换轨策略都有了全面认识。其实选型没有银弹，重要的是你把团队的技术栈、成本预算、运维能力和生态现状放在桌面上，对照三家特点做理性的匹配。

AI 应用场景

Python 演示

"""简化模拟：三大追踪后端的 Span 存储与查询对比"""import hashlibimport timefrom dataclasses import dataclass, fieldfrom typing import Dict, List, Optional  @dataclassclass Span:    trace_id: str    span_id: str    parent_span_id: Optional[str]    service_name: str    operation_name: str    duration_ms: float    tags: Dict[str, str] = field(default_factory=dict)  class ZipkinBackend:    """老牌邮局：全量索引，查询靠服务名+操作名"""    name = "Zipkin"     def __init__(self):        self.spans: List[Span] = []  # 模拟 ES 文档库        self.index: Dict[tuple, list] = {}  # (service, operation) -> span 列表     def write(self, span: Span):        self.spans.append(span)        key = (span.service_name, span.operation_name)        self.index.setdefault(key, []).append(span)     def query(self, service_name: str, operation_name: str) -> List[Span]:        key = (service_name, operation_name)        return self.index.get(key, [])  class JaegerBackend:    """极速快运：在 Zipkin 基础上增加标签索引"""    name = "Jaeger"     def __init__(self):        self.spans: List[Span] = []        self.tag_index: Dict[str, Dict[str, list]] = {}  # tag_key -> tag_value -> spans     def write(self, span: Span):        self.spans.append(span)        for k, v in span.tags.items():            self.tag_index.setdefault(k, {}).setdefault(v, []).append(span)     def query(self, tag_key: str, tag_value: str) -> List[Span]:        return self.tag_index.get(tag_key, {}).get(tag_value, [])  class TempoBackend:    """云仓一体：零索引，TraceID 哈希直达对象存储"""    name = "Tempo"     def __init__(self):        self.store: Dict[str, List[Span]] = {}  # object_key -> trace spans     def write(self, span: Span):        # TraceID 哈希计算对象存储路径        key = hashlib.md5(span.trace_id.encode()).hexdigest()[:16]        self.store.setdefault(key, []).append(span)     def query(self, trace_id: str) -> List[Span]:        key = hashlib.md5(trace_id.encode()).hexdigest()[:16]        return self.store.get(key, [])  def build_demo_trace() -> List[Span]:    """构造一条模拟链路：网关 -> 商品服务 -> 支付服务"""    return [        Span("abc123", "s1", None, "api-gateway", "POST /checkout", 105.0, {"http.status_code": "200"}),        Span("abc123", "s2", "s1", "product-svc", "getStock", 45.0, {"http.status_code": "200"}),        Span("abc123", "s3", "s1", "payment-svc", "charge", 58.0, {"error": "true", "http.status_code": "500"}),    ]  if __name__ == "__main__":    trace = build_demo_trace()    backends = [ZipkinBackend(), JaegerBackend(), TempoBackend()]    for backend in backends:        for span in trace:            backend.write(span)        print(f"--- {backend.name} ---")         if isinstance(backend, ZipkinBackend):            result = backend.query("payment-svc", "charge")            print(f"按服务+操作查询: {len(result)} 个 Span, 含错误标签: {result[0].tags}")        elif isinstance(backend, JaegerBackend):            result = backend.query("error", "true")            print(f"按错误标签查询: {len(result)} 个 Span, duration_ms={result[0].duration_ms}")        elif isinstance(backend, TempoBackend):            result = backend.query("abc123")            print(f"按 TraceID 精确取件: {len(result)} 个 Span, 耗时最长 {max(s.duration_ms for s in result)}ms")

1. key = (span.service_name, span.operation_name)Zipkin 建立“服务名+操作名”的联合索引卡片，查询必须提供这两个字段
2. self.tag_index.setdefault(k, {}).setdefault(v, []).append(span)Jaeger 为每个标签键值对建立倒排索引，实现多维过滤
3. hashlib.md5(span.trace_id.encode()).hexdigest()[:16]Tempo 用 Trace ID 的哈希值作为对象存储路径，实现 O(1) 直达取件
4. if isinstance(backend, ZipkinBackend)不同后端的查询方式差异通过类型判断演示，体现选型对查询模式的决定性影响

常见误区

面试题