3. 追溯系统技术架构：整体架构设计原则、分层架构与数据流设计

追溯系统能不能落地，技术架构是骨架。骨架歪了，后面再怎么填肉都别扭。我这些年见过不少项目，业务需求梳理得挺好，一上线就卡死，十有八九是架构设计时埋了雷。

这一章，咱们把技术架构拆开揉碎了讲。不扯虚的，全是实战里摸出来的经验。

3.1 整体架构设计原则：先想清楚再动手

设计架构前，先问自己三个问题：数据从哪来？数据到哪去？系统扛不扛得住？想明白了，原则自然就出来了。

我个人习惯，架构设计必须遵守以下四条铁律：

• 高可用：产线不能停。追溯系统挂了，生产得照常跑。数据先本地缓存，等系统恢复再补传。
• 可扩展：今天管一条线，明天扩到十条。架构不能推倒重来。模块化、微服务化是基本盘。
• 实时性：工序节拍以秒计。数据采集延迟超过5秒，操作工就骂娘。边缘计算是标配。
• 数据一致性：追溯链断了，整批产品都得报废。分布式事务、最终一致性方案必须提前设计。

我曾经在一个项目里，客户非要上全实时同步架构。结果产线震动大，网络闪断频繁，数据经常写一半就丢了。后来改成「边缘缓存+异步补偿」模式，问题才解决。嗯，这里要注意：别迷信实时，稳定比快更重要。

3.2 分层架构：设备层、执行层、应用层

追溯系统我习惯分三层：设备层、执行层、应用层。每层各司其职，层与层之间通过标准接口通信。你想想看，这样设计的好处是什么？解耦。换设备不用改上层，换应用不用动底层。

3.2.1 设备层：数据的源头

设备层是追溯系统的「眼睛和手」。它负责从生产现场采集原始数据，并执行下发的指令。

• 采集对象：PLC、扫码枪、RFID读写器、传感器、工业相机、智能仪表。
• 采集内容：产品条码、工序参数（温度、压力、扭矩）、设备状态、时间戳、操作人员ID。
• 通信协议：OPC UA、Modbus TCP、MQTT、HTTP API。

设备层有个坑，我踩过好几次：协议碎片化。一条产线上可能同时有西门子PLC、基恩士扫码枪、欧姆龙温控器，协议各不相同。我的建议是，统一用边缘网关做协议转换，上层只认MQTT或HTTP，别让应用层直接对接裸协议。

3.2.2 执行层：数据的加工厂

执行层是追溯系统的「大脑」。它负责接收设备层的数据，进行清洗、校验、关联，并驱动业务流程。

• 核心组件：MES执行引擎、数据采集服务（SCADA）、规则引擎、事件管理、工单管理。
• 关键能力：数据实时处理、异常告警、工序流转控制、批次追溯链构建。

执行层最容易被忽视的是数据校验。设备层传过来的数据，经常有乱码、重复、缺失。我在项目里遇到过扫码枪误读，把“ABC123”读成“ABC12Z”，导致追溯链断裂。后来我在执行层加了「校验规则库」，条码格式不对直接告警并拒绝入库。这个设计后来成了标准功能。

3.2.3 应用层：数据的展示者

应用层是追溯系统的「脸面」。它面向用户提供查询、分析、报表、看板等功能。

• 功能模块：追溯查询、质量分析、生产看板、报表中心、告警管理、系统配置。
• 技术栈：Web前端（Vue/React）、后端API（Spring Boot/.NET Core）、数据库（时序库+关系库）。

应用层设计时，我建议把读操作和写操作分离。追溯查询是典型的读密集型，而数据采集是写密集型。混在一起，查询慢会拖垮写入，写入忙会阻塞查询。用读写分离架构，各走各的路。

3.3 数据流与业务流设计：让数据有序流动

架构搭好了，数据怎么流？业务怎么走？这是追溯系统能不能跑通的关键。

3.3.1 数据流设计：从设备到应用，步步为营

数据流分三个阶段：采集、处理、存储。

阶段	说明	技术选型
采集	设备层通过OPC UA/MQTT上报原始数据	边缘网关、工业物联网平台
处理	执行层清洗、校验、关联，构建追溯链	流处理引擎（Kafka Streams/Flink）
存储	结构化数据入关系库，时序数据入时序库	PostgreSQL + InfluxDB / TimescaleDB

数据流设计有个原则：数据不落地，链路不断裂。每个环节都要有确认机制。设备上报后，执行层必须回ACK；执行层处理完，必须写日志。我曾经在一个项目里，因为漏了ACK机制，设备以为数据发成功了，执行层其实没收到，结果整批产品追溯缺失。后来加了「数据对账」功能，每小时比对一次设备上报量和系统入库量，不一致就自动补采。

3.3.2 业务流设计：从投料到出货，环环相扣

业务流是追溯系统的「灵魂」。它定义了数据在什么时机、什么条件下被采集和关联。

典型的追溯业务流如下：

1. 来料入库：扫描供应商条码，生成内部追溯码，记录批次、数量、入库时间。
2. 投料上机：扫描物料条码和工单号，系统校验物料是否匹配，记录投料时间、操作人。
3. 工序加工：设备自动采集工艺参数，操作工扫描产品条码，系统记录工序完成时间、参数值、设备ID。
4. 质量检验：检验员扫描产品条码，录入检验结果（合格/不合格），系统自动关联该工序的工艺参数。
5. 成品入库：扫描成品条码，系统自动汇总该产品的全流程追溯数据，生成追溯报告。

3.4 架构总览图：一张图看懂三层架构与数据流

说了这么多，不如一张图来得直观。下面是我画的三层架构与数据流图，你仔细看看，每个节点、每条线都有它的道理。

这张图我画了不下十版。最早版本把三层画成三个独立盒子，后来发现数据流和业务流是交织的，不能简单割裂。最终版就是你现在看到的：设备层向上报数据，执行层处理完向上喂数据，应用层向下发指令。箭头是双向的，但数据流是单向的——从下往上。指令流是反向的——从上往下。这个设计，说白了就是「数据向上汇聚，指令向下分发」。

3.5 架构落地的三个关键决策

架构设计完了，落地时还有三个决策点，我建议你提前想清楚：

1. 选集中式还是分布式？单工厂用集中式，多工厂用分布式。别为了技术炫酷，小厂硬上分布式，运维成本够你喝一壶。
2. 选实时库还是关系库？时序数据（温度、压力）用实时库，业务数据（工单、批次）用关系库。混着用，查询性能会崩。
3. 选自研还是采购？核心追溯逻辑自研，边缘采集用成熟方案。什么都自研，周期太长；什么都采购，定制能力太弱。