文末时序图与重构前后对比图需要科学上网才能流畅查看，图床直接用了 GitHub。

一、为什么要做业务上浮（收拢到 WES）？

早期 WES 的单据调度逻辑都在 WCS 服务里，但这样的领域划分其实存在一些问题：

  1. WCS 的业务领域应该是车辆调度相关的，不应该涉及到单据调度的业务。

  2. WCS 的代码与单据调度的代码都在一个服务里，两个团队开发起来，会互相影响发版。

  3. WCS 代码量 40 多万行，代码复杂度高，单据调度的代码如果抽出去，能减少 WCS 的代码复杂度，提升编译和启动速度。

二、业务上浮的规划

2.8 版本和 2.9 版本下游硬件和车辆调度集群都是不兼容的，WES 也不要求做兼容设计，所以总体的可操作度会大许多。

原先 WES 内部存在理货单与理货作业单，WES 生成理货单后，将 WES 的理货单通过Feign 接口同步到 WCS，WCS 通过一些定时任务根据商品库存状况将理货单生成理货作业单，再生成理货下架与上架任务，最终将任务流转到WCS 的搬运层相关状态，分车、顶升、搬运到工作站。

先确定一下 WES 和 WCS 负责的业务领域：

WES: 商品、批次、包装、库存、单据（出库、入库、盘点、理货）……

WCS: 车辆、路径、地图……

所以我们可以把库存、单据调度相关的都上浮到 WES，改造内容具体包括：

  1. 数据表迁移

  2. 代码迁移

  3. WES 与 WCS 的任务对接格式

三、数据表迁移

以货架到人理货业务为例，涉及到的表包括：

  1. 理货单

  2. 理货作业单（上架、下架共用）

  3. 理货作业单明细

  4. 理货作业单状态变更表

  5. 理货任务表

  6. 任务转态变更表

因为是跨版本升级，会重新开仓，所以这次升级无需考虑数据迁移的问题，直接迁移表结构就行，从 WCS 迁移至 WES 的库中。

四、代码迁移

4.1 理货作业单同步接口

WCS 接口废弃，测试完成后，相关代码删除

4.2 定时器迁移

主要涉及到以下几个定时器：

  • 计算并生成理货作业单定时器

  • 计算理货待下架库位，创建下架任务定时器

  • 计算理货待上架库位，创建上架任务定时器

4.3 搬运信息推送逻辑

主要涉及：

  • 货架搬运状态信息上报：顶升、开始搬运以及距离相关信息

  • 实操推送逻辑：WES 收到到站 MQ 消息，WES 记录到站信息，并按业务分类推送实操到工作站，更新任务信息。

4.4 MQ 消息监听

主要涉及：

  • 工作站下线消息监听

  • 理货下架实操反馈消息监听

  • 理货上架实操反馈消息监听

五、WES 与 WCS 的任务对接格式

使用 Feign 接口下发理货下架、上架任务。

不过这样的话就需要增加一个任务状态——WAITING_WCS：代表这个任务在 WES 的前置流程已经处理完毕，等待 WCS 调度搬运车辆。

六、业务上浮后系统数据链路时序图

业务上浮后系统数据链路时序图

七、DDD 视角下的重构前后对比

从 DDD 的角度分析，虽然我们没有用 DDD~

DDD 视角下的重构前后对比图