3. Tempo 部署模式：单体模式、微服务模式、Serverless 模式的选择与对比
Grafana Tempo 支持三种部署模式：单体模式 (Single Binary)、微服务模式 (Microservices) 和 Serverless 模式。选择哪种模式取决于你的追踪数据规模、运维团队能力、成本预算以及弹性需求。本章将深入对比这三种架构，帮助你为值班台选择最合适的部署方案。
值班台建议： 对于大多数中小规模团队（日处理追踪数据 < 5TB），单体模式是性价比最高的起点。当数据量持续增长或需要独立扩缩容特定组件时，再平滑迁移至微服务模式。
3.1 三种模式架构总览
下图展示了三种部署模式的组件边界与通信关系。核心组件（Distributor、Ingester、Querier、Compactor）在所有模式中均存在，但部署密度和网络拓扑不同。
3.2 核心差异对比表
下表从运维、性能、成本和扩展性四个维度，对三种模式进行详细对比：
| 对比维度 | 单体模式 | 微服务模式 | Serverless 模式 |
|---|---|---|---|
| 部署复杂度 | 极低：单进程部署，无外部依赖 | 高：需管理多个服务、服务发现、负载均衡 | 中：需配置云函数触发器与权限 |
| 资源隔离 | 无隔离：组件争抢 CPU/内存 | 完全隔离：每个组件独立资源 | 函数级隔离：冷启动可能影响延迟 |
| 扩缩容粒度 | 整体扩缩：无法单独扩容 Ingester | 组件级：可独立扩容 Ingester/Querier | 函数级：自动弹性，粒度最细 |
| 运维成本 | 低：单一日志/监控/告警 | 高：需监控多个服务实例 | 中：依赖云厂商基础设施 |
| 查询延迟 | 低：进程内通信无网络开销 | 中：gRPC 网络延迟约 1-5ms | 高：冷启动 + 网络延迟可达 100ms+ |
| 成本模型 | 固定：按实例付费，空闲时浪费 | 固定：按组件实例付费 | 按需：按调用次数和时长计费 |
| 适用规模 | 日处理 < 5TB，节点数 < 10 | 日处理 5TB-50TB，节点数 10-100 | 日处理 < 1TB 或突发流量场景 |
| 典型场景 | 开发测试、中小团队生产环境 | 大型生产环境、多租户场景 | 边缘追踪、低频查询、事件驱动 |
3.3 单体模式详解
单体模式将所有 Tempo 组件打包到一个二进制文件中运行，是上手最快、运维最简单的部署方式。
3.3.1 配置示例
# tempo-single.yaml
target: all # 启动所有组件
server:
http_listen_port: 3200
distributor:
receivers:
otlp:
protocols:
grpc:
endpoint: 0.0.0.0:4317
ingester:
lifecycler:
ring:
kvstore:
store: inmemory # 单体模式使用内存存储环信息
storage:
trace:
backend: s3
s3:
bucket: tempo-traces
endpoint: s3.amazonaws.com
pool:
max_workers: 100
compactor:
compaction:
block_retention: 48h3.3.2 适用条件
- 数据量：日处理追踪数据 < 5TB
- 节点数：Ingester 副本数 < 10
- 团队规模：运维人员 < 3 人
- 可用性要求：允许分钟级故障恢复
注意： 单体模式下，所有组件共享进程资源。如果 Ingester 因内存压力 OOM，会导致 Distributor、Querier 同时不可用。建议为单体模式配置 cgroup 内存限制，并设置合理的 GOMEMLIMIT 环境变量。
3.4 微服务模式详解
微服务模式将每个 Tempo 组件部署为独立服务，是生产环境最常用的部署方式。每个组件可以独立扩缩容、独立配置资源限制。
3.4.1 组件通信架构
下图展示了微服务模式下各组件的网络拓扑与数据流：
3.4.2 关键配置参数
# tempo-microservices.yaml
# 每个组件使用独立的配置文件，以下为 Ingester 示例
target: ingester
ingester:
lifecycler:
ring:
kvstore:
store: consul # 生产环境使用 Consul/Etcd
consul:
host: consul:8500
replication_factor: 3 # 数据复制因子
storage:
trace:
backend: s3
s3:
bucket: tempo-traces
endpoint: s3.amazonaws.com
overrides:
max_traces_per_user: 1000003.5 Serverless 模式详解
Serverless 模式将 Tempo 组件部署为云函数（如 AWS Lambda、Google Cloud Functions），适合极低负载或突发流量场景。该模式通过 Tempo Serverless 项目实现，将 Ingester、Querier 等组件包装为函数。
3.5.1 架构特点
- 零闲置成本：无流量时函数不运行，不产生费用
- 自动弹性：流量突增时自动创建数百个函数实例
- 冷启动延迟：首次调用或长时间空闲后，函数启动需 1-5 秒
- 有状态限制：Ingester 需将数据持久化到外部存储，无法利用本地磁盘
3.5.2 适用场景
| 场景 | 说明 | 推荐模式 |
|---|---|---|
| 开发/测试环境 | 低负载、非持续运行 | 单体模式 |
| 中小规模生产 | 日处理 1-5TB，团队运维能力有限 | 单体模式 |
| 大规模生产 | 日处理 > 5TB，需要组件级扩缩容 | 微服务模式 |
| 边缘/物联网 | 间歇性上报，流量波动极大 | Serverless 模式 |
| 事件驱动追踪 | 基于 CI/CD 事件触发追踪 | Serverless 模式 |
3.6 模式选择决策树
以下决策树可以帮助你快速确定最适合的部署模式：
- 数据量是否 < 5TB/天？
- 是 → 进入第 2 步
- 否 → 选择 微服务模式
- 是否有专职 SRE 团队？
- 是 → 选择 微服务模式（为未来扩展预留空间）
- 否 → 进入第 3 步
- 流量是否高度突发？
- 是 → 选择 Serverless 模式
- 否 → 选择 单体模式
值班台最佳实践： 建议从单体模式开始，使用 Docker Compose 或单节点 Kubernetes Deployment 部署。当 Ingester 的 CPU 使用率持续超过 70% 或内存使用率超过 80% 时，考虑迁移到微服务模式。迁移过程可以逐步进行：先独立部署 Distributor 和 Ingester，再逐步分离 Querier 和 Compactor。
3.7 迁移路径建议
从单体模式迁移到微服务模式时，建议遵循以下步骤：
| 阶段 | 操作 | 风险等级 |
|---|---|---|
| 1. 准备 | 将后端存储从 inmemory 切换到 S3/GCS；配置 Consul/Etcd 作为 KV 存储 | 低 |
| 2. 分离 Distributor | 将 Distributor 部署为独立服务，指向原有的 Ingester 地址 | 低 |
| 3. 分离 Ingester | 将 Ingester 部署为独立 StatefulSet，配置复制因子 | 中 |
| 4. 分离 Querier | 将 Querier 部署为独立 Deployment，配置查询路径 | 低 |
| 5. 分离 Compactor | 将 Compactor 部署为独立 Deployment，配置压缩策略 | 低 |
| 6. 优化 | 调整各组件资源限制、配置 HPA 自动扩缩容 | 低 |
选择正确的部署模式是 Tempo 运维的第一步。单体模式提供最低的运维成本，微服务模式提供最佳的扩展性和隔离性，Serverless 模式则适合极低负载或突发流量场景。值班台应根据实际数据规模和团队能力，选择最合适的模式，并规划好未来的迁移路径。