微服务系列(二) 微服务拆分不是拍脑袋-WMS怎么拆

微服务拆分不是拍脑袋WMS 怎么拆用 DDD 给仓储系统划边界我们踩过的弯路第一次拆分的翻车经历说实话我第一次拆微服务的时候自信满满。那时候公司有个单体 WMS仓储管理系统代码量大概 15 万行团队 20 多个人。每次发版都像在拆炸弹——你改了一个入库单的字段测试同学要把出库、盘点、报表全跑一遍生怕哪里连带崩了。老板拍板拆必须拆成微服务我当时想这还不简单微服务嘛就是把代码拆开部署。于是我大手一挥按技术层拆wms-controller-service放所有 Controller负责接 HTTP 请求wms-service-service放所有 Service负责业务逻辑wms-dao-service放所有 DAO 和数据库交互拆完之后我还挺得意看多清晰标准的 MVC 三层架构各管各的结果呢上线第一天就炸了。有个最简单的场景用户想查一个入库单的详情。这个请求先到 controller-servicecontroller-service 调 service-serviceservice-service 再调 dao-service。一个查询跨了 3 个服务走了 4 次网络调用。latency 从原来的 20ms 飙到了 400ms高峰期直接超时。更离谱的是有一次 dao-service 挂了controller-service 和 service-service 跟着全挂。本来是想解耦的结果耦合得更深了——只不过从代码层面的耦合变成了网络层面的耦合。那天晚上我和运维老哥一起 rollback 到单体版本凌晨三点才下班。路上我就在想微服务拆分到底该怎么拆后来我读到一句话醍醐灌顶微服务拆分的第一原则——按业务领域拆不是按技术层拆。说白了如果你按技术层拆只是把原来的一个应用变成了三个应用业务逻辑还是缠在一起的。真正该拆的是业务边界。这就引出了我们今天的主角DDD领域驱动设计。DDD 领域分析WMS 的五大核心域DDD 听起来很高大上其实核心思想就一句话先搞清楚业务里有哪些域再按域的边界拆服务。咱们以 WMS 为例跟业务专家也就是仓库的老大哥们聊了几轮之后我们梳理出了五大核心域。1. 入库域Inbound这个域管的是货怎么进来。核心流程收货 → 质检 → 上架。核心实体大概长这样// 入库域的核心实体classInboundOrder{StringorderNo;// 入库单号StringownerCode;// 货主编码引用基础资料ListInboundDetaildetails;InboundStatusstatus;// 待收货、收货中、质检中、已上架、已关闭}classInboundDetail{StringskuCode;// 商品编码BigDecimalqty;// 计划入库数量BigDecimalreceivedQty;// 已收货数量BigDecimalqualifiedQty;// 质检合格数量}边界说明入库域只关心货从到仓到上架这件事。它不需要知道库存最终有多少那是库存域的事。它只需要在质检完成、上架之后给库存域发一个事件“这批货已上架你记一下。”2. 出库域Outbound这个域管的是货怎么出去。核心流程波次分配 → 拣货 → 复核 → 打包 → 发货。// 出库域的核心实体classOutboundOrder{StringorderNo;StringownerCode;ListOutboundDetaildetails;OutboundStatusstatus;// 待分配、待拣货、拣货中、待复核、待打包、已发货}classWave{StringwaveNo;// 波次号ListStringorderNos;// 包含的出库单PickStrategystrategy;// 拣货策略按单拣、边拣边分、先拣后分}边界说明出库域的核心是让订单高效、准确地发出去。它会在拣货时向库存域查询可用库存在发货时通知库存域扣减库存。但它不维护库存余额只消费库存域的接口。3. 库存域Inventory这是 WMS 里最核心、也最敏感的域。核心职责库存记录、库存变动、库存冻结/释放。// 库存域的核心实体classInventory{StringwarehouseCode;StringownerCode;StringskuCode;StringlocationCode;// 库位编码BigDecimalqty;// 可用库存BigDecimalfrozenQty;// 冻结库存BigDecimallockedQty;// 锁定库存已被波次占用}classInventoryTransaction{StringbizNo;// 业务单号入库单/出库单/盘点单TransactionTypetype;// 入库增加、出库扣减、盘点调整、移库BigDecimalbeforeQty;BigDecimalafterQty;BigDecimaldeltaQty;}边界说明库存域是唯一的事实来源Single Source of Truth。任何域想改库存都必须通过库存域的接口。入库域说上架了库存域就加出库域说发货了库存域就扣库内作业域说盘亏了库存域就调。4. 库内作业域Internal这个域管的是仓库里不进货也不出货的日常操作。核心流程盘点、移库、补货、加工。// 库内作业域的核心实体classStockTakeOrder{StringorderNo;StockTakeTypetype;// 全盘、循环盘、动碰盘ListStockTakeDetaildetails;}classStockTakeDetail{StringlocationCode;StringskuCode;BigDecimalsystemQty;// 系统库存从库存域查询BigDecimalactualQty;// 实盘数量BigDecimaldiffQty;// 差异 实盘 - 系统}classMoveOrder{StringorderNo;StringfromLocation;StringtoLocation;StringskuCode;BigDecimalqty;}边界说明库内作业域会读取库存域的数据比如盘点时查系统库存也会产生库存变动盘点调整、移库。但和入库、出库不同的是库内作业不跟外部货主直接打交道它是仓库内部的自我管理。5. 基础资料域Master Data这个域是后勤部给其他所有域提供基础数据。核心实体商品SKU、货主Owner、仓库Warehouse、库位Location、承运商Carrier。// 基础资料域的核心实体classSku{StringskuCode;StringskuName;StringownerCode;Stringbarcode;BigDecimalweight;BigDecimalvolume;BooleanisFragile;// 是否易碎BooleanisColdChain;// 是否冷链}classLocation{StringwarehouseCode;StringlocationCode;LocationTypetype;// 拣货位、存储位、退货位、不良品位BigDecimalmaxWeight;BigDecimalmaxVolume;}边界说明基础资料域的数据相对静态变更频率低但读取频率极高。入库域要查 SKU 信息出库域要查库位信息库存域也要查。这个域的关键是接口稳定——一旦接口变了下游全得跟着改。边界划分的实战技巧光知道五大域还不够真正落地的时候你会发现很多灰色地带。比如入库单里要不要带 SKU 名称如果带是不是耦合了基础资料域库存变动日志该放在库存域还是单独拆一个库存日志服务报表该跟谁放在一起这些问题我们当时争论了很久。后来总结出了三个实战技巧分享给大家。技巧 1看数据归属——谁创建谁负责这是划分边界最朴素也最有效的一条规则。入库单是谁创建的入库域创建的那入库单的数据模型、生命周期、状态机都由入库域负责。SKU 是谁创建的基础资料域创建的SKU 的增删改查归基础资料域管。库存余额是谁创建的库存域创建的任何其他域只能用不能直接改。问题来了入库域展示入库单详情时需要显示 SKU 名称怎么办我们的做法是入库单里只存skuCode不存skuName。展示的时候前端分别调入库域和基础资料域的接口自己组装。或者由 BFFBackend for Frontend层去组装。这样做的好处是基础资料域改了 SKU 名称不需要通知入库域去同步。数据归属清晰边界就清晰。技巧 2看变更频率——高频变更的模块独立出来不同业务模块的变更频率差别很大。如果把它俩硬塞在一个服务里会互相拖累发版节奏。以 WMS 为例库存域几乎每天都在改今天加个冻结逻辑明天优化个锁库存性能后天对接一个新的电商平台。基础资料域一个月可能改不了一次SKU 新增都是运营在后台批量导入的。如果把库存和基础资料放一个服务里库存域每次发版都要带着基础资料域一起测、一起部署风险大、效率低。所以必须拆开。再举个例子报表模块需求变化极快老板今天想看这个维度明天想看那个维度后天要导出 Excel。核心作业模块出库流程一旦稳定不能轻易改动。所以报表一定要单独拆一个服务甚至单独一个数据库。报表查得慢、跑挂了都不能影响核心出库流程。技巧 3看团队边界——一个服务最好对应一个 2-pizza 团队亚马逊有个著名的2-pizza 团队原则一个团队的人数不能超过两张披萨能喂饱的规模大概 6-10 个人。这个原则在微服务拆分里特别有用一个服务最好由一个团队全权负责。我们当时有 20 多个人如果拆 5 个服务正好每个服务配 4-5 个人有点少如果拆 3 个服务每个服务 7-8 个人比较舒服。但注意不要为了凑团队人数而强行合并域。比如你把入库域和出库域合并成一个收发服务看起来团队规模合适了但入库和出库的业务逻辑差异很大一个团队很难同时精通两边最后变成谁都不敢大改。我们的折中方案是拆 6 个服务其中库存域团队 8 个人因为最核心、最复杂其他域各 3-4 个人基础资料域 2 个人就够了。我们最终的拆分方案聊了半天直接上图看看我们最后是怎么拆的。┌─────────────────────────────────────────────────────────────┐ │ 网关层 (Gateway) │ │ 统一鉴权、路由、限流、日志 │ └─────────────────────────────────────────────────────────────┘ ↓ ┌─────────────────────────────────────────────────────────────┐ │ BFF / 前端适配层 │ │ 组装数据、适配不同端PC、PDA、大屏 │ └─────────────────────────────────────────────────────────────┘ ↓ ↓ ↓ ↓ ↓ ┌─────────┐ ┌─────────┐ ┌─────────┐ ┌─────────┐ ┌─────────┐ │ 入库服务 │ │ 出库服务 │ │ 库存服务 │ │ 库内服务 │ │ 基础资料 │ │ Inbound │ │ Outbound│ │Inventory│ │ Internal│ │ Master │ │ Service │ │ Service │ │ Service │ │ Service │ │ Service │ └────┬────┘ └────┬────┘ └────┬────┘ └────┬────┘ └────┬────┘ │ │ │ │ │ └────────────┴────────────┴────────────┴────────────┘ ↓ ┌─────────────────┐ │ 消息队列 MQ │ │ (RocketMQ) │ └─────────────────┘ ↓ ┌─────────────────┐ │ 报表服务 │ │ Report Service │ └─────────────────┘为什么报表单独拆报表有几个特点查询重、计算重一个大盘报表可能要扫几百万条记录做聚合、分组、排序。数据来源杂要同时查入库、出库、库存、库内各个域的数据。变更频繁老板的需求你懂的今天加个字段明天换个图表。如果把报表逻辑塞在库存服务或者出库服务里轻则拖慢核心接口重则把核心服务搞挂。所以报表必须独立甚至可以用单独的数据库通过 MQ 同步各域数据用 OLAP 引擎来跑。为什么库存不能拆太细有人可能会问库存域那么大能不能再拆比如拆成可用库存服务、“冻结库存服务”、“库存流水服务”我们一开始也想过这么拆但后来放弃了。原因是库存的核心是强一致性。一次出库操作要同时扣减可用库存、增加锁定库存、记录库存流水。如果把这三件事拆成三个服务就要引入分布式事务复杂度指数级上升。而且可用库存、冻结库存、锁定库存本质上都是同一张核心表的不同字段。拆得太细数据库层面还是耦合的没什么意义。我们的结论是库存域内部可以按模块分层比如分成库存查询模块、库存变动模块、库存冻结模块但对外还是一个服务。服务间调用关系伪代码// 场景用户下了一个出库单系统要分配库存并创建波次// Step 1: 出库服务接收请求创建出库单outboundService.createOrder(request);// Step 2: 出库服务调用库存服务锁定库存// 关键这里只传 skuCode 和 qty不耦合库存的内部实现LockResultresultinventoryService.lockStock(newLockRequest(skuCode,qty,outboundOrderNo));// Step 3: 如果库存不足返回错误如果锁定成功创建波次if(result.isSuccess()){waveService.createWave(outboundOrderNo);// 发送事件波次已创建mqProducer.send(newWaveCreatedEvent(outboundOrderNo));}else{thrownewBizException(库存不足无法分配);}// Step 4: 库内服务监听 WaveCreatedEvent生成拣货任务RocketMQMessageListener(topicwms-wave-topic)classPickTaskConsumer{voidonMessage(WaveCreatedEventevent){internalService.createPickTask(event.getOrderNo());}}// Step 5: 拣货完成后出库服务调用库存服务扣减库存并释放锁定inventoryService.deductAndUnlock(newDeductRequest(skuCode,qty,outboundOrderNo));// Step 6: 库存变动后发送事件给报表服务同步数据mqProducer.send(newInventoryChangedEvent(...));关键点同步调用OpenFeign只用在强依赖、必须立即知道结果的场景比如锁库存。异步调用MQ用在最终一致、可以延迟处理的场景比如生成拣货任务、同步报表数据。每个服务只暴露最小化、稳定的接口内部实现对外不可见。拆分 checklist这三个问题必须想清楚拆微服务不是目的目的是让系统更好维护、更好扩展。拆之前建议用下面这个 checklist 自检一下1. 数据是否高度内聚一个服务里的数据应该由这个服务自己创建、自己维护、自己负责一致性。如果某个表被三个服务同时读写那说明边界还没划清楚。2. 对外接口是否稳定微服务之间的接口就是契约一旦定了不能轻易变。如果你的接口三天两头改下游服务会崩溃的。基础资料域尤其要注意这一点。3. 能否独立部署、独立扩展这是微服务最核心的价值。大促时出库量暴增你可以只扩容出库服务报表跑得太慢你可以单独给报表服务加机器。如果拆完之后几个服务还是必须一起打包、一起部署那说明拆了个寂寞。写在最后微服务拆分没有标准答案但有一些明确的错误答案——比如按技术层拆。我们第一次拆 WMS 的时候走了不少弯路。按技术层拆完又 rollback按功能拆得太细又合并反复折腾了两三个月才找到现在的方案。回过头看我觉得最重要的收获不是拆成了几个服务而是整个团队对业务领域有了更深的理解。DDD 的价值很多时候体现在大家一起画边界图、一起讨论数据归属的过程中。当然微服务也不是银弹。如果你的团队不到 10 个人系统日活不到一万单体应用可能更香。别为了拆而拆合适的架构才是最好的架构。你们团队在微服务拆分的时候踩过哪些坑是按业务域拆的还是按技术层拆的WMS 或者其他业务系统你有什么更好的拆分思路欢迎在评论区交流咱们一起进步