3. 事件驱动架构基础：事件、事件源、事件处理器、事件总线、事件驱动与请求驱动的区别
在数字工地管理现场看板系统中，传感器数据、设备状态变化、报警信号等高频、异步、多源的信息流，传统请求驱动模式难以高效处理。事件驱动架构（Event-Driven Architecture, EDA）通过“事件”作为核心通信单元，实现组件间的松耦合、实时响应与高可扩展性。本节将系统讲解事件驱动架构的五大核心要素，并对比其与请求驱动模式的关键差异。
3.1 核心概念定义
| 概念 | 定义 | 数字工地示例 |
|---|---|---|
| 事件（Event） | 表示“发生了某事”的不可变记录，包含时间戳、类型、数据载荷 | “塔吊风速超过阈值”、“人员进入禁区”、“混凝土温度异常” |
| 事件源（Event Source） | 产生事件的实体或系统组件，负责检测状态变化并发布事件 | IoT传感器、视频分析AI、设备PLC、工人定位标签 |
| 事件处理器（Event Processor） | 订阅并消费事件的组件，执行业务逻辑或触发后续动作 | 安全报告生成器、报警推送服务、看板数据刷新模块 |
| 事件总线（Event Bus） | 事件的中介通道，负责接收事件并路由给所有已订阅的处理器 | 消息队列（如Kafka、RabbitMQ）、云平台事件网格 |
关键原则：事件源与事件处理器完全解耦。事件源不关心谁消费事件，处理器不关心事件从何而来。这种松耦合是事件驱动架构在数字工地中能够灵活扩展、独立演化的基础。
3.2 事件驱动架构核心组件关系
下图展示了事件驱动架构中四个核心要素的协作关系：事件源将事件发布到事件总线，事件总线根据订阅规则将事件分发给对应的事件处理器，处理器执行逻辑后可能产生新事件再次进入总线。
3.3 事件驱动 vs 请求驱动：核心差异
请求驱动（Request-Driven）是传统的同步调用模式，客户端主动发起请求并等待响应；事件驱动则是异步、被动响应的模式。两者在数字工地场景中的适用性截然不同。
| 对比维度 | 请求驱动（同步） | 事件驱动（异步） |
|---|---|---|
| 通信方式 | 客户端主动请求，服务端响应 | 事件源发布，处理器订阅消费 |
| 耦合度 | 强耦合，调用方需知道服务地址和接口 | 松耦合，双方通过事件总线间接通信 |
| 时序关系 | 请求-响应必须同时在线 | 事件发布与消费可异步、可离线缓冲 |
| 扩展性 | 线性扩展困难，需协调上下游 | 处理器可独立水平扩展 |
| 典型场景 | 用户查询历史报告、配置参数 | 实时报警推送、传感器数据流处理 |
| 失败处理 | 请求超时或返回错误码 | 事件可重试、死信队列、补偿机制 |
数字工地选型建议：对于“查询历史安全报告”、“修改看板配置”等用户主动操作，使用请求驱动模式更直观；对于“传感器超限报警”、“设备故障自动上报”、“人员位置实时更新”等持续、异步的数据流，必须采用事件驱动架构以保证实时性和系统稳定性。
3.4 事件驱动与请求驱动的协作流程对比
以下两张SVG图分别展示请求驱动和事件驱动在“塔吊风速超限报警”场景下的处理流程，直观对比两者的差异。
3.4.1 请求驱动模式（轮询）
3.4.2 事件驱动模式（推送）
3.5 事件驱动架构在安全报告分级中的价值
- 实时性：传感器或AI检测到安全事件后立即发布，报告处理器即时响应，无需等待轮询周期。
- 分级处理：不同严重等级的事件可路由到不同的处理器（如红色事件触发紧急推送，黄色事件仅记录日志）。
- 弹性扩展：新增一种安全事件类型（如“基坑沉降异常”）只需添加对应的事件处理器，不影响现有组件。
- 故障隔离：某个处理器宕机不影响事件总线和其它处理器，事件可在队列中等待恢复后继续处理。
注意事项：事件驱动架构虽然强大，但引入事件总线增加了系统复杂度，需要处理事件顺序、重复消费、死信队列等问题。在数字工地中，建议对关键安全事件（如人员坠落、设备倾覆）启用“至少一次”投递语义，并配合幂等处理器防止重复报警。