查询与汇总

usage 这组服务的 service ID 通常就是 usage。

这页最重要的心智

同一份 usage 事实，会被两种角色从不同角度读取：

• 用户侧：我自己用了多少
• 管理侧：哪些产品、哪些模型、哪些用户在消耗资源

所以 Downcity 不只是记录 usage，还把它整理成不同读取入口。

管理侧常见读取

const events = await admin.service("usage").get("events");
const summary = await admin.service("usage").get("summary");

这两个读取入口常见用途分别是：

• events：排查具体调用、做细粒度审计
• summary：做 dashboard、运营看板、成本概览

用户侧常见读取

const me = await user.service("usage").get("me");

适合产品里的这些界面：

• 用量页
• 账户中心
• 套餐额度展示

一个常见管理端示例

const summary = await admin.service("usage").get("summary");

return {
  usageSummary: summary,
};

这类模式很适合：

• 管理后台
• 内部运营看板
• 周期性汇总脚本

一个常见用户端示例

const me = await user.service("usage").get("me");

return {
  currentUsage: me,
};

这类模式很适合：

• 在产品里告诉用户“你已经用了多少”
• 让用户知道为什么某些额度或套餐状态发生变化

为什么不直接只开放一个 events 接口

因为绝大多数使用场景并不想每次都自己重新聚合：

• 管理侧通常想直接看汇总结果
• 用户侧通常只想看自己的数据

所以把不同视角分成不同读取入口，会比“所有人都自己拿原始 events 再处理”更实用。

常用 API / 入口

这一页最相关的调用入口是：

• admin.service("usage").get("events")
• admin.service("usage").get("summary")
• user.service("usage").get("me")

常见误解

summary 不是“可有可无的糖”

很多后台和报表最需要的就是聚合结果，而不是原始事件列表。

用户侧也可以直接看 usage

usage 不只是内部运维数据，也可以是用户产品体验的一部分。

原始事件和汇总不应该混成一个概念

排查、运营、产品展示，关注点完全不同。

继续阅读

• 想理解 usage 本身记录什么，读 Usage 事实模型
• 想把 usage 接到套餐和收费规则，读 和计费逻辑怎么配