指标服务化解决什么
指标服务把取数逻辑收敛到统一接口：按「指标编码加维度加时间范围」查询，统一做鉴权、缓存与限流，避免每个业务系统各写一份 SQL。接口返回时同时带回口径版本号与查询条件回执，消费方能感知口径切换，也便于复现同一次查询。没有服务化时，同一个指标在不同系统里会被算出不同数字，出了问题也很难定位到底是谁算错了。
基本信息
| 入参 | 指标编码、维度过滤、时间范围 |
|---|---|
| 能力 | 鉴权、缓存、限流、访问审计 |
| 返回 | 数值、口径版本、查询回执 |
| 查询模式 | 点查、批量、导出 |
| 收益 | 口径统一、复用、可审计 |
典型使用场景
- 应用系统内嵌指标看板，直接调接口而不是各自连表计算
- 报表平台统一取数，避免每个报表维护一份口径
- 向合作方按权限开放数据，需要鉴权与访问审计
- 高并发场景通过缓存与限流保护底层查询集群
- 口径切换时依靠返回的版本号让消费方感知变化
接口示例
接口示例
# 指标查询接口示例
metric: PAY_AMT_7D
dims: region=east, channel=app
period: start=2026-10-01 end=2026-10-11
granularity: day
response:
data: [{dt: 2026-10-11, value: 12345.67, version: v2}]
meta: {cached: true, ttl: 300s}
# 返回必须带口径版本号，便于消费方识别口径切换接口要素
| 要素 | 要求 | 缺失的后果 |
|---|---|---|
| 指标编码 | 受控编码，不可随意拼接 | 口径失控，返回值不可解释 |
| 维度过滤 | 取值受维度表约束 | 自由文本过滤会漏数或重数 |
| 版本号 | 返回中透出口径版本 | 口径切换静默生效 |
| 缓存与限流 | 按指标与维度分别配置 | 热点查询拖垮底层集群 |
缓存要联动口径变更：指标版本切换时主动失效相关缓存，否则会出现新旧口径同时返回的窗口期，用户看到的数字忽高忽低。
接口要有访问审计：谁在什么时候查了哪个指标、什么维度，既是安全要求，也是排查异常用量的依据。