4. 追溯系统技术架构与集成模式

追溯系统能否真正落地，关键不在于追溯页面做得多漂亮，而在于底层架构选得对不对、MES 与追溯平台之间的数据通道是否可靠。本节围绕三个问题展开：追溯数据放在哪里（集中式与分布式架构）、系统之间怎么连（ESB、API、消息队列）、以及食品 MES 与追溯平台之间到底传什么数据、按什么顺序传。

一、集中式与分布式追溯架构的选择

集中式追溯架构是在集团或总部部署一套统一的追溯平台和数据库，各工厂的 MES、WMS、称重设备通过接口把批次、工序、检验、出入库数据上报到中心库，追溯查询、召回分析、报表统计都在中心完成。它的优点是数据口径统一、跨工厂追溯链路完整、召回时一次查询即可覆盖全部分厂；缺点是中心库压力大、网络依赖强，工厂断网时上报会中断，且不同工厂的工艺差异需要在中心侧做较多适配。

分布式追溯架构是每个工厂部署本地追溯节点（本地库＋本地服务），MES 就近写入本地节点，本地即可完成单厂追溯；总部通过数据同步或联邦查询获取汇总视图。它的优点是响应快、断网可降级运行、工厂自治度高；缺点是跨厂追溯需要拼接多个节点数据，主数据（物料、供应商、编码规则）容易不一致，同步延迟会导致总部视图滞后。

实际工程中更常见的是混合模式：主数据与编码规则集中管理，业务追溯数据本地存储、异步汇总。判断依据可以归纳为三条：一是监管与客户是否要求跨厂一键追溯；二是工厂网络稳定性与断网容忍时长；三是批次数据量级——日批次记录超过十万条时，中心库的写入与查询压力需要提前评估。食品行业还需特别注意保质期与召回时效要求，若法规要求 2 小时内完成批次流向定位，纯分布式拼接往往难以满足，通常需要在中心侧保留一份关键流向索引。

二、ESB、API 与消息队列的集成方式

ESB（企业服务总线）适合系统异构程度高、协议繁杂的场景。例如老厂 MES 只提供 SOAP 接口或数据库中间表，追溯平台要求 JSON 报文，ESB 负责协议转换、报文映射、路由分发和调用审计。它的价值在于把“点对点蜘蛛网”收敛为“星型总线”，但配置重、链路长，单个事件延迟通常在百毫秒到秒级，且总线本身成为单点，需要高可用部署。

REST API适合同步交互：追溯平台向 MES 查询某工单的投料明细、下发物料主数据与编码规则、校验批次号是否已存在。设计要点是接口幂等（用业务单号做幂等键）、分页查询避免大结果集、明确超时与重试策略。API 不适合高频事件推送，否则 MES 会被大量回调拖慢生产业务。

消息队列适合异步事件流：MES 在投料、工序完成、包装赋码、入库等节点发布事件，追溯平台订阅消费。它天然削峰、支持多消费者（追溯、看板、质量分析同时订阅同一事件）、消费失败可重入队。工程上必须保证至少一次投递＋消费端幂等，否则重复消费会造成批次关联重复计数。食品工厂常见的做法是：主数据走 API 同步，业务事件走消息队列，跨系统对账与异常补偿走 ESB 或定时任务。

三、食品 MES 与追溯平台的数据流设计

数据流设计的核心是确定“哪些数据在哪个节点产生、以什么粒度、按什么顺序进入追溯平台”。以乳品灌装线为例（以下参数为教学示例）：工单 WO-20240513-007 下达后，MES 记录计划产量 24000 包；投料环节扫描原料批次 RM-240510-A12（生乳）与 RM-240511-B03（菌种），形成“工单—原料批次”绑定关系；杀菌工序上报温度 137℃、保持 4s；灌装工序按包生成唯一码并汇总为箱码 CS-0001，每 24 箱组成托盘码 PL-0001；入库事件携带库位与生产日期；发货事件携带经销商与目的地。

追溯平台消费这些事件后，建立三层关联：批次层（原料批次→半成品批次→成品批次）、包装层（包码→箱码→托码）、流向层（托码→发货单→经销商）。当发生质量异常时，输入一个包码即可向上追溯到原料批次与杀菌参数，向下追溯到同托、同发货单的全部产品，从而界定召回范围。

设计时需重点处理三类问题：一是时序错乱，包装赋码事件可能早于工序完成事件到达，消费端应按事件时间而非到达时间排序，或允许后到事件补全关联；二是主数据不一致，物料编码必须在 MES 与追溯平台间由同一主数据源下发，禁止两边各自建码；三是断网补偿，MES 本地应缓存未确认事件，恢复后按原顺序重投，追溯平台以事件 ID 去重。建议在集成初期就建立对账机制：每日按工单核对 MES 侧成品数量与追溯平台已关联码数量，差异超过阈值即告警，这比事后排查召回缺口要经济得多。