3. Tempo 部署模式：单体模式、微服务模式、Serverless 模式对比与适用场景
Grafana Tempo 支持三种部署模式：单体模式、微服务模式和Serverless 模式。不同模式在资源消耗、运维复杂度、扩展能力和成本结构上差异显著。选择哪种模式取决于你的追踪数据规模、SLA 要求以及基础设施成熟度。
3.1 三种部署模式架构总览
下图展示了三种部署模式的核心组件分布与网络边界。单体模式将所有进程打包为一个二进制；微服务模式按职责拆分为独立组件；Serverless 模式则将后端存储与查询层分离，利用函数计算处理无状态任务。
3.2 三种模式详细对比
| 对比维度 | 单体模式 | 微服务模式 | Serverless 模式 |
|---|---|---|---|
| 部署复杂度 | 低：单个二进制 + 配置文件 | 中：需编排多个服务（K8s 或 Nomad） | 中高：需管理 Lambda 函数 + 事件触发 |
| 组件隔离 | 无隔离，一个组件 OOM 影响全局 | 完全隔离，故障域独立 | 查询/压缩无状态，写入组件仍为常驻 |
| 扩缩容粒度 | 整体扩缩，资源浪费 | 按组件独立扩缩，资源利用率高 | 查询层自动弹性，写入层需手动扩缩 |
| 查询延迟 | 低（进程内通信） | 中低（gRPC 内网通信） | 中高（Lambda 冷启动 + 网络开销） |
| 运维成本 | 低：单进程监控 | 中：需监控多个服务 + 链路依赖 | 中：需管理 Lambda 日志 + 并发限制 |
| 适用数据规模 | < 100 GB/天 | 100 GB ~ 10 TB/天 | < 1 TB/天（查询量波动大） |
| 典型场景 | 开发环境、POC、小团队 | 生产环境、多租户、高可用要求 | 成本敏感、查询频率低、突发流量 |
3.3 单体模式部署架构
单体模式将所有 Tempo 内部组件打包为一个进程，适合快速验证和小规模场景。所有组件共享内存和 CPU，配置简单，但缺乏隔离性。
实践建议：单体模式适合每日追踪数据量小于 100GB 的场景。如果使用 Docker Compose 部署，建议设置内存限制（如
--memory=4g）防止 ingester 组件占用过多内存导致 OOM。单体模式下，target: all 是默认配置，但也可以指定 target: scalable-single-binary 启用无状态写入模式。
3.4 微服务模式部署架构
微服务模式将 distributor、ingester、querier、compactor、query-frontend 拆分为独立部署单元。每个组件可以独立扩缩容，适合生产环境。通常使用 Kubernetes 部署，每个组件对应一个 Deployment 或 StatefulSet。
| 组件 | 职责 | 扩缩容策略 | 资源需求 |
|---|---|---|---|
| distributor | 接收追踪数据，进行哈希分片和负载均衡 | 水平扩展（无状态） | CPU 密集型，2~4 核 |
| ingester | 将追踪数据写入后端存储，构建内存索引 | 水平扩展（有状态，需持久化） | 内存密集型，8~32 GB |
| querier | 从存储中读取数据并执行查询 | 水平扩展（无状态） | CPU + 内存均衡，4~8 核 |
| compactor | 合并小文件，清理过期数据 | 单实例或少量实例 | CPU 密集型，2~4 核 |
| query-frontend | 查询缓存、分片、合并结果 | 水平扩展（无状态） | 内存密集型，4~8 GB |
注意：微服务模式下，ingester 组件是有状态的，需要配置持久卷（PVC）来存储 WAL 文件。如果 ingester 重启后 WAL 丢失，会导致最近几分钟的追踪数据不可用。建议为 ingester 配置
ingester.lifecycler.ring.store: consul 或 etcd 来管理成员状态。
3.5 Serverless 模式部署架构
Serverless 模式将查询和压缩任务卸载到 AWS Lambda 函数中执行，写入组件（distributor + ingester）仍然作为常驻服务运行。这种模式适合查询频率低、成本敏感的场景，但查询延迟会因 Lambda 冷启动而增加。
| 组件 | 部署方式 | 触发方式 | 注意事项 |
|---|---|---|---|
| distributor | 常驻服务（ECS / K8s） | 持续运行 | 需要配置 Lambda 作为后端存储 |
| ingester | 常驻服务（ECS / K8s） | 持续运行 | WAL 写入 S3 或 EFS |
| querier (Lambda) | AWS Lambda 函数 | API Gateway / ALB 触发 | 冷启动延迟 200~500ms，建议预留并发 |
| compactor (Lambda) | AWS Lambda 函数 | S3 事件通知触发 | 执行时间限制 15 分钟，大文件需分片 |
成本对比参考：以每日 500GB 追踪数据、每月查询 10 万次为例：单体模式约 $800/月（4 台 8 核 32GB 实例），微服务模式约 $1200/月（6~8 个 Pod），Serverless 模式约 $500/月（常驻 2 台实例 + Lambda 按量计费）。Serverless 模式在查询量低时成本优势明显，但查询量超过 50 万次/月后，微服务模式更经济。
3.6 模式选择决策树
根据你的实际需求，可以按照以下决策树选择部署模式：
- 数据量 < 100 GB/天 且 查询量 < 1 万次/天？ → 单体模式（最简单，运维成本最低）
- 数据量 100 GB ~ 10 TB/天 或 需要高可用？ → 微服务模式（隔离性好，扩缩容灵活）
- 数据量 < 1 TB/天 且 查询频率低 且 成本敏感？ → Serverless 模式（按量付费，无需常驻查询资源）
- 已有 AWS 基础设施且希望减少运维？ → Serverless 模式（Lambda + S3 原生集成）
- 需要多租户隔离或跨区域部署？ → 微服务模式（每个租户独立 querier 或独立 ingester）
迁移路径：推荐从单体模式开始，当数据量增长到 100 GB/天时，切换到微服务模式。Tempo 的配置结构在两种模式之间高度兼容，只需将
target: all 改为 target: <component> 并调整网络配置即可。Serverless 模式适合作为查询层的补充，例如将历史数据查询卸载到 Lambda，常驻服务只处理最近 7 天的热数据。