3. EAP采集架构设计

EAP（Equipment Application Process）设备参数采集系统要同时面对几十到上千台设备、毫秒级到秒级不等的采集周期、多种工业协议以及上层 MES/SPC/看板对实时数据的并发消费需求。如果把这些职责全部塞进一个进程，任何一处阻塞都会拖垮整条链路。因此工程上普遍采用四层解耦架构：边缘采集层负责“把设备数据拿到手”，消息中间件负责“把数据可靠地搬运”，数据存储层负责“把数据按用途落位”，应用服务层负责“把数据变成业务价值”。四层之间通过明确的接口与背压机制隔离，使系统在单点故障、流量突增和横向扩容时都能保持稳定。

边缘采集层：把不确定性挡在车间侧

边缘层是整条链路中环境最恶劣、协议最杂的一层。它的核心职责不是“采集”本身，而是把设备侧的不确定性收敛成统一、可传输的数据格式。典型实现是在一台工控机或边缘网关上运行采集服务，内部按“驱动插件 + 调度器 + 标准化管道 + 本地队列”组织。

以一台支持 SECS/GEM 的刻蚀设备为例，采集服务通过 HSMS 连接设备，订阅 S1F3 状态变量和 S6F11 事件报告。假设采集周期为 500 ms，每次读取 12 个参数（腔体压力、RF 功率、气体流量等），单台设备每秒产生约 24 条记录。采集服务在本地完成三件事：一是给每条记录打上设备时间戳与采集时间戳，两者不一致时以设备时间为准并标记偏差；二是附加质量码（Good/Bad/Uncertain），通信超时或数值越界时置为 Bad；三是按设备 ID 做本地去重与死区压缩，例如温度变化小于 0.1 ℃ 时不重复上报，可降低 30%～60% 的无效流量。

边缘层的高可用关键是断网续传。本地队列建议使用嵌入式数据库或磁盘队列，容量按“最长断网时间 × 峰值速率”估算。若单台设备峰值 50 条/秒、要求断网 2 小时不丢数，则队列至少需容纳 36 万条记录。恢复联网后按时间顺序回放，并在消息头中标记 replay=true，便于下游区分实时数据与补传数据。

消息中间件：可靠搬运与流量削峰

消息中间件承担“解耦、缓冲、广播”三重角色。选型上，Kafka 适合高吞吐与多消费组场景，RabbitMQ 适合复杂路由与低延迟，Pulsar 则在多租户和分层存储上有优势。无论选哪种，Topic 设计都应遵循按设备或产线分区的原则，例如 eap.raw.{site}.{line}.{equipmentId}，这样同一台设备的数据严格有序，不同设备可并行消费。

可靠性由三个参数共同决定：生产者 acks=all 确保消息写入所有同步副本；Topic 副本数设为 3、min.insync.replicas=2，允许单 broker 故障而不丢数据；消费者采用手动提交位点，先写库再提交，避免“提交成功但数据未落库”的丢数窗口。当存储层写入变慢时，消费滞后（Lag）会上升，此时应通过增加分区数和消费者实例来水平扩展，而不是无限堆积。

数据存储层：按用途分层落位

采集数据不能只进一个库。工程上通常分四类存储：时序数据库（如 TDengine、InfluxDB）存原始参数与高频曲线，按设备建超级表、按天分区；关系数据库存设备台账、参数定义、采集配置等低频变更数据；缓存（Redis）存每台设备的最新值与热点查询结果，供看板毫秒级读取；对象存储存原始日志、SECS 报文和归档文件。

生命周期策略建议：原始秒级数据保留 30 天，1 分钟聚合数据保留 1 年，1 小时聚合数据长期保留。这样既满足 SPC 追溯，又控制存储成本。写入侧采用批量提交，例如每 500 条或每 200 ms 触发一次 flush，可在吞吐与实时性之间取得平衡。

应用服务层：无状态与可扩展

应用层应保持无状态，会话与中间结果放入 Redis，使任意实例可被替换或扩容。实时看板通过 WebSocket 订阅消息中间件，SPC 分析服务按消费组独立消费，告警引擎基于规则窗口计算。所有对外接口经 API 网关统一鉴权、限流与熔断，单实例故障不影响整体可用性。

可扩展性则体现在分区键与无状态化上：边缘节点按设备分组横向增加，消息分区按设备 ID 扩展，存储按时间分区滚动，应用实例按消费组扩容。四层各自独立伸缩，整条链路才能随产线数量增长而平滑扩展，而不是被迫整体重构。