2. 集成架构总体设计
ERP、MES、QMS、WMS 四类系统的集成，本质上不是“把接口连起来”这么简单，而是要在业务语义、数据时效、系统边界和运维责任之间做一次总体权衡。总体设计的核心任务，是先把系统分成清晰的层次，再为每一层之间的交互选择匹配的集成模式，最后用技术选型和约束条件把方案钉死，避免后期出现“接口能通、业务不通”的返工。
一、分层架构：把四类系统放到正确的位置
推荐采用“五层参考架构”，自下而上依次为：设备与执行层、制造执行层、业务管理层、质量与仓储协同层、集成与数据服务层。注意，QMS 和 WMS 并不完全从属于某一层，它们既服务于制造现场，也服务于业务管理，因此在架构中应作为“横向协同域”处理。
设备与执行层包含 PLC、SCADA、条码/RFID 采集终端、AGV 调度接口等，主要产生高频、短周期、强实时的过程数据。MES 位于制造执行层，负责工单派工、工序报工、物料消耗、设备状态和过程追溯。ERP 位于业务管理层，负责销售订单、采购、生产计划、库存财务和成本核算。QMS 覆盖来料检验、过程检验、成品检验、不合格品处理和 CAPA；WMS 覆盖收货、上架、拣选、发运和库存盘点。集成与数据服务层则承担协议转换、消息路由、数据映射、接口监控和主数据分发。
分层的意义在于：每一层只暴露必要的接口，上层不直接穿透到底层数据库。例如 ERP 不直接写 MES 的工单表，而是通过集成层下发工单；MES 不直接改 WMS 的库存表，而是通过物料移动请求触发 WMS 过账。这样既保护了各系统的内部模型，也让故障边界和升级边界变得清晰。
二、集成模式：按业务时效选择，而不是一刀切
四类系统之间的交互，按实时性可分成三档，对应三种集成模式。
第一档：实时同步调用（REST/HTTP + JSON）。适用于需要立即得到结果的场景，例如 MES 向 WMS 发起“物料出库请求”，WMS 必须当场返回“过账成功/失败”以及批次号。这类接口要求低延迟、强一致，通常设置 3～5 秒超时，失败后由调用方决定是否重试。示例参数：超时 3000 ms，重试 2 次，退避间隔 500 ms。
第二档：异步消息（Kafka/RabbitMQ）。适用于状态通知和事件广播，例如 MES 报工完成后发布“工序完工事件”，ERP 和 QMS 各自订阅。异步模式解耦了生产者和消费者，允许短时峰值堆积。关键设计是消息幂等：每条消息带唯一 businessKey，消费端按 businessKey 去重，避免重复过账。
第三档：批量文件/定时任务。适用于大批量、非实时数据，例如每日凌晨将 ERP 的物料主数据、BOM 版本同步到 MES 和 WMS。通常采用 CSV/JSON 文件加校验和，或直接走数据库批量接口。示例：每日 02:00 执行，单批不超过 5 万条，失败自动告警并保留上一版本。
选择原则可以概括为：要结果用同步，要通知用异步，要批量用文件。同一对系统之间可以同时存在多种模式，但必须明确每种模式负责的数据对象，避免同一份数据被两条路径重复写入。
三、技术选型：接口、中间件与数据格式
接口层面，优先采用 RESTful API 作为同步交互标准，统一使用 JSON 作为报文格式，字段命名采用小驼峰，时间统一为 ISO 8601 带时区格式。对于设备侧高频数据，可保留 OPC UA 或 MQTT 接入，再由边缘网关转换为平台消息。
中间件层面，消息队列建议选择 Kafka 或 RabbitMQ：Kafka 适合高吞吐、可回溯的事件流；RabbitMQ 适合复杂路由和低延迟通知。若企业已有 ESB 或 iPaaS，可复用其路由和转换能力，但不要让 ESB 承担业务逻辑，否则会形成新的单点瓶颈。
数据格式与映射层面，必须建立统一的“集成数据字典”。例如 ERP 的物料编码为 10 位数字，MES 为 12 位带前缀，WMS 为 8 位内部码，集成层需要维护一张映射表，并在每次同步时校验映射完整性。示例映射规则：ERP 物料编码 1000234567 → MES 编码 M-1000234567 → WMS 编码 W234567。任何一条映射缺失，都应阻断该条数据下发并产生告警，而不是静默跳过。
四、关键约束：让架构可落地、可运维
总体设计必须提前约定以下约束，否则集成越深入，返工成本越高。
- 主数据唯一源：物料、BOM、供应商、客户以 ERP 为唯一源；库位、批次规则以 WMS 为唯一源；检验项和判定规则以 QMS 为唯一源。其他系统只读，不得本地修改后回写。
- 接口幂等：所有写操作接口必须支持幂等，调用方携带唯一请求号，服务端按请求号去重，防止网络重试导致重复过账。
- 时序一致：同一业务对象的事件必须带时间戳和版本号，消费端按版本号拒绝旧消息，避免“先发后到”造成状态回退。
- 网络分区容忍：车间网络可能短时中断，MES 应具备本地缓存和断点续传能力，恢复后按序补发，而不是直接丢弃。
- 审计与回滚：每次集成写入都要记录来源系统、请求号、报文摘要、处理结果和时间戳；关键业务支持按请求号反向冲销，而不是直接改库。
总体设计完成后，可以用一个简单判据检验：任意一条业务数据，能否说清它从哪个系统产生、经过哪条路径、在哪个环节被转换、最终落到哪个系统、失败时由谁负责。如果这条链路是清晰的，分层、模式和约束就基本立住了；如果说不清，说明架构还停留在“接口能通”的层面，需要回到本节的分层和约束重新对齐。