APM 支持跨应用共享数据源
0x01 背景
a. Why
当前 APM 采用一应用一数据源的架构，每个应用独占一组 ES 索引。
资源压力来自索引数量线性膨胀：
- 分片数随应用数量增长。
- 集群元数据开销持续增大。
- ES 资源碎片化加剧。
b. 目标
- 索引收敛：多应用复用同一数据源，将 ES 索引数量从与应用数等比增长收敛至可控的共享池规模
- 查询透明：共享模式对上层查询透明兼容，应用间数据通过业务和应用维度严格隔离
- 可扩展：方案预留日志、指标等数据类型的共享空间，本期聚焦 Trace
0x02 实现路线
a. 建议的方案
模型与抽象
- 关系模型：应用与数据源从
1:1改为N:1 - 核心抽象：引入「共享数据源池」，独立管理容量和元数据
- 分配策略：创建应用时优先复用使用量最低的可用数据源
- 兜底策略：无可用数据源时自动新建
- 回收策略：删除应用时释放使用量
- 命名策略：共享数据源在全局公共空间注册，采用统一序列号命名
数据写入
- 注入入口：采集链路在数据清洗阶段从认证令牌反解业务和应用标识
- 注入内容：将
bk_biz_id与app_name写入原始数据 - 适用范围：共享模式和独占模式统一注入
数据查询
- 逻辑层隔离：结构化查询、拓扑发现、全文检索等路径统一追加业务和应用维度过滤条件
- 路由层依赖：元数据路由层需支持以业务维度过滤查询全局公共空间结果表
- 降级策略：若路由层能力不足，则 APM 查询层直接指定结果表绕过路由
生命周期管理
- 关联方式：现有应用数据源配置层增加对共享池的关联
- 共享模式：复用池中的数据链路标识，不再自建结果表和索引
- 启停边界：共享模式下跳过对结果表的直接操作
b. 约束
- 本期仅覆盖 Trace 数据类型，日志和指标的共享支持后续迭代
- 不支持存量应用从独占模式迁移到共享模式，仅对新建应用生效
- 元数据路由层对全局结果表按业务过滤的能力为跨团队依赖项，需与 metadata 团队确认
- 共享数据源本期不创建日志索引集
0x03 参考
- 关联子 issue：APM 预计算适配共享数据源
- 涉及模块：数据源模型、应用资源接口、Trace 查询处理层、采集端