1. 课程导入与全景认知
SaaS 的商业模式从"卖许可证"转向"卖用量"之后，工程团队面对的第一个硬问题就是：一次用户行为，究竟该被记成多少量？这个问题看似只是计数，实际牵动计费准确性、客户信任、成本核算与产品定价四条线。本章不写代码，先把全景铺开——搞清楚计量与配额到底在解决什么、边界画在哪里、系统由哪些部件组成，为后续 29 章的深入实现建立坐标系。
一、业务价值：为什么计量与配额是 SaaS 的"水电表"
传统软件一次性售卖，收入在签约时确定；SaaS 按用量收费，收入随客户行为持续产生。这意味着计量数据本身就是收入凭证。如果计量漏记，公司少收钱；如果重复计量，客户投诉甚至流失；如果计量延迟，财务无法及时出账。三类典型损失可以这样理解：
- 收入泄漏：API 调用未被采集，某客户月均 200 万次调用只记到 180 万次，按 0.001 元/次计，单客户每月损失约 200 元，千客户规模即年损失约 240 万元。
- 成本失控：配额不设上限，某租户跑批任务把共享数据库连接池打满，影响其他租户，SLA 违约赔偿远超该租户贡献的收入。
- 信任崩塌：账单与客户自建监控对不上，客户要求逐条核对，支持成本飙升，续约率下降。
因此，计量与配额不是"计费系统的一个模块"，而是贯穿产品、研发、财务、客户成功的横向能力。它的价值可以概括为三句话：让收入可追溯、让成本可约束、让客户可自证。
二、核心概念：把"用量"拆成可工程化的对象
要工程化，先要统一语言。以下五个概念是后续所有设计的基石，建议先建立精确定义：
| 概念 | 定义 | 示例 |
|---|---|---|
| 计量事件（Meter Event） | 一次可被计量的业务动作，含租户、指标、数量、时间戳、幂等键 | 租户 T-1001 在 10:00:03 调用 OCR 接口 1 次，事件 ID evt_9f2a |
| 计量指标（Metric） | 被计量的维度，决定"记什么" | api_calls、storage_gb_hours、seats_active、tokens_processed |
| 聚合（Aggregation） | 把原始事件按时间窗与维度汇总 | 按小时 SUM(api_calls)，按天 MAX(storage_gb) |
| 配额（Quota） | 对某指标在周期内的允许上限或速率限制 | 每月 100 万次 API 调用；每秒 50 次并发 |
| 用量快照（Usage Snapshot） | 某时刻已确认的累计用量，用于展示与出账 | 截至 10 月 20 日 24:00，已用 63.2 万次 |
这里有一个容易混淆的点：计量（Metering）与计费（Billing）不是一回事。计量回答"用了多少"，计费回答"该收多少钱"。计量输出的是用量事实，计费再叠加价格计划、折扣、税费、账期。把两者混在一个服务里，会导致价格调整时被迫改动采集链路，风险极高。
三、系统边界：谁负责记，谁负责算，谁负责收
画清边界是本章最重要的工程决策。一个常见的错误是把计量逻辑散落在各业务服务里，每个服务自己写数据库计数，结果口径不一、无法对账。正确的做法是业务服务只负责"上报事件"，计量平台负责"接收、聚合、存储、查询"。
边界可以这样划分：
- 业务侧：在关键动作处埋点，生成计量事件并异步投递，不阻塞主流程。
- 计量平台：接收事件、幂等去重、按窗口聚合、写入时序/分析存储、对外提供用量查询 API。
- 配额服务：维护配额定义与实时消耗，提供"检查—扣减—回滚"接口，供业务侧在动作前调用。
- 计费系统：从计量平台拉取已确认用量，结合价格计划生成账单，不直接接触原始事件。
下面这张图给出整体工程框架：左侧是业务动作产生事件，中间是计量与配额双通道，右侧是消费方。注意配额通道是同步、低延迟的，计量通道是异步、可缓冲的，两者共享同一份指标定义，但走不同的技术路径。
四、典型场景：四类必须覆盖的用量形态
不同产品的用量形态差异极大，工程上要提前识别属于哪一类，因为它直接决定聚合方式与配额策略：
- 计数型：API 调用次数、消息条数。特点是高频、可累加，适合 SUM 聚合，配额用"周期总量 + 速率限制"双约束。
- 计量型：存储 GB、Token 数。特点是数值连续，需要按时间加权，例如"存储 GB·小时"，配额用"峰值上限"。
- 状态型：活跃席位、并发连接数。特点是随时间变化，需要记录状态变更事件，聚合用 MAX 或按时间积分。
- 资源型：GPU 时长、专属实例。特点是占用即消耗，需要"开始—结束"配对，防止泄漏导致虚高。
以存储为例，若某租户 10 月 1 日存入 100 GB，10 月 11 日扩容到 300 GB，10 月 21 日删除到 150 GB，按"GB·天"计费，则 10 月用量为 100×10 + 300×10 + 150×11 = 5650 GB·天。这个计算说明：状态型指标必须记录变更时间点，否则无法还原。这也是很多团队初期用"每日快照"导致账单偏差的根因。
五、工程框架的四个关键设计原则
在进入后续章节前，先记住四条原则，它们会在每个模块反复出现：
- 幂等优先：每个计量事件必须带唯一幂等键（如 tenant_id + metric + request_id），接收端去重，避免重试导致重复计量。
- 先计量后计费：原始事件不可变，聚合结果可重算。价格调整只影响计费层，不回溯修改事件。
- 配额与计量解耦：配额走同步快路径，计量走异步慢路径，两者通过同一份指标定义对齐口径，但不共享存储。
- 可对账：任何时刻，客户看到的用量、计费系统用的用量、内部监控的用量，三者应能通过同一份快照对齐，差异可解释。
最后强调一个常被忽视的边界问题：计量平台不应承担业务判断。它只回答"某租户某指标在某时间窗内用了多少"，不回答"这个租户是否该被限流"。限流决策属于配额服务，计费决策属于计费系统。把判断逻辑上移到消费方，计量平台才能保持稳定、可重算、可审计——这正是整套工程框架能够长期演进的前提。