📚 课程目录第4章 MOM接口平台架构设计

4. MOM接口平台架构设计

MOM（制造运营管理）接口平台不是把 ERP、MES、WMS、QMS、SCADA 等系统简单“连起来”的中间件，而是一套有明确分层职责、可独立演进、可观测、可治理的接口运行体系。分层的目的不是画架构图好看，而是让每一类问题都有唯一的归属层：安全与流量问题归网关层，业务语义与编排问题归服务层，异构协议与系统适配问题归集成层，数据一致性与持久化问题归数据层，运行状态与治理闭环归监控层。理解这五层的职责边界和交互关系，是后续做接口设计、排障和容量规划的基础。

五层职责定位

网关层是接口平台对外的唯一入口，承担南北向流量的统一管控。核心职责包括：路由与转发（按接口路径、调用方、版本路由到后端服务）、认证鉴权（校验调用方身份，如 OAuth2 Token、API Key、双向 TLS 证书）、限流熔断（按调用方或接口维度设置 QPS 阈值，超限快速失败）、协议转换（对外统一暴露 REST/JSON，屏蔽后端可能存在的 SOAP、gRPC 差异）、日志埋点（记录请求 ID、耗时、状态码）。网关层不承载业务逻辑，任何“判断这个工单该不该下发”的规则都不应写在这里。

服务层是接口平台的业务编排与语义中心。它把来自网关的请求翻译成制造业务动作，例如“创建生产工单”“报工过站”“库存预留”。服务层负责：接口契约定义（请求/响应结构、字段校验规则）、业务编排（一次报工可能需要同时更新 MES 工序状态、扣减 WMS 线边库存、写入 QMS 检验记录）、幂等控制（同一报工请求重复提交只生效一次）、事务边界管理。服务层是唯一允许出现业务规则的地方。

集成层解决“怎么和具体系统说话”的问题。每个被集成的系统（ERP、MES、WMS、SCADA、PLC）通常有独立的适配器，负责协议适配（HTTP、MQ、OPC UA、数据库直连）、数据格式转换（XML↔JSON、字段映射、编码转换）、连接管理与重试。集成层不判断业务对错，只保证“把服务层给的数据按目标系统能接受的方式送达，并把响应原样带回”。

数据层负责接口平台自身需要持久化的数据：接口调用日志、幂等键记录、消息投递状态、接口配置元数据、字典映射表。它不存储各业务系统的全量业务数据，只存接口运行所必需的“过程数据”和“治理数据”。数据层的设计重点是写入性能（高并发日志）和查询效率（按请求 ID、时间、调用方检索）。

监控层是横切层，贯穿其余四层。它采集网关的流量指标、服务层的业务成功率、集成层的适配器健康度、数据层的写入延迟，并输出告警、链路追踪和治理报表。监控层不是“事后看日志”，而是要在接口调用链路上埋点，做到一次失败请求能定位到具体是哪一层、哪个适配器、哪个字段出的问题。

层间交互关系与数据流

一次典型的接口调用遵循“自上而下处理、自下而上返回”的路径。以移动端发起“报工过站”为例：请求首先到达网关层，网关校验 Token 有效性和调用方 QPS 配额，通过后按路径 /api/v1/production/report 路由到服务层的报工服务。服务层解析请求体，校验工单号、工序号、报工数量等字段，生成幂等键（工单号+工序号+报工时间戳），先查数据层幂等表确认未重复提交，然后执行编排：调用集成层的 MES 适配器更新工序状态，调用 WMS 适配器扣减线边库存，调用 QMS 适配器写入检验记录。三个适配器分别以各自协议与目标系统通信，将结果返回服务层。服务层汇总结果，若全部成功则写入调用日志和幂等记录，返回成功响应；若任一失败，根据事务策略决定回滚或标记补偿。响应沿原路径返回网关，网关记录耗时和状态码后返回调用方。

这里有一个关键设计点：幂等键的生成和校验必须在服务层完成，而不是网关层或集成层。网关层不知道“工单号+工序号”的业务含义，集成层只面对单个目标系统无法判断跨系统重复。服务层持有完整业务语义，是幂等控制的唯一正确位置。数据层的幂等表通常以幂等键为主键，写入时利用数据库唯一约束实现原子性判断，避免“先查后写”的并发漏洞。

监控层的横切采集与故障定位

监控层不是独立运行的第五层，而是以埋点方式嵌入其余四层。网关层埋入请求 ID 和入口耗时，服务层埋入业务步骤耗时和幂等命中标记，集成层埋入适配器调用耗时、目标系统响应码和重试次数，数据层埋入写入延迟和慢查询。所有埋点共享同一个请求 ID，使得一次失败请求可以在监控面板上展开完整链路：请求从哪个调用方进入、在网关是否被限流、在服务层哪个编排步骤失败、在集成层是哪个适配器返回了什么错误码、数据层是否成功记录了失败日志。

例如，某次报工接口返回 500，监控链路显示：网关层状态正常（耗时 12ms），服务层“扣减线边库存”步骤耗时 8s 后失败，集成层 WMS 适配器返回 CONNECTION_TIMEOUT，重试 2 次均失败，数据层已记录失败日志。排障结论直接指向 WMS 适配器与 WMS 系统之间的网络或 WMS 服务可用性问题，而不需要逐层排查。这就是分层加统一请求 ID 带来的定位效率。

分层设计的边界纪律

分层架构最容易出问题的地方不是层没画出来，而是层与层之间的职责越界。常见的越界包括：把限流规则写成“某工单类型不允许高频报工”放进网关层（这是业务规则，应放服务层）；在集成层里判断“库存不足则不调用 WMS”（这是业务判断，应放服务层）；把业务系统的全量工单数据同步到数据层做报表（数据层只存接口过程数据，业务报表应查业务系统或数仓）。

边界纪律的核心判断标准：如果一条逻辑的变更原因是“业务规则变了”，它属于服务层；如果变更原因是“目标系统换了协议或字段”，它属于集成层；如果变更原因是“安全策略或流量策略调整”，它属于网关层。按变更原因归层，而不是按代码位置归层。

接口元数据配置示例

为了让五层协同工作，接口平台需要一份接口元数据来描述每个接口在各层的配置。以下是一个报工接口的元数据示例（YAML 格式，字段为示例值）：

interface:
  name: production-report
  path: /api/v1/production/report
  method: POST
  gateway:
    auth: oauth2
    rate_limit: 200/s
    timeout_ms: 10000
  service:
    idempotency_key: "${workOrderNo}:${operationNo}:${reportTime}"
    orchestration:
      - step: update_mes_operation
        adapter: mes-adapter
        timeout_ms: 3000
      - step: deduct_wms_stock
        adapter: wms-adapter
        timeout_ms: 3000
      - step: write_qms_record
        adapter: qms-adapter
        timeout_ms: 2000
    transaction: best_effort_compensate
  integration:
    mes-adapter:
      protocol: http
      endpoint: http://mes.internal/api/operation/status
      retry: 2
    wms-adapter:
      protocol: mq
      topic: wms.stock.deduct
      retry: 3
  data:
    log_retention_days: 90
    idempotency_ttl_hours: 24
  monitor:
    alert_on_error_rate: 1%
    alert_on_p99_ms: 3000

这份元数据本身就是分层职责的落地表达：gateway 段只出现认证、限流、超时；service 段出现幂等键和编排步骤；integration 段出现协议、端点、重试；data 段出现日志保留和幂等有效期；monitor 段出现告警阈值。每一段的内容都严格对应所属层的职责，没有交叉。

容量与性能的分层考量

五层的性能特征不同，容量规划也要分层做。网关层是无状态转发，扩容靠增加实例和负载均衡，瓶颈通常在 TLS 握手和限流计数器的集中存储；服务层有业务计算和编排，扩容时要注意幂等键的分布式锁竞争；集成层受目标系统吞吐限制，扩容适配器实例不一定能提升整体吞吐，反而可能压垮目标系统，因此集成层更适合做队列缓冲和背压控制；数据层的日志写入是高频追加，适合用分区表和异步批量写入，幂等表则需要低延迟点查，适合用内存数据库或带唯一索引的关系表；监控层的指标采集要考虑采样率，全量采集在高 QPS 下本身会成为负担。

理解这五层的职责、交互和边界，后续做接口设计时就能快速判断“这个逻辑该放哪一层”“这个故障该查哪一层”“这个容量瓶颈该扩哪一层”，而不是把所有问题都堆在一个“接口服务”里。