1、项目背景与设计思路
由于货源方与销售平台(ERP)之间数据割裂,订单、库存、运费、售后全靠人工登录双系统操作,效率低且易出错。本项目采用 SaaS 化标准化管理模式,销售平台(1889)作为固定的核心方,深度对接多个货源方(如天马、第三方 ERP),提供专属的配置化接口服务。旨在开发一个纯数据桥接中间件,实现两大系统间的全自动化数据交互,降低人工成本,提升发货准确率和业务响应速度。
2、软件功能、核心功能模块
系统包含四大核心模块:
订单同步:自动拉取销售平台配货中订单,经过库存/余额校验和仓库/货号/尺码映射后,调用货源方 API 下单,并回写运单号至销售平台。
库存同步:定时拉取货源方库存快照,通过 MD5 对比找出变化 SKU,根据鞋类/非鞋类规则转换尺码,按批推送至销售平台并记录日志。
运费同步:同步货源方运费规则,区分自营仓与非自营仓(含快递映射),批量更新销售平台运费策略。
售后同步:实现双向售后同步,定时拉取 1889 售后申请(四阶段:A 申请 / B 状态查询 / C 失败重试 / D 退货快递回传),自动调货源方售后 API 并回写处理结果。
3、业务流程与功能路径
以订单为例,业务路径为:
Hangfire 每 30 秒拉取 1889 订单(Type=3 配货中)
→ 映射仓库、货号、尺码
→ 前置检查(库存 / 余额 / 地址完整性)
→ 调用货源方下单 API 获取运单号
→ 回写销售平台物流信息
异常闭环:若失败则自动重试 3 次,仍失败则转人工,并在订单页展示具体原因,实现全链路异常闭环。由于是单货源方的 SaaS 化统一管理,所有操作均围绕固定货源方的标准接口进行深度优化,无需频繁适配多货源逻辑,大大提升了系统的稳定性与维护效率。
思考过程
项目实现(最终定稿版)
1、整体架构和设计思路
采用前后端分离架构 + 中间件设计模式。后端基于 .NET 8 + SqlSugar ORM 构建高并发的 API 网关和定时任务引擎,使用 Hangfire + Redis 持久化任务队列,保障任务不丢失并支持多 Worker 并发调度(5 个 Worker 实例)。前端采用 Vue 3 + Vite + Element Plus + TypeScript 构建 SaaS 化"配置中心"管理后台,支持非研发人员自助配置(仓库映射、尺码规则、快递映射、预警阈值等),契合"固定单货源方"的统一标准化管理需求。
数据层采用多存储隔离策略:
MySQL 存储核心业务映射数据和配置信息,保证强一致性,含结构化运行日志(integration_log / sync_task_log,按 365 天 retention 自动清理);
Serilog 按天分目录落文件日志(warning / error / fatal),便于回溯排查;
Redis(DB 5) 作为 Hangfire 任务存储和业务缓存,避免与 MySQL 共享时的 InnoDB 锁竞争,同时用于订单去重和热点配置缓存。
该架构设计使系统具备高吞吐、高可用及极佳的可维护性。
2、负责模块和结果
独立负责订单、库存、运费、售后四大同步引擎的架构设计与核心代码编写,并搭建 Vue 可视化配置中心。
订单同步:通过 Hangfire 每 30 秒高效拉取,引入"前置预校验 + 数据库唯一索引幂等去重"机制,实现日均数千单的自动化下单回写,历史订单零重复。
库存同步:基于 MD5 哈希的增量对比机制,将每日对货源方接口的无效请求量降低了 90% 以上。结合尺码转换引擎(区分鞋类 PickNonEuSize 与非鞋类尺码映射),实现库存数据分钟级精准同步。
运费及售后:实现四阶段售后状态机闭环(A 申请 / B 状态查询 / C 失败重试 / D 退货快递回传),售后自动处理率达 95% 以上。
管理效率:通过 SaaS 化可视化配置管理页面,将以往需开发写代码改配置的操作,变为运营人员鼠标点击即可完成,配置调整效率提升 80% 以上,且配置变更通过"刷新缓存"即时生效,无需重新部署。
3、难点、坑与解决方案
难点一:复杂易变的数据映射(尺码/仓库/快递)。货源方与销售平台编码体系完全不同,易发生映射错乱。解决方案:设计基于单货源 SaaS 化的多级映射表结构(sys_goods_mapping、sys_express_mapping、sys_warehouse_mapping 等),前端配置后台支持级联选择 + 校验,后端使用 MD5 对比变化数据只推送变更项,从根源遏制数据风暴。同时将货源方专属逻辑(如天马尺码转换)封装在专属 Servi