4、Jaeger部署模式对比：All-in-One模式、生产级微服务模式、高可用模式
Jaeger 的部署模式直接决定了分布式追踪系统的可靠性、扩展性以及故障定位时效。在生产环境中，错误的部署模式会导致数据丢失、查询超时，进而拉长 MTTR 复盘口径中的故障定位环节。本章从架构、组件、适用场景三个维度，对三种主流部署模式进行系统性对比。
4.1 三种部署模式概述
| 部署模式 | 核心特征 | 组件数量 | 数据持久化 | 典型场景 |
|---|---|---|---|---|
| All-in-One | 单进程包含所有 Jaeger 组件 | 1 个二进制文件 | 内存（默认） | 开发测试、快速体验 |
| 生产级微服务 | 组件独立部署，支持水平扩展 | 5+ 个独立服务 | Elasticsearch / Cassandra | 中小规模生产环境 |
| 高可用模式 | 微服务 + 多副本 + 负载均衡 | 7+ 个独立服务 + 网关 | 分布式存储 + 副本集 | 大规模、高 SLA 生产环境 |
4.2 All-in-One 模式（快速验证，不可用于生产）
All-in-One 模式将 agent、collector、query、ingester、UI 全部打包在同一个进程中。启动命令极为简单：
docker run -d --name jaeger \
-e COLLECTOR_ZIPKIN_HOST_PORT=:9411 \
-p 5775:5775/udp \
-p 6831:6831/udp \
-p 6832:6832/udp \
-p 5778:5778 \
-p 16686:16686 \
-p 14250:14250 \
-p 14268:14268 \
-p 14269:14269 \
-p 9411:9411 \
jaegertracing/all-in-one:1.60
⚠️ 生产环境禁止使用 All-in-One 模式。 该模式默认使用内存存储，进程重启后所有 trace 数据永久丢失。在 MTTR 复盘场景中，若依赖 All-in-One 模式，故障定位将无法回溯历史数据，导致复盘口径完全失效。
4.3 生产级微服务模式（标准生产部署）
生产级微服务模式将 Jaeger 各组件解耦为独立服务，每个组件可以独立扩缩容。典型架构包含以下组件：
- jaeger-agent：作为 DaemonSet 部署在每个节点，负责接收 span 并批量发送给 collector。
- jaeger-collector：无状态服务，接收 span 并写入后端存储。
- jaeger-query：无状态服务，提供 API 和 UI 查询能力。
- jaeger-ingester：可选组件，从 Kafka 消费 span 并写入存储，提供削峰填谷能力。
- 存储后端：Elasticsearch 或 Cassandra，提供持久化能力。
📌 MTTR 关键影响： 生产级微服务模式下，collector 和 query 可以独立水平扩展。当故障发生时，即使流量突增 10 倍，collector 也能通过快速扩容避免 span 丢失，确保故障定位所需的全量 trace 数据完整写入存储。
4.4 高可用模式（大规模生产环境）
高可用模式在生产级微服务模式的基础上，增加了以下关键能力：
- 多副本部署：collector、query 至少 3 副本，分布在不同的可用区。
- 负载均衡：agent 通过 DNS 轮询或 gRPC 负载均衡将 span 分发到多个 collector。
- Kafka 缓冲层：所有 span 先写入 Kafka，ingester 再从 Kafka 消费写入存储，实现流量削峰和故障隔离。
- 存储高可用：Elasticsearch 集群至少 3 节点，配置副本分片，确保单节点故障不丢数据。
- 查询高可用：query 服务前端部署 Nginx/HAProxy 负载均衡，提供统一的查询入口。
💡 最佳实践： 在 MTTR 复盘场景中，高可用模式能够保证在 collector 或存储节点故障期间，span 数据通过 Kafka 缓冲层完整保留。故障恢复后，ingester 自动回放 Kafka 中的积压数据，确保复盘口径的 trace 数据零丢失。
4.5 三种模式对 MTTR 复盘口径的影响对比
| 评估维度 | All-in-One | 生产级微服务 | 高可用模式 |
|---|---|---|---|
| 数据持久性 | ❌ 进程重启即丢失 | ✅ 持久化到 ES/Cassandra | ✅✅ Kafka + ES 双重保障 |
| 故障期间数据完整性 | ❌ 完全不可用 | ⚠️ 单点故障可能丢数据 | ✅ 故障隔离，零丢失 |
| 查询响应时间 (P99) | ❌ 内存查询快但不可靠 | ✅ 秒级查询 | ✅✅ 毫秒级查询 |
| 水平扩展能力 | ❌ 不支持 | ✅ collector/query 可扩展 | ✅✅ 全组件可扩展 |
| MTTR 复盘数据可用性 | ❌ 无法复盘 | ✅ 可复盘，但存在数据盲区 | ✅✅ 全量数据可复盘 |
| 运维复杂度 | ⭐ 极低 | ⭐⭐⭐ 中等 | ⭐⭐⭐⭐⭐ 较高 |
4.6 部署模式选择建议
📋 决策矩阵：
- 开发/测试环境 → All-in-One 模式，快速验证 Jaeger 功能。
- 日请求量 < 1000 万 span → 生产级微服务模式，Elasticsearch 单集群。
- 日请求量 > 1000 万 span 或 SLA > 99.9% → 高可用模式，必须引入 Kafka 缓冲层。
- MTTR 复盘口径要求 100% 数据可回溯 → 强制使用高可用模式，存储配置副本分片。
⚠️ 常见陷阱： 部分团队在生产环境使用 All-in-One 模式并挂载持久化卷，试图绕过内存限制。这种做法仍然存在单点故障风险，且无法水平扩展。一旦进程 OOM 或节点宕机，MTTR 复盘将完全失去数据支撑，故障定位时效从分钟级退化为不可用。