Writes concise architecture de…

# 订单系统库存服务拆分架构决策说明

一、背景与问题

• 当前订单系统为单体架构，库存扣减逻辑与订单创建、支付、退款等模块耦合在同一应用中，随业务增长暴露以下问题：
• 性能瓶颈：大促期间订单与库存竞争同一数据库连接和行锁，扣库存超时频发。
• 扩展性差：库存属于高频写场景，无法独立水平扩容，只能整体扩容单体应用，资源浪费。
• 耦合风险：库存逻辑变更需整体发版，影响订单主流程稳定性；故障互相传染。
• 多渠道诉求：跨境电商需对接多平台（自有站、第三方平台），库存需统一池化管理，单体难以支撑。

二、备选方案对比

方案A：维持单体，模块内优化

• 通过数据库乐观锁、热点分片、缓存预热优化库存扣减。
• 优点：改造成本低，无分布式事务问题。
• 缺点：无法根本解决扩展性与多渠道统一库存的诉求，技术债持续累积。

方案B：拆分库存服务 + 同步调用（RPC）

• 库存独立成服务，订单通过同步RPC扣减库存。
• 优点：调用链路简单，实时性强，语义清晰。
• 缺点：订单强依赖库存可用性；跨服务同步调用放大延迟；峰值期需复杂限流降级。

方案C（选定）：拆分库存服务 + Kafka异步消息

• 库存独立部署，订单侧通过Kafka发布订单事件，库存服务消费并扣减；库存变更结果再经Kafka回传。
• 辅以Redis预扣减应对峰值，数据库做最终持久化。

三、取舍与权衡

• 选Kafka而非RPC：削峰填谷、解耦故障域（库存服务短暂不可用不影响订单受理），但引入最终一致性，需接受秒级延迟窗口。
• 一致性处理：采用本地消息表保证订单事件可靠投递；库存消费幂等（基于订单号去重）防止重复扣减；对账任务兜底补偿。
• 超卖风险：Redis预扣 + 分段库存 + 兜底校验，允许极小概率的负库存由人工/自动回滚流程处理。
• 未选方案A：短期成本最低，但无法满足跨境多渠道统一库存的战略需求；未选方案B因强耦合违背拆分初衷。

四、后续演进

• 建设库存对账与监控告警体系；视业务规模评估是否引入库存分库分表；预留向Event Sourcing演进的接口设计。