📚 课程目录第4章 Jaeger部署模式

4. Jaeger 部署模式：All-in-one、生产级 Kubernetes 部署、存储后端选型

Jaeger 的部署模式直接决定了其可用性、扩展性与资源消耗。本章将系统讲解三种主流部署模式：面向开发测试的 All-in-one、面向生产环境的 Kubernetes 原生部署，以及两种核心存储后端 Elasticsearch 与 Cassandra 的选型对比。

4.1 部署模式总览

下表从适用场景、组件完整性、持久化能力与资源开销四个维度，对三种模式进行横向对比：

部署模式	适用场景	组件完整性	持久化存储	资源开销
All-in-one	本地开发、功能验证、Demo	Agent + Collector + Query + UI 单进程	内存（默认）或 Badger（本地文件）	低（单节点 1-2 GB 内存）
Kubernetes 生产部署	生产环境、微服务集群、高可用	Agent（DaemonSet）+ Collector（Deployment）+ Query（Deployment）+ 存储后端	外部存储（ES / Cassandra）	中高（按流量水平扩展）
Docker Compose 简易集群	小团队、预生产环境	组件分离但单实例	外部存储（ES / Cassandra）	中（多容器共享主机）

建议： 生产环境务必使用 Kubernetes 部署模式，并搭配外部持久化存储。All-in-one 模式仅用于快速上手，重启后数据丢失，不适合任何需要追溯历史链路的场景。

4.2 All-in-one 模式详解

All-in-one 将 Jaeger 的所有核心组件（Agent、Collector、Query、UI）打包在同一个二进制文件中，使用内存或本地 Badger 作为存储后端。启动命令极为简洁：

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

启动后，访问 http://localhost:16686 即可打开 Jaeger UI。该模式适合以下场景：

本地开发环境快速验证链路采集是否正常
集成测试中临时启用链路追踪
教学演示与概念验证（PoC）

注意： All-in-one 默认使用内存存储，重启后所有 trace 数据丢失。如需保留数据，可挂载本地卷并启用 Badger 存储（--badger.directory-key=/data --badger.directory-value=/data），但仍不具备高可用能力。

4.3 生产级 Kubernetes 部署

生产环境推荐使用 Jaeger Operator 或 Helm Chart 在 Kubernetes 上部署。Operator 模式通过 CRD（Custom Resource Definition）管理 Jaeger 实例的生命周期，支持自动扩缩容、滚动升级与健康检查。

4.3.1 架构组件与部署拓扑

下图展示了生产级 Kubernetes 部署的核心组件及其交互关系：

4.3.2 使用 Helm Chart 快速部署

以下命令使用 Jaeger Helm Chart 在 Kubernetes 集群中部署生产级实例：

# 添加 Jaeger Helm 仓库
helm repo add jaegertracing https://jaegertracing.github.io/helm-charts
helm repo update

# 部署 Jaeger（使用 Elasticsearch 作为存储后端）
helm upgrade --install jaeger jaegertracing/jaeger \
  --namespace observability \
  --create-namespace \
  --set provisionDataStore.cassandra=false \
  --set provisionDataStore.elasticsearch=true \
  --set storage.elasticsearch.host=elasticsearch-master.observability.svc.cluster.local \
  --set storage.elasticsearch.port=9200 \
  --set collector.replicas=3 \
  --set query.replicas=2

  关键参数说明：
  provisionDataStore：控制是否自动部署存储后端。生产环境通常使用外部已有 ES 或 Cassandra 集群。
collector.replicas：根据 trace 吞吐量设置副本数，建议至少 2 个以保证高可用。
query.replicas：UI 查询服务副本数，建议与 Collector 持平或略少。

4.4 存储后端选型：Elasticsearch vs Cassandra

存储后端是 Jaeger 生产部署中最关键的决策点。Elasticsearch 与 Cassandra 在数据模型、查询能力、运维复杂度上存在显著差异。

4.4.1 核心特性对比

对比维度	Elasticsearch	Cassandra
数据模型	文档型（JSON），天然支持嵌套与全文检索	宽列存储，基于分区键与排序键
查询能力	丰富：全文搜索、聚合、范围查询、高亮	有限：仅支持按分区键 + 排序键查询，不支持 Join
写入性能	中等，受索引刷新间隔影响	极高，线性扩展，适合海量写入
运维复杂度	中高：需管理分片、副本、索引生命周期（ILM）	中：需管理节点拓扑、一致性级别、压缩策略
存储效率	较低，倒排索引占用额外空间	较高，LSM-Tree 压缩比好
Jaeger 集成成熟度	官方首选，功能最全（支持服务依赖图、Span 对比）	成熟，但部分高级功能（如 TraceQL）支持较弱
典型场景	需要复杂查询、日志与链路联动、中小规模集群	超大规模写入、多数据中心、写入密集型场景

4.4.2 选型决策树

以下决策流程可帮助团队快速确定存储后端：

4.4.3 存储后端配置示例

Elasticsearch 配置（values.yaml 片段）：

storage:
  type: elasticsearch
  elasticsearch:
    host: elasticsearch-master.observability.svc.cluster.local
    port: 9200
    user: "elastic"
    password: "changeme"
    indexPrefix: "jaeger"
    indexDateSeparator: "-"
    createIndexTemplates: true
    maxSpanAge: 168h  # 保留 7 天
    numShards: 5
    numReplicas: 1
    es.version: 7

Cassandra 配置（values.yaml 片段）：

storage:
  type: cassandra
  cassandra:
    hosts:
      - cassandra-0.cassandra.observability.svc.cluster.local
      - cassandra-1.cassandra.observability.svc.cluster.local
      - cassandra-2.cassandra.observability.svc.cluster.local
    port: 9042
    keyspace: jaeger_v1_dc1
    consistency: QUORUM
    connectionsPerHost: 4
    maxRetryAttempts: 3
    timeout: 10s
    replicationFactor: 3

生产注意事项：

Elasticsearch 需配置索引生命周期管理（ILM），避免索引无限增长导致磁盘满。
Cassandra 需提前创建 keyspace 并设置合适的复制因子（RF），RF=3 是生产最低要求。
两种存储后端均建议使用独立集群，避免与业务系统争抢 I/O 资源。

4.5 本章小结

All-in-one 模式适合开发测试，启动快但无持久化保障。
Kubernetes 生产部署 通过 Operator/Helm 实现组件解耦与水平扩展，是生产环境的唯一推荐方案。
Elasticsearch 适合中小规模、需要复杂查询的场景；Cassandra 适合超大规模写入、写入密集型场景。
存储后端选型应综合考虑 Trace 吞吐量、查询需求、运维能力与成本预算。