2. Jaeger 架构基础：组件、数据模型与部署模式
Jaeger 是 CNCF 毕业的分布式追踪系统，其架构围绕“采集—存储—查询—可视化”四条主线展开。理解 Jaeger 的组件职责、核心数据模型以及主流部署模式，是后续配置环境一致性验证的前提。
2.1 Jaeger 核心组件
Jaeger 由四个主要组件构成，它们协同完成从数据采集到展示的完整链路。下表列出各组件的定位与关键职责：
| 组件 | 角色 | 核心职责 | 通信协议 |
|---|---|---|---|
| Agent | 边车代理 | 接收应用发出的 Span，批量压缩后转发给 Collector；降低应用端网络开销 | gRPC / Thrift |
| Collector | 数据管道 | 验证、清洗、索引 Span，写入后端存储；支持采样策略下发 | gRPC / HTTP |
| Query | 查询服务 | 提供 Trace 检索 API，聚合 Span 数据，返回完整调用链 | gRPC / HTTP |
| UI | 可视化层 | 基于 Query API 构建 Web 界面，展示 Trace 拓扑、火焰图、时间线 | HTTP (Browser) |
关键认知： Agent 并非强制组件。在 Kubernetes 环境中，多数团队直接让应用通过 gRPC 向 Collector 上报 Span，以简化运维。Agent 主要保留在传统虚拟机或需要本地缓冲的场景。
2.2 数据模型：Span 与 Trace
Jaeger 的数据模型基于 OpenTracing 标准，核心抽象为 Span 和 Trace。
- Span：一次操作的最小记录单元，包含操作名称、开始/结束时间、标签（Tags）、日志（Logs）以及 SpanContext（TraceID、SpanID、Baggage）。
- Trace：由一组具有相同 TraceID 的 Span 构成的有向无环图（DAG），完整描述一次请求在分布式系统中的执行路径。
Span 之间的因果关系通过 SpanRef 表达，常见类型包括 ChildOf（父子）和 FollowsFrom（异步跟随）。
// Span 核心结构（简化）
{
"traceID": "abc123",
"spanID": "def456",
"operationName": "HTTP GET /api/order",
"startTime": 1710000000000000,
"duration": 150000, // 微秒
"tags": [
{"key": "http.status_code", "value": 200},
{"key": "peer.service", "value": "order-service"}
],
"logs": [
{"timestamp": 1710000000050000, "fields": [{"key": "event", "value": "cache miss"}]}
],
"references": [
{"refType": "CHILD_OF", "traceID": "abc123", "spanID": "ghi789"}
]
}
配置一致性验证要点： 在质量门禁场景中，需重点校验 Span 的
tags 和 process.tags 是否包含预期的环境标识（如 deployment.env=staging、config.version=1.2.3）。缺失或错误的标签将导致验证失败。
2.3 部署模式对比
Jaeger 支持三种主流部署模式，不同模式对基础设施和运维能力的要求差异显著。下表从组件拆分、扩展性、适用场景三个维度进行对比：
| 部署模式 | 组件拆分 | 扩展性 | 典型场景 |
|---|---|---|---|
| All-in-One | Agent + Collector + Query + UI 合并为单进程 | 低，单点瓶颈 | 本地开发、功能验证、小规模演示 |
| 生产轻量 | Collector + Query + UI 独立部署，Agent 可选 | 中，Collector 可水平扩展 | 中小团队、中等流量、快速上线 |
| 生产高可用 | Collector 集群 + Query 集群 + 独立存储 + 可选 Agent | 高，各组件独立扩缩容 | 大规模微服务、SRE 体系、多环境一致性验证 |
下图展示了生产高可用模式下各组件的协作关系与数据流向：
2.4 组件通信与数据流
理解数据在组件间的流转路径，有助于定位配置不一致的环节。标准数据流包含以下步骤：
- 应用埋点：应用通过 Jaeger Client SDK 创建 Span，携带 TraceID、SpanID、Tags。
- 本地上报：SDK 将 Span 通过 UDP 或 gRPC 发送给本地 Agent（若部署），或直接发送给 Collector。
- 批量转发：Agent 将多个 Span 压缩、合并后通过 gRPC 转发给 Collector。
- 校验与存储：Collector 校验 Span 合法性，执行采样决策，写入后端存储。
- 查询与展示：Query 服务从存储中检索 Span，按 TraceID 聚合后通过 API 返回给 UI。
质量门禁切入点： 在步骤 2 和步骤 4 之间，可以插入配置一致性校验中间件，拦截 Span 并验证其 Tags 是否包含预期的环境标识、配置版本号等字段。若校验失败，可触发告警或拒绝写入。
2.5 部署模式选择建议
根据团队规模和运维成熟度，推荐以下选型路径：
- 开发/测试环境：All-in-One 模式，快速启动，无需外部存储依赖。
- 预发/小规模生产：生产轻量模式，Collector 独立部署，存储使用单节点 Elasticsearch。
- 大规模生产/SRE 体系：生产高可用模式，Collector 和 Query 均集群化，存储使用 Cassandra 或 Elasticsearch 集群，并启用 Agent 以降低应用端网络开销。