订阅与计费 — 把"按时间和用量收钱"做成可对账的引擎Subscription & Billing: Lifecycle State Machine, Proration, Usage Metering, Multi-currency & Tax

问题场景与需求约束

设计一个 SaaS 计费平台（类似 Stripe Billing / Chargebee）：10 万企业订阅，混合定价 = 月度/年度固定费（seat-based）+ 按量计费（API 调用、存储 GB）。客户随时升降级套餐、增减席位，跨 30+ 国家、多货币、需自动算税。这是 Day 17 支付的上游：支付解决"怎么把一笔钱安全收掉"，计费解决"这个月到底该收多少钱、向谁、为什么"。

面试要先澄清的关键约束：

• 金额永远整数：minor units（分）存储，绝不用 float，否则四舍五入误差累积成对账 break。
• 账单可解释：每张 invoice 的每一行（line item）都要能追溯到"为什么是这个数"——监管与客户投诉都要查。
• 变更幂等：扣费 cron 重跑、客户重复点"升级"都不能多生成一张 invoice。
• 规模：固定费扣费 ~10 万张 invoice/月，但用量事件 ~10 亿/天——计费的真正吞吐瓶颈在 metering 不在 invoicing。
• 延迟：账单生成可异步（分钟级），但 proration 预览要同步（< 300ms）让客户当场看到差价。

高层架构

组件职责：① Pricing Catalog 定义产品、价格、计划（版本化，改价不影响存量订阅）；② Subscription Service 维护每个订阅的生命周期状态机；③ Metering 把海量用量事件去重、聚合成可计费数量；④ Billing Engine 是核心——周期到点把"固定费 + 用量 + proration 调整 + 税"汇成一张 invoice；⑤ 账单交给 Day 17 的幂等支付收款，失败进 Dunning 催收；⑥ 所有金额落 Ledger 做收入确认与对账。

关键技术点

① 订阅生命周期状态机 + 周期触发 — 让"到点扣费"既不漏也不重

核心 trade-off：用一个显式落库的状态机，换掉散落在各处的 if-else 与重复扣费风险。

【原理】订阅不是一个布尔"激活/未激活"，而是状态机：trialing → active → past_due → canceled / unpaid。状态转移由两类事件驱动：时间（周期结束 = 该出账）和动作（升级、取消、支付成功/失败）。到点扣费的触发有两种实现：扫表 cron（每分钟查 next_billing_at <= now）或为每个订阅注册一个 scheduled job。关键是幂等：把"为周期 P 生成 invoice"用 (subscription_id, period_start) 做唯一键，cron 重跑只命中已存在的 invoice，绝不重复出账。

# pseudo-code: 幂等周期出账（cron 每分钟跑）
def bill_due_subscriptions(now):
    for sub in db.query("status IN ('active','past_due') AND next_billing_at <= %s", now):
        period = (sub.current_period_start, sub.current_period_end)
        # 唯一键去重：同周期只出一张账
        inv = db.get_or_create_invoice(sub.id, period[0])
        if inv.status != 'draft':          # 已出过 → 跳过
            continue
        add_recurring_lines(inv, sub)      # 固定费/席位
        add_metered_lines(inv, sub, period)# 用量（见技术点③）
        finalize_and_charge(inv)           # 定稿→交支付
        sub.advance_period()               # 推进到下一周期

② Proration（按比例计费）— 中途变更怎么"补差价"

核心 trade-off：proration 让定价公平且即时，但每一次变更都往账单塞入正负两条调整行，复杂度与可解释性成本陡增。

【原理】客户在周期中途从 $10/月 升到 $20/月，不能整月按新价收。proration 把变更点切成两段：退还旧套餐剩余时间的未使用部分（负数 credit），补收新套餐剩余时间（正数 charge）。半个月升级 → -$5（旧价未用）+ $10（新价剩余）= 净补 $5。这些以 invoice line item 形式累积，下次出账或立即结算。比例因子 = 剩余秒数 / 周期总秒数——按秒算，不是按天，否则边界不公。

# pseudo-code: 升级 proration（按秒比例）
def prorate_change(sub, new_price, now):
    total = sub.period_end - sub.period_start      # 周期总秒数
    remain = sub.period_end - now                  # 剩余秒数
    factor = remain / total
    credit = -round(sub.current_price * factor)    # 退旧价未用（minor units）
    charge =  round(new_price        * factor)     # 补新价剩余
    add_line(sub.invoice, "unused time credit", credit)
    add_line(sub.invoice, "remaining time @ new", charge)
    sub.current_price = new_price                  # 余额 credit 抵扣，不退现金

③ 用量计费（Metering）— 10 亿事件/天怎么聚合成几个数字

核心 trade-off：在精度（每个事件都算）与吞吐/成本（聚合后再记）之间权衡，外加迟到事件破坏已定稿账单的风险。

【原理】metering pipeline 四段：Emit（业务发用量事件）→ Ingest（校验+幂等去重）→ Meter（聚合成可计费量）→ Invoice（汇入账单）。10 亿/天直接一条条写 DB 会爆，工业做法是两级聚合：先在应用内存/Redis 按 (customer, meter, 小时) 累加，每分钟 flush 一次到 Postgres rollup 表，出账时只 SUM 几千行小时桶。聚合函数受限：通常只支持 sum / count / last——"峰值并发""日均存储"这类 max/avg 要业务侧自己算好上报 last 值。事件必须带 幂等键（event_id）去重，否则客户端重试 = 多计费。

# pseudo-code: 两级聚合 + 幂等去重
def ingest(event):
    if not redis.set(f"seen:{event.id}", 1, nx=True, ex=DAY):  # 幂等
        return                                  # 重复事件丢弃
    key = (event.customer, event.meter, hour_bucket(event.ts))
    redis.hincrby("usage", key, event.qty)      # 内存累加

def flush_every_minute():                        # 二级：落 Postgres
    for key, qty in redis.hgetall("usage"):
        db.upsert_rollup(key, qty)               # 小时桶
# 出账：SELECT SUM(qty) ... WHERE customer=? AND ts IN [period]

④ 多货币与税务 — 同一套引擎服务全球

核心 trade-off：本币计价体验最好，但引入 FX 风险、税则复杂度与对账维度爆炸。

【原理】两件事必须做对。货币：每个 price 用 minor units + ISO 货币码存储（日元无小数、第纳尔三位小数——别假设两位）；跨币种不在出账时实时换汇，而是为每币种预设价格，避免汇率波动让账单不可复现。税：税额是额外加（exclusive，美国常见）还是已含（inclusive，欧盟含 VAT）由地区/货币决定；商品要打 tax code 决定税率与是否免税。税在出账瞬间按当时税率冻结进 invoice，事后税率变更不回改历史账单。

扩展与优化（增长后怎么办）

• 出账尖峰：把账单 anchor date 打散到全月（而非都在 1 号），billing run 按客户分片并行；用量 rollup 提前到周期内增量计算，出账时只做收尾。
• Dunning（催收）：支付失败不等于流失——按 backoff 重试（如第 1/3/5/7 天），配合 smart retry（避开发卡行拒付高峰）、邮件提醒、最后降级到 unpaid。这是 SaaS 挽回收入的关键一环。
• 收入确认（RevRec）：年付一次性收钱但要按月确认收入（ASC 606 / IFRS 15），靠 Ledger 把"已收现金"与"已确认收入"分开记——预收款是负债，逐月转收入。
• 定价实验：Pricing Catalog 版本化，新价格只对新订阅生效，存量订阅 grandfather（保留旧价）；改价绝不能就地改存量订阅的引用。
• 对账：billing 的 invoice 总额 ⇄ 支付实收 ⇄ ledger 收入，三方逐笔对账（接 Day 17 的对账作业），任何 break 都要可定位到 line item。

常见陷阱 + 面试追问

高频追问：① 周期出账用 cron 还是 per-subscription timer，怎么保证不漏不重？② 中途升级的 proration 一步步算给我看（按秒）。③ 10 亿用量事件/天的 metering 怎么设计，迟到事件怎么办？④ 年付怎么做收入确认，现金和收入为什么要分开记？⑤ inclusive vs exclusive 税，多币种为什么不实时换汇？

深入资源

• Stripe Billing — Subscriptions Overview & Prorations（overview / prorations）：生命周期状态机与按秒 proration 的权威实现。
• Stripe — Designing robust and predictable APIs with idempotency（stripe.com/blog/idempotency）：出账与变更幂等的工程基础。
• Stripe Billing Meters / Usage-based billing（recording usage）：用量聚合 sum/count/last 与高频上报的官方建议。
• Stripe Tax — Tax behavior & multi-currency（tax behavior）：inclusive/exclusive 与多币种税则。
• TigerBeetle — Debit/Credit schema（docs）：把收入确认建成双重记账不变量。
• 《Designing Data-Intensive Applications》（Kleppmann）：批处理出账、幂等与对账思想的底层原理。

深入思考（点击展开答案）