3. 存储后端选型：支持的后端与生产推荐方案
存储后端是 Tempo 分布式追踪查询性能的基石。选型错误会导致查询延迟飙升、运维成本失控，甚至数据丢失。本章从支持的后端清单、多维对比表、生产环境推荐方案三个层面，帮你做出可落地的决策。
3.1 支持的后端清单
Tempo 目前支持四种存储后端，覆盖从本地开发到多云生产的所有场景：
- S3（Amazon S3 / MinIO / Ceph RGW）—— 最成熟、社区生态最完善
- GCS（Google Cloud Storage）—— 与 GCP 原生集成，冷热分层成本低
- Azure Blob —— Azure 用户的首选，支持 ADLS Gen2
- Local（本地文件系统）—— 仅用于单节点开发/测试，禁止用于生产
⚠️ 生产红线：Local 后端没有数据冗余、没有水平扩展能力、没有跨 AZ 容灾。任何生产环境都不应使用 Local 后端。如果团队在 PoC 阶段使用了 Local，请在上线前完成迁移。
3.2 选型对比表
下表从 8 个关键维度对比四种后端，帮助你根据自身基础设施和性能要求做决策：
| 维度 | S3 | GCS | Azure Blob | Local |
|---|---|---|---|---|
| 数据持久性 | 99.999999999% (11个9) | 99.999999999% (11个9) | 99.999999999% (11个9) | 取决于磁盘 RAID |
| 查询延迟 (P99) | 低 (30-80ms) | 低 (30-80ms) | 中 (50-120ms) | 极低 (<5ms) |
| 水平扩展 | 原生支持 | 原生支持 | 原生支持 | 不支持 |
| 跨 AZ 容灾 | 需配置跨区域复制 | 多区域存储类 | RA-GRS | 无 |
| 冷热分层 | S3 Intelligent-Tiering | Nearline/Coldline | Cool/Archive | 无 |
| 运维复杂度 | 低 (托管) | 低 (托管) | 低 (托管) | 高 (自建) |
| 成本 (1TB/月) | ~$23 (标准) | ~$20 (标准) | ~$18 (热) | 磁盘成本 |
| 社区支持 | 最广泛 | 良好 | 良好 | 仅开发调试 |
💡 关键解读：查询延迟上 S3 和 GCS 差距不大，但 Azure Blob 在跨区域场景下延迟会明显升高。如果团队已经深度绑定某个云厂商，优先选择该厂商的原生对象存储，以减少网络出口费用和运维摩擦。
3.3 生产环境推荐方案
根据不同的基础设施现状，推荐以下三种经过验证的部署方案：
方案 A：AWS 原生栈（推荐度 ⭐⭐⭐⭐⭐）
- 后端：Amazon S3（标准存储 + Intelligent-Tiering）
- 配套：Tempo 部署在 EKS，使用 IAM Role 进行访问控制
- 优势：延迟最低、与 Grafana 生态集成最顺、社区案例最多
- 适用：已有 AWS 基础设施的团队
方案 B：多云/混合云（推荐度 ⭐⭐⭐⭐）
- 后端：MinIO 自建 S3 兼容集群（至少 4 节点，EC:4+2）
- 配套：Tempo 部署在 Kubernetes，MinIO 使用 NVMe SSD 作为缓存层
- 优势：避免厂商锁定、数据主权可控、可部署在任意机房
- 适用：金融、政府、混合云场景
方案 C：GCP 原生栈（推荐度 ⭐⭐⭐⭐）
- 后端：GCS（Standard + Nearline 冷数据自动迁移）
- 配套：Tempo 部署在 GKE，使用 Workload Identity
- 优势：冷热分层成本最优、BigQuery 可做离线分析
- 适用：GCP 为主力云的团队
📊 性能基线参考（来自生产压测）：
S3 后端 + 64GB 内存 Tempo 实例 + 100 个并发查询，P99 查询延迟稳定在 45ms 以内。
同等条件下 MinIO（NVMe + 10GbE）P99 延迟约 55ms，差距在可接受范围内。
S3 后端 + 64GB 内存 Tempo 实例 + 100 个并发查询，P99 查询延迟稳定在 45ms 以内。
同等条件下 MinIO（NVMe + 10GbE）P99 延迟约 55ms，差距在可接受范围内。
3.4 存储后端架构决策图
下图展示了从基础设施现状到最终后端选型的决策路径，以及各方案的关键权衡点：
3.5 选型检查清单
在最终确定存储后端前，请逐项确认以下条件：
- 延迟要求：你的 P99 查询延迟目标是否在 100ms 以内？如果是，S3/GCS/MinIO 均可满足；如果要求 <10ms，必须使用 Local（但仅限开发）。
- 数据量级：日均追踪数据量是否超过 1TB？如果是，必须启用冷热分层，避免标准存储成本失控。
- 容灾等级：是否需要跨 AZ 或跨 Region 容灾？S3 需配置 CRR，GCS 使用多区域存储类，Azure 使用 RA-GRS。
- 网络拓扑：Tempo 与对象存储是否在同一 Region？跨 Region 访问会增加 20-50ms 延迟。
- 运维人力：是否有专职 SRE 管理 MinIO 集群？如果团队小于 5 人，优先选择云托管服务。
🔧 快速验证命令：在选型阶段，使用
tempo-cli inspect backend 工具对候选后端进行 10 分钟压测，直接观察 P50/P99/P999 延迟和错误率。不要依赖厂商提供的 SLA 数字，实际网络环境差异很大。
3.6 常见选型误区
- 误区一：“Local 后端延迟最低，生产环境也可以用。” —— 错误。Local 没有数据冗余和扩展能力，生产环境必须使用对象存储。
- 误区二：“S3 和 MinIO 完全兼容，可以无缝切换。” —— 部分正确。MinIO 实现了大部分 S3 API，但某些高级特性（如 Object Lock、Batch Operations）不支持，迁移前需要验证。
- 误区三：“冷数据直接删掉就好，不用分层。” —— 危险。Tempo 的 trace 数据在故障排查时可能需要回溯 30 天甚至更久，删除冷数据会直接降低可观测性能力。