3. Jaeger 核心架构：组件、数据流与存储后端
Jaeger 作为云原生分布式追踪系统，其架构设计遵循“端侧轻量采集、后端水平扩展、存储解耦”的原则。理解 Jaeger 的组件构成与数据流转路径，是评估部署方案对 MTTR 复盘时效影响的基础。本章将拆解 Jaeger 的四大核心组件、数据流方向以及存储后端选型。
3.1 核心组件与职责
Jaeger 架构由四个主要组件构成，每个组件承担明确的职责边界：
| 组件 | 角色 | 关键职责 | 部署位置 |
|---|---|---|---|
| Agent | 边车代理 | 接收应用发出的 UDP 数据，批量压缩后转发给 Collector | 与业务容器同 Pod / 同主机 |
| Collector | 数据收集器 | 验证、清洗、索引 Span 数据，写入存储后端 | 独立部署 / 集群 |
| Query | 查询服务 | 提供 API 接口，从存储后端检索 Trace 并返回给 UI | 独立部署 / 集群 |
| UI | 用户界面 | 可视化 Trace 拓扑、火焰图、服务依赖关系 | 与 Query 同进程或独立 |
MTTR 关联提示： Agent 的采样策略直接影响故障现场数据的完整性；Collector 的吞吐能力决定故障数据能否及时入库；Query 的缓存策略影响故障回溯时的查询响应速度。
3.2 数据流与组件协作
一条完整的 Trace 从产生到可视化，经历以下标准数据流路径：
- 应用端生成 Span：业务代码通过 Jaeger Client SDK 创建 Span，携带 TraceID、SpanID、ParentSpanID、OperationName、Tags、Logs 等字段。
- Agent 本地接收：Client 通过 UDP 协议将 Span 发送给同主机 Agent（默认端口 6831/6832）。Agent 负责批量聚合、压缩，降低网络开销。
- Collector 批量消费：Agent 通过 gRPC 或 HTTP 将 Span 批量推送给 Collector。Collector 执行数据校验、采样决策、服务名索引构建。
- 存储后端持久化：Collector 将清洗后的 Span 写入配置的存储后端（Cassandra / Elasticsearch / Badger / Kafka）。
- Query 检索与 UI 展示：用户通过 UI 发起查询请求，Query 服务从存储后端拉取 Span 数据，组装为完整 Trace 树，返回给前端渲染。
故障定位关键路径： 在 MTTR 复盘场景中，数据流中的“采样丢失”或“Collector 背压”是导致故障现场数据缺失的两大主因。建议在 Collector 层开启“自适应采样”并配置告警阈值。
3.3 存储后端选型对比
存储后端是 Jaeger 架构中影响 MTTR 复盘时效最深的组件。不同的存储后端在写入吞吐、查询延迟、数据保留策略上差异显著：
| 存储后端 | 写入性能 | 查询延迟 | 数据保留策略 | 运维复杂度 | 适用场景 |
|---|---|---|---|---|---|
| Cassandra | 高（分布式写入） | 中等（依赖分区键设计） | TTL 自动过期 | 高（需管理集群） | 大规模生产环境 |
| Elasticsearch | 中高（批量写入） | 低（全文索引优势） | ILM 索引生命周期管理 | 中（需调优分片） | 日志与追踪统一存储 |
| Badger | 高（本地嵌入式） | 低（内存优先） | 无内置 TTL（需应用层控制） | 低（单节点） | 开发测试 / 小规模 |
| Kafka + 后端 | 极高（缓冲层） | 取决于下游存储 | Kafka 保留 + 下游策略 | 高（多组件联动） | 高吞吐、异步解耦 |
MTTR 复盘陷阱： 使用 Badger 作为存储后端时，若未配置数据清理策略，磁盘写满后将导致 Collector 写入失败，造成故障现场数据永久丢失。生产环境至少应选择 Cassandra 或 Elasticsearch，并配置合理的 TTL 与索引策略。
3.4 组件部署拓扑与数据流全景
以下 SVG 图展示了一个典型的高可用 Jaeger 部署拓扑，包含 Agent 边车模式、Collector 集群、Kafka 缓冲层以及双存储后端（ES + 冷存储）的架构：
3.5 组件交互的关键协议与端口
在部署 Jaeger 时，需要明确各组件之间的通信协议与端口映射，避免网络策略导致数据流中断：
| 通信方向 | 协议 | 默认端口 | 说明 |
|---|---|---|---|
| Client → Agent | UDP (Thrift) | 6831 / 6832 | 紧凑协议与二进制协议 |
| Agent → Collector | gRPC / HTTP | 14250 (gRPC) / 14268 (HTTP) | 推荐 gRPC，支持压缩 |
| Collector → 存储 | 驱动协议 | 取决于后端 | Cassandra: 9042; ES: 9200 |
| Query → 存储 | 驱动协议 | 取决于后端 | 与 Collector 相同 |
| UI → Query | HTTP (JSON) | 16686 | 前端 API 调用 |
部署建议： 在 Kubernetes 环境中，Agent 以 DaemonSet 或 Sidecar 模式部署，确保每个节点或 Pod 都有本地 Agent。Collector 和 Query 建议使用 HPA 自动扩缩容，应对故障期间的查询流量峰值。