一、立项背景与目标
立项背景:由于新的SAVE(国药物流供应链云服务平台系统)平台与上游CMS(货主的分销系统)在新疆等特殊地区存在网络中断的风险,同时部分地区的WMS系统不愿意直接接入新的SAVE平台。
系统目标:在完全不改造原有CMS系统的前提下,将CMS-FE作为数据交互代理服务器接管数据的收发工作。系统设计了一个灵活的“路由开关”:网络正常时,将数据发往SAVE平台;断网或需要直连时,关闭开关,直接与WMS-FE(仓库管理系统前置机)进行业务数据交换与反馈,无需平台支撑。此外,系统支持MQSSL等安全传输协议,旨在保障特殊环境下数据通信的稳定与安全。
二、核心业务与功能
系统的核心业务和功能主要划分为四大板块:
1.数据下发功能(CMS-FE->SAVE/WMS-FE)
CMS数据库中的数据变更时,通过触发器将变更数据推至OracleAQ队列,前置机监听后经WebServices(WS)或FTP下发给下游。
基础与单据下发:包括推送商品(货品)、单位(客商及地址)、入库单、出库单以及订单取消数据。
大批量对账包下发:针对库存对账等海量数据,系统通过定时任务分批读取、生成TXT并打包为ZIP,最后经FTP服务上传给下游解析。
2.数据接收与反馈功能(SAVE/WMS-FE->CMS-FE)
系统被动接收下游处理结果,采用“两阶段反馈”机制:阶段一为同步接收下发成功回执;阶段二为下游数据正式落库后异步回传的具体业务结果。
业务反馈接收:包括卡单异常(仅入临时表记日志)、出入库单关单、库存调整反馈。接收报文存入临时表后,异步调用CMS存储过程更新业务数据。
对账结果反馈:通过监听FTP对应目录,下载回传的ZIP对账文件,解压入库并调存储过程完成对账。
串行批量反馈:由于CMS系统不支持高并发操作,系统内置了基于Quartz的串行批量反馈任务(默认每5分钟执行一次),确保数据排队平稳回写。
3.反馈主动查询功能(CMS-FE->SAVE)
除了被动接收反馈,CMS-FE还能主动向SAVE平台发起查询请求(该功能仅SAVE平台提供),实时获取入库单、出库单、库存调整及库存比对的反馈结果。
4.系统配置与后台管理功能
提供基于Web的图形化控制台,保障系统高可用与灵活调度:
开关与路由控制:可一键启停AQ/MQ服务,及切换核心的路由开关(指向SAVE或WMS-FE)。
业务缓冲与错峰:支持配置“商品下发延迟”(缓冲合并修改防下游崩溃)和“反馈接收时间段”(避开CMS日结高峰期错峰反馈)。
异常重发与日志:支持对下发失败数据的手动批量重发及接收失败的延迟重发配置;提供详尽的操作、报文、卡单及对账日志查询,并支持定时自动归档陈旧报文。
一、 设计思路和整体架构
1、CMS-FE的核心定位是作为一个数据交互代理服务器,在不改造原有CMS(货主分销系统)的前提下,接管其数据下发与反馈接收工作。
网络容灾与灵活对接:旨在解决新的SAVE(国药物流供应链云服务平台系统)平台与CMS在特定地区(如新疆)可能出现的断网问题,同时满足部分WMS(仓库管理系统)不愿直连新的SAVE平台的业务需求。灵活的路由开关:系统内置路由开关,网络正常时开启,数据发往SAVE;网络异常或需直连时关闭,直接向WMS-FE发送业务数据。
2、系统的整体架构,主要分为“一出一进”和“灵活部署”:
数据下发(出):CMS数据库内发生业务变更时,通过触发器将数据写入Oracle AQ队列。前置机监听AQ队列,提取数据后经由 Web Services (WS) 或 FTP 发送给下游(SAVE或WMS-FE)。
数据接收(进):前置机接收到下游的业务反馈(如关单、库存同步)后,一律先落入临时反馈表,随后异步调用CMS存储过程来更新CMS的正式业务表(卡单异常等单纯记录日志的除外)。
部署架构:底层基于J2EE容器。不仅支持单台Tomcat的单点部署,还支持Nginx + 多台Tomcat的高可用集群部署,以应对高负载
二、 涉及模块与技术栈
主要模块:数据下发(商品、客商、地址、出入库单、订单取消、对账包等)、数据接收(卡单、关单、库存调整、对账)、反馈查询,以及系统配置控制台(包含路由配置、协议配置、数据手动重发、日志定时归档等)。
技术栈:Java,spring,myBatis,tomcat与Nginx;数据库利用 Oracle (AQ队列、触发器、存储过程);通信协议涵盖 WS(SOA)、MQ和FTP;调度框架使用 Quartz,路由与文件处理使用 Apache Camel;数据格式涉及 XML、JSON、TXT 和 ZIP,。
四、 遇到的难点(坑)与解决方案
1、CMS系统不支持并发操作:
坑:高并发的反馈回传会导致CMS系统处理异常或锁表。
解决方案:反馈过程全部采用独立事务、异步处理,并开发了基于Quartz的“串行批量反馈”功能(默认每5分钟排队批量处理一次),确保数据平稳回写。
2、商品重复下发导致平台压力过大:
坑:CMS下发商品时,同一商品一次会触发两条记录,导致SAVE端接收大量垃圾数据并承受极大压力。
解决方案:增加商品下发延迟时间配置(默认5000毫秒/5秒),通过延迟缓冲来合并与减轻平台压力。
3、‘网络波动造成的数据处理失败或积压:
坑:通信失败导致数据不一致,且大量历史报文会拖慢系统查询性能。
解决方案:针对接收失败,开发了延迟重发机制(默认5分钟后自动重试,可配置次数);针对下发失败,提供了基于Web控制台的手动批量重发功能;同时配置定时任务,每天凌晨2点自动归档3个月前的报文日志以释放空间。