生产级市场后端

Source: Dev.to

为什么市场平台后端在上线后会出问题（以及如何为正确性而设计）

大多数市场平台后端并不是因为缺少功能而出问题。
它们出问题是因为库存、金钱和重试在生产环境中相互冲突。

如果你曾经运营过一个市场平台（B2B 或 B2C），下面的情况可能对你很熟悉：

• 高并发下库存出现负数
• 订单卡在无效状态
• 重试悄悄产生重复数据
• 发票与客户实际付款不匹配
• “维护模式”在事故期间把管理员锁了出去

这些问题通常在开发阶段不会出现。它们会在上线后，在并发、重试和部分失败的情况下显现。

常见根本原因

根据我的经验，这些问题大多来源于几种设计上的捷径：

• 库存直接存放在商品表中
• 订单状态转换散落在各个控制器里
• 使用浮点数表示金钱
• “直接重试请求”的逻辑
• 全局守卫强制业务规则

这些做法在一切顺利时可以工作，但一旦出现异常就会失效。

正确性优先的市场平台后端应该是什么样子

在为真实生产使用设计市场平台后端时，我对几个不可妥协的要点形成了自己的观点。

库存必须结构化安全

库存应当：

• 独立存放在自己的表中
• 使用数据库级锁进行保护
• 明确地进行预留、释放和最终确认

如果可能出现超卖，迟早会发生。

订单需要真实的状态机

订单应当：

• 通过明确的状态流转
• 在中心位置进行校验
• 永不跳过状态转换

当订单逻辑被分散时，数据损坏是不可避免的。

金钱必须是不可变且基于整数的

• 不使用浮点数
• 不从实时商品数据重新计算总额
• 订单项和发票必须基于快照

一旦订单确认，财务数据就不应再改变。

重试必须默认安全

重试不是边缘案例——它们是常态。这意味着：

• 对写操作使用幂等键
• 数据库强制唯一性约束
• 安全的重放而不是产生重复副作用

运维工具绝不能把操作员锁在外面

全局守卫和硬编码配置是风险点。维护模式、功能标记和运行时设置应当：

• 基于数据库存储
• 可审计
• 始终允许管理员绕过

在生产事故中发现自己被锁在外面是最糟糕的情况。

为什么这很重要

大多数团队在生产中吸取这些教训后，最终不得不重建后端。

我一直在构建一个符合生产级别的 B2B 市场平台后端，从第一天起就围绕这些原则设计：

• 通过结构防止超卖
• 严格的订单生命周期约束
• 基于快照的财务正确性
• 幂等且安全的写入路径
• 管理员安全的运营控制

这不是一个 MVP 脚手架——而是你在上线六个月后通常会希望拥有的后端。

如果你正在构建一个市场平台并考虑生产就绪，我随时乐于交流经验或一起审视设计决策。

正确性第一。
生产环境要稳妥。
这就是目标。