从 ES 崩溃到架构重塑：Zipkin 万亿级链路追踪存储优化实践

作者： /

在微服务架构已成事实标准的今天，分布式链路追踪系统（如 Zipkin、Jaeger）从“锦上添花”的辅助工具，演变为保障系统稳定性的“关键基础设施”。然而，随着业务规模的指数级增长，每日产生的 Span 数据可达百亿甚至万亿级别，其背后的存储系统，特别是默认推荐的 Elasticsearch，往往成为最先崩溃的一环。本文将从一线实战视角，深入剖析 Zipkin 存储的性能瓶颈，回归存储引擎与数据结构的基本原理，最终给出一套从“对症下药”到“架构重塑”的完整演进方案，帮助面临同样困境的技术团队找到突围之路。

现象与问题背景

设想一个典型的场景：一个大型跨境电商平台，拥有数千个微服务。在大促活动期间，系统 QPS 飙升至平日的十倍。运维团队突然收到告警，APM 系统的 Zipkin UI 响应极其缓慢，甚至完全无法打开。与此同时，负责维护 Elasticsearch 集群的 SRE 团队也焦头烂额：

  • CPU 飙升与频繁 Full GC：ES 数据节点 CPU 使用率长时间处于 90% 以上，JVM Full GC 频繁发生，导致集群间歇性“假死”。

    • –

  • 磁盘 I/O 瓶颈：写入速率远超磁盘处理能力，`iowait` 居高不下，索引合并（Merge）操作严重延迟，进一步拖慢写入。

    • –

  • 存储成本失控：链路数据占据了数百 TB 的 SSD 存储，且每日增量惊人，存储成本成为一个沉重的负担。

    • –

  • 查询超时：业务开发团队尝试通过 Zipkin UI 查询一条具体的 Trace 链路，请求耗时超过 30 秒，最终以超时告终。在分秒必争的故障排查中，这无异于灾难。

这些现象的根源，并非简单地“机器不够”，而是我们将一个为全文搜索设计的存储引擎，滥用在了海量、高维度的时序数据场景下。当数据量跨越某个临界点后，性能的断崖式下跌是必然结果。要解决这个问题，我们必须下钻到存储引擎的内核，理解其工作原理与能力边界。

关键原理拆解

（教授声音） 在深入探讨解决方案之前，我们必须回归计算机科学的基础，理解我们所处理的数据类型及其对存储系统的内在要求。链路追踪数据，本质上是一种高度结构化的时序数据（Time-Series Data），具备以下几个鲜明特征：

  • 高并发写入，追加模型：数据源源不断地从成千上万个应用实例产生，以追加（Append-only）的方式写入，极少有更新或删除操作。
  • 数据价值随时间衰减：最近几小时或几天的数据对于实时故障排查至关重要，而数月前的数据主要用于离线的趋势分析或审计，访问频率极低。
  • 固定的数据结构：每个 Span 都包含 Trace ID, Span ID, Parent ID, Service Name, Timestamp, Duration 等核心字段，以及一组键值对形式的 Tags。
  • 多维度的查询需求：排查问题时，我们不仅需要根据 Trace ID 精确查找整条链路，还需要根据服务名、API 端点、耗时、业务标签（如用户 ID、订单号）等多个维度进行组合筛选。

正是这最后一个“多维度查询”的需求，让很多人自然而然地选择了 Elasticsearch。但它的实现机制——倒排索引（Inverted Index），恰恰是其性能瓶颈的根源。

倒排索引的原理如同书籍末尾的索引。它为文档中的每个词条（Term）创建一个条目，指向包含该词条的文档列表。这使得文本搜索类的查询（“包含‘订单’和‘失败’的日志”）变得极为高效。但在链路追踪场景下，诸如 `traceId`、`spanId` 甚至一些业务 Tag（如 `orderId`）具有极高的基数（Cardinality），意味着索引中会产生海量的唯一词条。当一个新的 Span 写入时，ES 需要更新所有相关词条的文档列表，这个过程涉及大量的磁盘随机 I/O 和复杂的索引数据结构维护，在高并发下很快会成为瓶颈。

与此相对，Cassandra 这类基于 LSM-Tree（Log-Structured Merge-Tree） 的 NoSQL 数据库，则为高并发写入场景做了极致优化。LSM-Tree 的核心思想是将所有写入操作先在内存中的 Memtable 中完成，然后批量、顺序地刷写到磁盘上的 SSTable 文件中。这种顺序写的方式完全规避了昂贵的随机写，因此其写入吞吐量远超基于 B-Tree（传统关系型数据库的索引结构）和倒排索引的系统。然而，它的代价是读取操作相对复杂，且其原生查询能力通常只支持基于主键的高效查找，对于多维度任意查询则力不从心。

至此，我们看清了核心矛盾：Elasticsearch 提供了我们想要的灵活查询，但无法承载海量数据的写入和存储成本；Cassandra 提供了我们想要的写入性能和低成本，但无法满足我们多维度的查询需求。这就是问题的本质，也是我们架构优化的出发点。

系统架构总览

一个成熟的、可演进的链路追踪存储架构，不应是单一存储组件的“单点选择”，而应是一个分层、职责清晰的复合系统。其逻辑架构图可描述如下：

  • 数据采集层 (Agent/SDK): 部署在各个业务应用中，负责生成 Span 数据并上报。遵循 OpenTelemetry 或 Zipkin B3 等标准协议。

    • –

  • 数据接收与缓冲层 (Collector/Kafka): Zipkin Collector 接收来自 Agent 的数据。为了削峰填谷和解耦，通常会将数据先写入一个高吞吐的消息队列，如 Kafka。这一层是实现高级采样和数据分流的关键。

    • –

  • 数据处理/分流层 (Processing Pipeline): 一个自定义的流处理应用（如 Flink, Spark Streaming 或轻量级 Go 服务），消费 Kafka 中的原始 Span 数据。它承担三大职责：实时采样决策（如尾部采样）、数据路由（根据策略写入不同存储）、实时聚合（计算服务依赖、QPS、延迟等指标）。

    • –

  • 存储层 (Storage Layer): 这是一个混合存储层。
    • 热数据存储 (Hot Storage): 用于存放最近 1-3 天的数据，要求极高的查询灵活性和响应速度。一个经过高度优化的 Elasticsearch 集群是这里的首选。
    • 冷数据/归档存储 (Cold/Archive Storage): 用于长期保存所有原始数据，要求极高的写入性能和极低的存储成本。Cassandra、ScyllaDB 或对象存储（如 S3, GCS）是理想选择。
    • 指标存储 (Metrics Storage): 存放由处理层聚合好的指标数据，如 Prometheus 或 M3DB。

    • –

  • 查询层 (Query Service): Zipkin Query Service 依然是查询入口，但它需要被改造或扩展，使其能够智能地从不同的存储后端（ES、Cassandra）拉取数据并聚合展现给用户。

这个架构的核心思想是“数据分类，按需存储”，将单一存储的压力分解到多个为特定场景优化的专业系统中，从而在整体上实现成本、性能和功能的最优解。

核心模块设计与实现

（极客声音） 理论说完了，我们来点硬核的。下面是如何一步步实现这个架构中的关键优化点。

策略一：为 Elasticsearch “刮骨疗毒”

在放弃 ES 之前，先榨干它的潜力。对于一个专用于 Zipkin 的 ES 集群，90% 的性能问题都源于不合理的索引配置。你需要创建一个自定义的索引模板（Index Template）来覆盖 Zipkin 的默认设置。

关键优化点：

  1. 禁用高基数标签的索引： 像 `traceId`, `spanId` 这种字段，除了 Zipkin 内部通过 `_id` 查询外，几乎不会有人用它做模糊搜索。业务标签中的 `userId`, `orderId` 也是重灾区。果断地将它们的 `index` 属性设为 `false`。
  2. 精确定义字段类型： 默认情况下，ES 可能会将字符串同时索引为 `text` 和 `keyword`。对于服务名、接口名这类只需要精确匹配的字段，只保留 `keyword` 类型，可以节省大量空间和索引开销。
  3. 关闭 `_source` 或使用 `source filtering`： `_source` 字段存储了原始的 JSON 文档，方便了 Reindex 等操作，但也占用了大量空间。如果你的查询主要依赖聚合和少数几个字段，可以考虑禁用 `_source`，或通过 `includes/excludes` 只存储必要的字段。但要注意，禁用 `_source` 后 Zipkin UI 可能无法展示完整的 Span 详情。
  4. 合理的 Shard 策略： 不要创建过多的 Shard。每个 Shard 都是一个迷你的 Lucene 实例，有其自身的资源开销。根据经验，单个 Shard 的大小保持在 20GB-40GB 之间较为理想。使用基于时间的索引（如每日一个），并配合 ILM (Index Lifecycle Management) 策略自动管理索引的生命周期（hot, warm, cold, delete）。

{
  "index_patterns": ["zipkin:span-*"],
  "settings": {
    "number_of_shards": 3,
    "number_of_replicas": 1,
    "codec": "best_compression",
    "mapping.total_fields.limit": 1000
  },
  "mappings": {
    "_source": {
      "excludes": ["_q"]
    },
    "dynamic": "false",
    "properties": {
      "traceId": { "type": "keyword", "index": false },
      "id": { "type": "keyword", "index": false },
      "parentId": { "type": "keyword", "index": false },
      "name": { "type": "keyword" },
      "localEndpoint": {
        "properties": {
          "serviceName": { "type": "keyword" },
          "ipv4": { "type": "ip", "index": false }
        }
      },
      "timestamp": { "type": "long" },
      "duration": { "type": "long" },
      "tags": {
        "properties": {
          "http.method": { "type": "keyword" },
          "http.status_code": { "type": "keyword" },
          "customer.id": { "type": "keyword", "index": false }
        }
      }
    }
  }
}

上面这个模板就体现了“精确控制”的思想。通过将 `dynamic` 设为 `false`，我们阻止了 ES 自动为未定义的字段创建索引，迫使开发人员必须有意识地将被查询的字段加入到模板中。仅此一项优化，通常就能将存储空间和写入压力降低 50% 以上。

策略二：Cassandra 作为写入和归档的主力

当 ES 优化到极限后，引入 Cassandra 来分担职责。Cassandra 的表设计哲学是“Query-First”，即先想好你要怎么查，再据此设计表结构。

一个基础的设计如下：

  1. 主表 `traces`： 这是数据的权威来源，存储所有 Span 的完整信息。
    • Partition Key: `trace_id`。这保证了同一个 Trace 的所有 Span 都在同一个分区，甚至同一个节点上，使得按 Trace ID 查询整条链路的性能达到极致。
    • Clustering Key: `timestamp`, `span_id`。这使得同一个 Trace 内的 Span 们能够按照时间顺序和 ID 排序。
  2. 索引表 `traces_by_service_and_span`： 为了支持按服务名和接口名查询，我们创建一张“物化视图”或“索引表”。
    • Partition Key: `service_name`, `span_name`, `time_bucket`（例如，按小时或15分钟取整的时间戳）。
    • Clustering Key: `duration`, `start_time`, `trace_id`。这样我们可以查询某个服务接口耗时最长的 Top N 个 Trace。
    • Payload: 只存储必要的字段，如 `trace_id` 和摘要信息，避免数据冗余过大。

-- 主表，用于通过 traceId 精确查找
CREATE TABLE zipkin.spans (
    trace_id text,
    ts timestamp,
    id text,
    parent_id text,
    service_name text,
    span_name text,
    duration bigint,
    tags map<text, text>,
    PRIMARY KEY (trace_id, ts, id)
) WITH CLUSTERING ORDER BY (ts ASC);

-- 索引表，用于按服务、接口、时间范围查询
CREATE TABLE zipkin.traces_by_service_span (
    service_name text,
    span_name text,
    ts_bucket bigint, -- e.g., timestamp rounded to the hour
    duration bigint,
    start_ts timestamp,
    trace_id text,
    PRIMARY KEY ((service_name, span_name, ts_bucket), duration, start_ts, trace_id)
) WITH CLUSTERING ORDER BY (duration DESC, start_ts DESC);

注意： 这种 denormalization 的方式会带来显著的写放大（Write Amplification），一份 Span 数据可能会被写入多次。但这就是 Cassandra 的 Trade-off：用磁盘空间和写入资源换取特定的查询能力。

性能优化与高可用设计

在混合架构下，系统的瓶颈点和高可用设计的关注点也发生了变化。

  • 数据分流的可靠性： 消费 Kafka 的数据处理管道自身必须是高可用的。使用 Flink 或部署多个无状态的 Go 服务实例，并利用 Kafka Consumer Group 的 rebalance 机制来实现故障转移。必须监控消费延迟（Consumer Lag），防止数据积压。

    • –

  • 尾部采样（Tail-based Sampling）： 这是降低存储成本的大杀器。传统的头部采样（Head-based Sampling）在请求入口就决定是否采样，可能会漏掉偶发的错误请求。尾部采样则是在整条 Trace 完成后，根据其特征（如是否包含错误、耗时是否超长）再决定是否保留。这需要在数据处理层做一个微型的聚合器，收集属于同一个 Trace ID 的所有 Span，等待 Trace 结束后再做决策。这会增加实现的复杂度和处理延迟，但采样效率极高。

    • –

  • 查询服务的聚合逻辑： Zipkin Query Service 需要被扩展。当收到一个查询请求时（例如，查询过去3天的某个服务的 Trace），它应该：
    1. 首先查询“热数据”存储（Elasticsearch）。
    2. 如果查询的时间范围超出了 ES 的覆盖范围，则将请求转发给一个适配了 Cassandra 查询的服务，从 Cassandra 的索引表中拉取数据。
    3. 最后将两边的结果聚合后返回给前端。

    这需要对 Zipkin 的源码进行二次开发，或者在其前端和后端之间加一层智能代理。

    • –

  • 冷数据归档到对象存储： 对于超过一定年限（如1年）的数据，其查询需求非常低。可以运行一个批处理任务，定期将 Cassandra 中的数据导出为 Parquet 或 ORC 等列式存储格式，并存入 S3/GCS。当需要进行历史数据分析时，可以使用 Presto 或 Athena 等大数据查询引擎进行查询，成本极低。

架构演进与落地路径

没有一个架构是一蹴而就的，盲目追求“终极架构”往往会陷入过度设计的泥潭。以下是一个务实的、分阶段的演进路线图：

第一阶段：起步与规范（0-6个月）

团队规模和业务量不大。此时，直接使用 Zipkin + 单一 Elasticsearch 集群是最高效的选择。但重点是“立好规矩”：

  • 建立统一的 Trace 标准，所有团队必须在关键业务流程中正确埋点。
  • 立即应用前文提到的 Elasticsearch 索引模板优化，从一开始就避免野蛮生长。
  • 设置合理的采样率（例如 10%），并通过 Zipkin 的 ILM 功能配置好数据保留策略（例如，保留7天）。

第二阶段：优化与止血（6-18个月）

业务快速发展，ES 集群开始出现性能问题。此时的目标是“用最小的代价延长现有架构的寿命”：

  • 对 ES 集群进行垂直和水平扩展，增加更多节点，使用更好的硬件。
  • 引入动态采样率，例如，对核心交易链路保持高采样率，对边缘查询服务使用低采样率。
  • 开始调研和 PoC 尾部采样方案，作为技术储备。

第三阶段：架构分离与重塑（18个月以上）

ES 成本和运维压力达到瓶颈，优化手段的回报率越来越低。此时，进行架构重塑的时机成熟：

  • 引入 Kafka 作为数据总线，解耦 Collector 和后端存储。
  • 开发或引入数据处理管道，实现 ES（热）+ Cassandra（冷）的双写存储。
  • 改造或替换 Zipkin Query，使其支持混合查询。这是一个大工程，需要专门的团队投入。
  • 对于有更高追求的团队，可以考虑评估更专业的时序数据库或可观测性平台，如 ClickHouse、M3DB 或 VictoriaMetrics，它们在某些方面比通用解决方案更具优势。

这个演进路径的核心思想是，让架构的复杂度与业务的实际需求和团队的技术能力相匹配，在正确的时间点做正确的事，避免过早优化，也避免在技术债的泥潭中无法自拔。

延伸阅读与相关资源

  • 想系统性规划股票、期货、外汇或数字币等多资产的交易系统建设，可以参考我们的
    交易系统整体解决方案。
  • 如果你正在评估撮合引擎、风控系统、清结算、账户体系等模块的落地方式，可以浏览
    产品与服务
    中关于交易系统搭建与定制开发的介绍。
  • 需要针对现有架构做评估、重构或从零规划，可以通过
    联系我们
    和架构顾问沟通细节，获取定制化的技术方案建议。
滚动至顶部