Stripe 只想要一个数字

# Stripe 只想要一个数字 来源：https://blog.exe.dev/billable-facts 如果你走到任何一家科技公司的工程师面前，问他们“你最喜欢开发技术栈里的哪一部分？”，我敢保证他们的答案不会和我一样：计费（billing）。 根据我的经验，当计费逻辑和常规业务逻辑纠缠在一起时，计费就会变得困难。你最终会得到一段代码，它触达了每一个需要执行计费操作的热路径。即使有 LLM，也很难不让它到处蔓延。初创公司承受不起这种代价，因为它会导致脆弱的定价结构，难以修改——而没有哪家初创公司能腾出时间重写计费系统。相反，我们应该让产品事件告诉计费系统：“有东西变了，你可能需要为此收费。”我称这些为**可计费事实（billable facts）**。 在 exe，我的目标是确保任何人都能处理计费工作，而当那些古怪的特殊情况出现时，我可以介入。我们承受不起让一个人掌握所有计费信息、并且这成为他唯一关注点的情况。Exe 不做代码审查，这意味着我们有不同的代码编写方式。我们都有权更改系统中的任何代码。代价是这就像拥有一辆车：大多数工作任何人都可以自己动手。一旦缸垫烧了，你面对的就是发动机和成百上千个零件。而我就是那个必须修缸垫的人。 在我们最早的计费阶段，我们采用了通常的做法：某个巨大的函数做了所有事情，然后带有计费副作用。给团队添加一个席位就是这样的例子： 1. 团队邀请某人以特定角色加入。 2. 用户接受邀请，验证账户，然后加入团队。 3. 用户获得团队共享虚拟机的访问权限。 4. 根据团队的计划，用户获得一定数量的计算资源配额。 5. 新用户可以使用 exe.dev。（http://exe.dev/） 6. 我们通过一系列类似于 Pee-wee 早餐机那样的含糊其辞，来弄清楚如何为这个席位收费。 席位计费的第一个实现是可行的。在这些数据库变更（包裹在事务中）的过程中，我们也向计费提供商发出了计费 API 调用。任何写过计费代码的人可能都这么干过。但常见的问题也随之而来： - 如果 API 调用失败怎么办？ - 如果数据库事务失败怎么办？ - 如果团队有奇怪的订阅状态怎么办？ - 如果为席位收费时付款被拒绝怎么办？ 我知道这会变得越来越脆弱——计费边缘情况会堆积如山。 我没有直接上线然后宣布完工（像我在过去可能做的那样），而是决定用不同的方式思考这个问题。与其让计费 API 调用散落在代码里，不如我们发布关于某事物状态的**可计费事实**，待新事实落定后再对账计费？可计费事实是表示“有东西变了”的原子操作。利用这些事实，我们可以执行任何业务逻辑，确定资源的新状态，最后再与计费提供商对账。毕竟，Stripe 只想要一个数字。它不关心我们是怎么得到这个数字的。 这是新的产品流程： 1. 团队邀请某人以特定角色加入。 2. 用户接受邀请，验证账户，然后加入团队。 3. 用户获得团队共享虚拟机的访问权限。 4. 根据团队的计划，用户获得一定数量的计算资源配额。 5. 新用户可以使用 exe.dev。（http://exe.dev/） 而计费侧是这样运作的： 1. 在邀请流程中，邀请被接受后，团队席位状态被标记为 dirty。 2. 一个下游 worker 注意到团队被标记为 dirty。 3. Worker 根据业务规则计算席位增量（seat delta）。 4. 如果增量发生变化，worker 会更新 Stripe 中的订阅数量。 有了这种架构，加入新团队成员就不再依赖我们的计费代码了。如果我们想改变席位增量的计算方式，也不会影响添加新团队成员的过程。 随着 exe 持续成长，这种计费模式一直扩展得很好。同样的对账流程也运行在我们所有的按量计费上。我们的系统会发布关于活跃虚拟机的可计费事实，比如磁盘使用情况，然后计量 worker 与计费提供商进行对账。即使我们增加了不同的用户计费方式，这些事实也不会改变。相反，工作重心转移到了如何通过各种 API 对账这些事实上。我们在 iOS 应用上看到了好处——它只需要告诉我们的系统“有人通过应用内购买订阅了”，之后的事情就会自动对账。 计费在这里正慢慢变得对其他人容易上手。和我们其余的代码一样，我们的计费架构给了人们按自己想法进行修改的灵活性。我不必担心因为有人决定重写邀请的工作方式而导致计费出问题。很开心大家不用再敲“Bryan GPT”去做计费任务了。