一、一个被低估的事实WMS拆错的代价比不拆更大从单体WMS拆到微服务最常见的翻车方式不是“拆得太少”而是拆出了分布式单体——服务数量上去了数据所有权却还是乱的。入库服务直接改库存表出库服务绕过库存服务扣减波次服务自己读订单库拼接拣货任务。结果是服务独立部署了但一个入库逻辑的慢查询仍然能让出库、波次、PDA扫码全部卡死因为它们共享同一个数据库连接池。拆分WMS的第一原则不是“越细越好”而是先按作业域划清数据所有权再按流量特征决定部署粒度。谁的数据谁做主是后续所有高并发、最终一致性方案能够成立的前提。二、拆分边界四个核心服务一条“记录系统”红线2.1 按作业域拆分而不是按页面拆分一个可落地的WMS微服务骨架按作业域而非页面来划分服务职责数据所有权基础数据服务货品、库位、供应商等静态数据唯一持有者库存服务库存扣减、冻结、调拨库存的唯一记录系统出入库服务收货、上架、拣货、复核、出库单据单据数据的持有者波次服务订单池管理、波次生成、任务分派波次与任务数据的持有者入库、出库、库存、波次如果全在一个工程里共用一个发布窗口改动一行入库校验逻辑就要全量回归出库模块在高峰期压力爆表却无法单独扩容这是拆分的第一驱动力。2.2 红线库存的“记录系统”永远是库存服务拆分后的边界可以用一条红线概括出库服务可以“发起冻结请求”但不能直接修改库存表入库服务可以“发起增加可用量的请求”但不能绕过库存服务写库存。单体时代的Controller往往把库存冻结和出库单创建串在一个方法里直接依赖多个本地Servicejava// 单体一个方法里串了库存和出库 PostMapping(/outbound/create) public String createOutbound(RequestBody OutboundOrder order) { inventoryService.freezeStock(order.getSku(), order.getQty()); outboundService.createOrder(order); return OK; }拆分后库存冻结归属于库存服务出库单创建归属于出库服务java// 库存服务只负责库存冻结不关心出库单 RestController RequestMapping(/inventory) public class InventoryController { PostMapping(/freeze) public FreezeResult freeze(RequestBody FreezeRequest request) { // 冻结逻辑含幂等键校验 return inventoryService.freeze(request); } }这条红线的工程含义是任何涉及库存变动的操作必须经过库存服务的统一入口由它来做幂等、状态校验和并发控制。如果允许其他服务直写库存表库存服务内部的锁和状态机就形同虚设。三、库存高并发Redis预扣减 状态机 对账兜底3.1 为什么不能直接扣数据库WMS的库存扣减是最高频、最敏感的操作。大促或直播场景下多个订单同时对同一个SKU发起扣减直接走数据库行锁会迅速把连接池打满如果扣减逻辑没有原子性保证库存可能在并发中被扣成负数。方案是三层协同Redis原子预扣减在入口扛住并发状态机约束业务流转异步落库 对账兜底最终一致性。3.2 Redis Lua判断和扣减必须原子预扣减在Redis中用Lua脚本执行保证“检查扣减”是一个原子操作同时用幂等键防止重复扣减lua-- KEYS[1]: 库存keyskuId:warehouseId -- ARGV[1]: 扣减数量 -- ARGV[2]: 幂等键 local stock tonumber(redis.call(GET, KEYS[1])) if stock nil then return -1 end local deduct tonumber(ARGV[1]) if stock deduct then redis.call(DECRBY, KEYS[1], deduct) redis.call(SET, idem: .. ARGV[2], 1, EX, 86400) return stock - deduct else return -2 end预扣减成功后异步投递消息更新数据库物理库存。Redis扛住入口并发数据库只承担最终落库的串行压力。3.3 状态机让库存变动“有据可依”库存数字本身没有意义背后的业务状态才决定它能不能被操作。库存需要维护显式状态机待拣货 → 拣货中 → 已出库以及订单取消时的已取消 → 释放库存。状态机和扣减动作绑定一个已经进入终态的库存记录不可能再次被冻结从状态层面杜绝重复操作。四、波次与库存的边界波次服务只消费“已预扣”的库存波次生成不能只看订单池必须校验库存可用性。但波次服务不直接扣库存——它只消费库存服务已经预扣成功的库存。一个订单被纳入波次时其所需SKU必须在目标库位有足够的已预扣量否则波次生成后拣货员到库位发现无货会造成无效行走和任务重排。这个边界模糊时最常见的错误是波次服务为了“快”自己读库存表判断可用量然后生成波次——结果是波次生成时“可用”实际拣货时被其他订单抢走了。波次的可信度依赖于库存服务预扣的原子性而不是波次服务自己查询的结果。五、分布式一致性不追求强一致但必须最终一致微服务拆分后库存预扣减和出库单创建跨服务本地事务无法覆盖。务实的路径是BASE 最终一致性预扣减成功后发送消息到Kafka出库服务和库存落库服务各自消费消息携带幂等键做去重对于必须保证“业务动作消息发送”原子性的场景使用本地消息表兜底每日对账比对Redis预扣量、数据库扣减量和履约完成量差异进入补偿队列。分布式事务不必在所有环节硬上Seata AT。AT模式依赖全局锁本质是用强一致性换吞吐量。WMS中真正需要强一致的范围很小大部分库存扣减场景可以用“预扣减异步消息对账”做到最终一致。六、避坑指南坑1按页面拆服务而不是按作业域拆。拆出了“收货页面服务”“上架页面服务”“拣货页面服务”结果每个服务都直接读写库存表库存一致性彻底失控。拆分边界必须按数据所有权划而不是按UI页面划。坑2库存预扣减成功但出库单创建失败库存不回补。预扣流水记录了订单号但释放逻辑只在“取消订单”时触发没有覆盖“预扣成功、出库单创建异常”的路径。预扣必须与出库单创建在同一个业务动作的补偿范围内或者由对账任务识别“有预占、无单据”的孤儿记录并自动释放。坑3波次服务自己判断库存可用性。波次服务读库存表生成波次但库存表的数据可能已经被其他订单预扣而尚未落库导致波次生成后拣货无货。波次只能消费库存服务已确认的预扣结果不能自行查询判断。七、总结WMS微服务拆分的第一优先级不是“拆多少服务”而是先划清“谁的数据谁做主”的红线。库存的“记录系统”只有一个其他服务可以申请、可以消费但不能直写。库存高并发靠Redis原子预扣减扛入口状态机约束业务流转对账兜底最终一致性。波次服务只消费已预扣的库存不越界判断。分布式一致性不追求全链路强一致用本地消息表和对账在关键路径上兜底。下一篇预告服务边界划清之后下一个问题是“入口怎么防”。明天聊物流网关设计——多平台接入、统一鉴权与限流降级的工程实现。 本文作者深圳Eyf•半字节科技▪技术产品团队 物流、快递、快运作业管理系统让每一票都清晰可控。从任务分配到签收回传一站式管理每个作业环节。
一、一个被低估的事实WMS拆错的代价比不拆更大从单体WMS拆到微服务最常见的翻车方式不是“拆得太少”而是拆出了分布式单体——服务数量上去了数据所有权却还是乱的。入库服务直接改库存表出库服务绕过库存服务扣减波次服务自己读订单库拼接拣货任务。结果是服务独立部署了但一个入库逻辑的慢查询仍然能让出库、波次、PDA扫码全部卡死因为它们共享同一个数据库连接池。拆分WMS的第一原则不是“越细越好”而是先按作业域划清数据所有权再按流量特征决定部署粒度。谁的数据谁做主是后续所有高并发、最终一致性方案能够成立的前提。二、拆分边界四个核心服务一条“记录系统”红线2.1 按作业域拆分而不是按页面拆分一个可落地的WMS微服务骨架按作业域而非页面来划分服务职责数据所有权基础数据服务货品、库位、供应商等静态数据唯一持有者库存服务库存扣减、冻结、调拨库存的唯一记录系统出入库服务收货、上架、拣货、复核、出库单据单据数据的持有者波次服务订单池管理、波次生成、任务分派波次与任务数据的持有者入库、出库、库存、波次如果全在一个工程里共用一个发布窗口改动一行入库校验逻辑就要全量回归出库模块在高峰期压力爆表却无法单独扩容这是拆分的第一驱动力。2.2 红线库存的“记录系统”永远是库存服务拆分后的边界可以用一条红线概括出库服务可以“发起冻结请求”但不能直接修改库存表入库服务可以“发起增加可用量的请求”但不能绕过库存服务写库存。单体时代的Controller往往把库存冻结和出库单创建串在一个方法里直接依赖多个本地Servicejava// 单体一个方法里串了库存和出库 PostMapping(/outbound/create) public String createOutbound(RequestBody OutboundOrder order) { inventoryService.freezeStock(order.getSku(), order.getQty()); outboundService.createOrder(order); return OK; }拆分后库存冻结归属于库存服务出库单创建归属于出库服务java// 库存服务只负责库存冻结不关心出库单 RestController RequestMapping(/inventory) public class InventoryController { PostMapping(/freeze) public FreezeResult freeze(RequestBody FreezeRequest request) { // 冻结逻辑含幂等键校验 return inventoryService.freeze(request); } }这条红线的工程含义是任何涉及库存变动的操作必须经过库存服务的统一入口由它来做幂等、状态校验和并发控制。如果允许其他服务直写库存表库存服务内部的锁和状态机就形同虚设。三、库存高并发Redis预扣减 状态机 对账兜底3.1 为什么不能直接扣数据库WMS的库存扣减是最高频、最敏感的操作。大促或直播场景下多个订单同时对同一个SKU发起扣减直接走数据库行锁会迅速把连接池打满如果扣减逻辑没有原子性保证库存可能在并发中被扣成负数。方案是三层协同Redis原子预扣减在入口扛住并发状态机约束业务流转异步落库 对账兜底最终一致性。3.2 Redis Lua判断和扣减必须原子预扣减在Redis中用Lua脚本执行保证“检查扣减”是一个原子操作同时用幂等键防止重复扣减lua-- KEYS[1]: 库存keyskuId:warehouseId -- ARGV[1]: 扣减数量 -- ARGV[2]: 幂等键 local stock tonumber(redis.call(GET, KEYS[1])) if stock nil then return -1 end local deduct tonumber(ARGV[1]) if stock deduct then redis.call(DECRBY, KEYS[1], deduct) redis.call(SET, idem: .. ARGV[2], 1, EX, 86400) return stock - deduct else return -2 end预扣减成功后异步投递消息更新数据库物理库存。Redis扛住入口并发数据库只承担最终落库的串行压力。3.3 状态机让库存变动“有据可依”库存数字本身没有意义背后的业务状态才决定它能不能被操作。库存需要维护显式状态机待拣货 → 拣货中 → 已出库以及订单取消时的已取消 → 释放库存。状态机和扣减动作绑定一个已经进入终态的库存记录不可能再次被冻结从状态层面杜绝重复操作。四、波次与库存的边界波次服务只消费“已预扣”的库存波次生成不能只看订单池必须校验库存可用性。但波次服务不直接扣库存——它只消费库存服务已经预扣成功的库存。一个订单被纳入波次时其所需SKU必须在目标库位有足够的已预扣量否则波次生成后拣货员到库位发现无货会造成无效行走和任务重排。这个边界模糊时最常见的错误是波次服务为了“快”自己读库存表判断可用量然后生成波次——结果是波次生成时“可用”实际拣货时被其他订单抢走了。波次的可信度依赖于库存服务预扣的原子性而不是波次服务自己查询的结果。五、分布式一致性不追求强一致但必须最终一致微服务拆分后库存预扣减和出库单创建跨服务本地事务无法覆盖。务实的路径是BASE 最终一致性预扣减成功后发送消息到Kafka出库服务和库存落库服务各自消费消息携带幂等键做去重对于必须保证“业务动作消息发送”原子性的场景使用本地消息表兜底每日对账比对Redis预扣量、数据库扣减量和履约完成量差异进入补偿队列。分布式事务不必在所有环节硬上Seata AT。AT模式依赖全局锁本质是用强一致性换吞吐量。WMS中真正需要强一致的范围很小大部分库存扣减场景可以用“预扣减异步消息对账”做到最终一致。六、避坑指南坑1按页面拆服务而不是按作业域拆。拆出了“收货页面服务”“上架页面服务”“拣货页面服务”结果每个服务都直接读写库存表库存一致性彻底失控。拆分边界必须按数据所有权划而不是按UI页面划。坑2库存预扣减成功但出库单创建失败库存不回补。预扣流水记录了订单号但释放逻辑只在“取消订单”时触发没有覆盖“预扣成功、出库单创建异常”的路径。预扣必须与出库单创建在同一个业务动作的补偿范围内或者由对账任务识别“有预占、无单据”的孤儿记录并自动释放。坑3波次服务自己判断库存可用性。波次服务读库存表生成波次但库存表的数据可能已经被其他订单预扣而尚未落库导致波次生成后拣货无货。波次只能消费库存服务已确认的预扣结果不能自行查询判断。七、总结WMS微服务拆分的第一优先级不是“拆多少服务”而是先划清“谁的数据谁做主”的红线。库存的“记录系统”只有一个其他服务可以申请、可以消费但不能直写。库存高并发靠Redis原子预扣减扛入口状态机约束业务流转对账兜底最终一致性。波次服务只消费已预扣的库存不越界判断。分布式一致性不追求全链路强一致用本地消息表和对账在关键路径上兜底。下一篇预告服务边界划清之后下一个问题是“入口怎么防”。明天聊物流网关设计——多平台接入、统一鉴权与限流降级的工程实现。 本文作者深圳Eyf•半字节科技▪技术产品团队 物流、快递、快运作业管理系统让每一票都清晰可控。从任务分配到签收回传一站式管理每个作业环节。
