4. Jaeger 架构解析：组件、数据模型与存储后端
在混沌工程基线核验中，Jaeger 作为分布式链路追踪的核心工具，其架构设计直接决定了故障数据的采集效率、处理能力与查询性能。本章将深入解析 Jaeger 的四大核心组件、链路追踪的数据模型以及存储后端选型策略，帮助你在故障注入场景中精准定位链路断裂点。
4.1 Jaeger 核心组件架构
Jaeger 采用微服务架构设计，由 Agent、Collector、Query 和 UI 四个主要组件构成。每个组件承担独立的职责，通过 gRPC 或 HTTP 协议进行通信，形成从数据采集到可视化展示的完整链路。
4.1.1 Jaeger Agent
Agent 是一个网络守护进程，通常以边车（Sidecar）模式部署在每个主机或 Pod 中。它负责接收应用服务通过 UDP 发送的 Span 数据，进行批量处理后转发给 Collector。
- 数据接收： 默认监听端口 6831 (Thrift Compact) 和 6832 (Thrift Binary)，支持 Zipkin 兼容格式。
- 采样策略： 支持概率采样、速率限制采样和远程采样，在混沌工程中建议使用固定采样以确保故障链路不丢失。
- 故障场景： Agent 宕机或网络中断会导致 Span 数据丢失，建议配置
JAEGER_REPORTER_LOG_SPANS=true启用日志回退。
4.1.2 Jaeger Collector
Collector 是链路数据的核心处理单元，负责验证、索引和持久化 Span 数据。在混沌工程基线核验中，Collector 的吞吐能力直接决定能否承受故障注入带来的流量洪峰。
| 特性 | 说明 | 混沌工程建议 |
|---|---|---|
| 数据验证 | 检查 Span 的 TraceID、SpanID、时间戳完整性 | 开启 --collector.span-size-limit 防止恶意大 Span |
| 批量处理 | 将多个 Span 打包写入存储后端 | 调整 --collector.queue-size 应对突发流量 |
| 采样决策 | 支持头部采样和尾部采样 | 故障注入期间建议关闭采样或使用 100% 采样 |
4.1.3 Jaeger Query 与 UI
Query 服务提供 gRPC 和 HTTP API 用于检索 Trace 数据，UI 则提供基于 React 的 Web 界面。在故障排查中，Query 的响应速度直接影响 MTTR（平均修复时间）。
- 查询能力： 支持按 TraceID、服务名、操作名、标签、时间范围检索。
- 依赖图： 自动生成服务依赖关系图，帮助识别故障传播路径。
- 性能优化： 启用
--query.max-clock-skew-adjustment处理时钟偏差，避免故障链路显示异常。
4.2 数据模型：Span 与 Trace
Jaeger 的数据模型基于 OpenTracing 标准，核心概念为 Span（跨度）和 Trace（追踪）。理解这两个模型是进行链路故障分析的基础。
4.2.1 Span（跨度）
Span 是链路追踪的最小工作单元，代表一个分布式系统中的单个操作。每个 Span 包含以下核心信息：
- 标识信息： TraceID（全局追踪 ID）、SpanID（当前 Span ID）、ParentSpanID（父 Span ID，根 Span 为空）。
- 时间信息： StartTime（开始时间戳）、Duration（耗时，微秒级）。
- 元数据： OperationName（操作名称）、Tags（键值对标签，如
http.status_code=500）、Logs（事件日志）。
error=true 的 Span。使用 span.tags["http.status_code"] 快速定位 HTTP 500 错误。
4.2.2 Trace（追踪）
Trace 是由一组具有相同 TraceID 的 Span 构成的树状结构，完整记录一次请求从入口到所有下游服务的执行路径。Trace 的根 Span 代表请求的入口点，子 Span 代表各服务的处理过程。
| 属性 | 描述 | 混沌工程应用 |
|---|---|---|
| TraceID | 128 位或 64 位全局唯一标识 | 故障注入时记录 TraceID 用于事后关联分析 |
| Span 树 | 通过 ParentSpanID 构建父子关系 | 断链分析：缺失子 Span 表示下游服务故障 |
| 服务依赖 | 从 Trace 中提取服务调用关系 | 生成依赖图，识别故障传播路径 |
4.3 存储后端选型与对比
Jaeger 支持多种存储后端，不同存储方案在性能、扩展性和运维复杂度上差异显著。在混沌工程基线核验中，存储后端的写入延迟和查询性能直接影响故障数据的完整性。
| 存储后端 | 类型 | 写入性能 | 查询性能 | 运维复杂度 | 推荐场景 |
|---|---|---|---|---|---|
| Cassandra | NoSQL 列族 | 高（分布式写入） | 中（依赖二级索引） | 高（需集群运维） | 大规模生产环境 |
| Elasticsearch | 全文搜索 | 中（批量写入优化） | 高（全文检索、聚合分析） | 中（需管理索引生命周期） | 日志与追踪联动场景 |
| Badger | 嵌入式 KV | 高（本地写入） | 高（内存索引） | 低（单机部署） | 开发测试、小规模部署 |
| 内存 (Memory) | 临时存储 | 极高 | 极高 | 无 | 快速验证、演示环境 |
4.3.1 存储后端配置示例
以下为使用 Elasticsearch 作为存储后端的 Collector 启动配置：
# Jaeger Collector 启动命令（Elasticsearch 后端）
./jaeger-collector \
--cassandra.keyspace=jaeger_v1_dc1 \
--cassandra.servers=127.0.0.1 \
--collector.zipkin.host-port=9411 \
--collector.grpc-server.host-port=14250 \
--collector.http-server.host-port=14268 \
--es.server-urls=http://elasticsearch:9200 \
--es.num-shards=5 \
--es.num-replicas=1 \
--es.create-index-templates=true