2. EAP系统典型架构剖析

EAP（Equipment Application Platform，设备应用平台）承担着设备连接、协议解析、配方下发、数据采集、任务调度与MES/EAP上层系统对接等职责。它的架构选择直接决定了系统在设备断线、网络抖动、单点故障、版本升级等场景下的可用性表现。本节围绕四种典型架构——单体、集群、微服务、边缘计算——从部署形态、高可用瓶颈、容错边界与设计取舍四个维度展开剖析，帮助读者建立"架构即可用性边界"的判断能力。

一、单体架构：简单但存在硬性单点

单体架构将设备接入、协议适配、业务逻辑、数据库访问、Web管理界面全部打包在一个进程或一个WAR/JAR中部署。典型部署形态是：一台工控机或服务器运行一个EAP应用，通过SECS/GEM、Modbus TCP、OPC UA等协议直连设备，数据写入本地或集中数据库。

它的高可用瓶颈非常明确：进程级单点。一旦EAP进程崩溃、JVM Full GC停顿过长、或所在主机宕机，所有设备连接同时中断。设备侧通常有连接超时与重连机制，但重连风暴会进一步压垮刚恢复的进程。此外，单体架构中协议解析线程与业务处理线程共享同一线程池，某台设备的高频上报可能耗尽线程资源，导致其他设备"被饿死"。

设计取舍上，单体架构适合设备数量少（例如<50台）、协议种类单一、停机窗口可协商的场景。它的优势是部署简单、调试直观、事务边界清晰。若必须提升可用性，通常采用"冷备+VIP切换"或"双机热备"，但切换期间仍存在秒级到分钟级的中断，且状态同步（如未完成的配方下发事务）难以保证。

二、集群架构：横向扩展与有状态连接的矛盾

集群架构在单体基础上引入多实例与负载均衡。常见形态是：N个EAP实例同时运行，前置一个TCP负载均衡器或网关，设备连接被分发到不同实例。无状态的管理接口可以轻松水平扩展，但设备连接是有状态的长连接，这构成了集群架构的核心矛盾。

如果采用普通四层负载均衡，设备重连后可能落到不同实例，导致会话状态丢失、配方下发中断、事件订阅错乱。因此实际工程中通常引入会话粘滞（source IP hash）或集中式会话存储（Redis保存设备会话与订阅关系）。但粘滞策略在实例故障时会导致该实例上的设备全部重新分配，引发瞬时重连风暴。

集群架构的高可用瓶颈还包括：共享数据库成为新的单点；集群脑裂时可能出现双主写入；跨实例的设备状态一致性依赖分布式锁或版本号机制，实现复杂度显著上升。设计取舍是：用复杂度换可用性，适合设备规模中等（50~500台）、允许秒级切换、且团队具备分布式系统运维能力的场景。

三、微服务架构：解耦彻底但链路更长

微服务架构将EAP拆分为设备接入服务、协议适配服务、配方服务、数据采集服务、告警服务、API网关等独立进程，各自独立部署与扩缩容。设备接入服务负责维护长连接，协议适配服务负责SECS/GEM或OPC UA报文解析，配方服务负责事务性下发，数据采集服务负责时序数据写入。

这种架构的高可用优势在于故障隔离：配方服务崩溃不会直接断开设备连接，接入服务仍可缓存设备上报数据。但瓶颈也随之转移：服务间调用链变长，一次配方下发可能经过网关→配方服务→接入服务→设备，任一环节超时都会导致整体失败；服务注册中心、配置中心、消息队列成为新的关键依赖；分布式事务难以保证，配方下发与设备确认之间可能出现"半成功"状态。

设计取舍上，微服务适合设备规模大（>500台）、协议多样、需要独立迭代与弹性伸缩的场景。但必须配套完善的可观测性（链路追踪、指标、日志聚合）与熔断降级策略，否则故障定位时间会远超单体架构。

四、边缘计算架构：把可用性下沉到设备侧

边缘计算架构在设备侧或车间侧部署边缘节点，边缘节点承担协议解析、数据缓存、本地规则判断与断网续传，云端或中心EAP负责全局调度、模型训练与跨车间协同。典型形态是：边缘网关运行轻量EAP Agent，通过MQTT/HTTPS与中心通信，本地保留最近24~72小时数据。

它的高可用瓶颈从"中心是否宕机"转变为"边缘节点是否可靠"以及"边缘与中心的同步一致性"。边缘节点通常资源受限（CPU、内存、磁盘），长时间断网后本地队列可能溢出；边缘与中心恢复连接后，若采用简单的时间戳覆盖策略，可能造成数据错乱。因此需要设计幂等写入、断点续传与冲突解决规则。

设计取舍是：用边缘自治换中心依赖，适合网络不稳定、设备分布分散、对本地实时性要求高的场景。代价是运维节点数量增多、版本升级复杂、安全边界扩大。

五、架构选型的判断依据

四种架构并非互斥，实际项目中常见"边缘+中心微服务"的混合形态。选型时应重点回答三个问题：第一，设备断线时，业务能容忍多长的数据丢失窗口？单体可能丢失全部未落库数据，边缘架构可保留本地队列。第二，单台设备故障是否会扩散为系统故障？单体与集群中共享线程池、共享数据库都可能成为扩散路径，微服务与边缘架构通过隔离降低扩散概率。第三，团队能否承担对应的运维复杂度？微服务的可观测性建设、边缘节点的批量升级，都是隐性成本。