3. 事件驱动架构原理

事件驱动架构（Event-Driven Architecture, EDA）是值班机器人自动化框架的核心通信范式。与传统的请求-响应模式不同，EDA 将系统行为建模为“事件”的产生、传播与消费，从而实现组件间的松耦合、异步协作与故障隔离。本章将系统阐述 EDA 的核心概念、三大关键组件，并通过与请求驱动架构的对比，揭示其在故障恢复场景中的独特优势。

3.1 EDA 核心概念

事件驱动架构围绕以下四个基本概念构建：

• 事件（Event）：系统中发生的、值得记录或响应的状态变化。例如：“磁盘使用率超过 90%”、“服务进程崩溃”、“告警被确认”。事件是不可变的事实记录，通常包含时间戳、源标识符和负载数据。
• 事件生产者（Producer）：负责检测状态变化并发布事件的组件。在值班机器人中，监控探针、日志采集器、健康检查模块均属于生产者。
• 事件消费者（Consumer）：订阅并处理特定类型事件的组件。例如：故障诊断引擎、自动恢复脚本、通知分发器。
• 事件通道（Channel）：连接生产者与消费者的异步消息管道，负责事件的缓冲、路由与分发。

3.2 事件源（Event Source）

事件源是事件的原始产生地。在值班机器人场景中，事件源通常分为三类：

3.3 事件总线（Event Bus）

事件总线是 EDA 的中枢神经系统，负责事件的接收、存储、路由和投递。在值班机器人框架中，事件总线需要满足以下能力：

• 异步缓冲：当消费者处理速度低于生产者发布速度时，总线能暂存事件，防止数据丢失。
• 发布/订阅（Pub/Sub）：消费者根据事件类型或标签进行订阅，总线自动将匹配的事件推送给所有订阅者。
• 至少一次投递：确保事件不会因消费者临时故障而丢失，支持重试机制。
• 有序性保证：对于同一事件源或同一故障链的事件，保持处理顺序。

常见的事件总线实现包括：

3.4 事件处理器（Event Processor）

事件处理器是实际执行业务逻辑的组件。在值班机器人中，事件处理器通常以“管道”形式串联，每个处理器只关注一个职责：

1. 过滤处理器：根据规则丢弃无效或低优先级事件，减少下游负载。
2. 丰富处理器：为事件补充上下文信息，如关联的 CMDB 数据、历史故障记录。
3. 诊断处理器：执行故障分析，判断根因与影响范围。
4. 恢复处理器：执行预定义的恢复动作，如重启服务、扩容、回滚版本。
5. 通知处理器：将处理结果发送给值班人员或外部系统。

# 事件处理器示例：诊断处理器
class DiskHighDiagnosisProcessor:
    def handle(self, event):
        # 从事件负载中提取磁盘使用率
        usage = event.payload.get('usage_percent', 0)
        mount_point = event.payload.get('mount', '/')
        
        # 诊断逻辑
        if usage > 95:
            return self._emit_critical(event, mount_point, usage)
        elif usage > 85:
            return self._emit_warning(event, mount_point, usage)
        else:
            return None  # 不产生新事件，静默通过

3.5 与请求驱动架构的对比

请求驱动架构（Request-Driven Architecture, RDA）是传统的同步调用模式，如 REST API、RPC。下表从多个维度对比 EDA 与 RDA：

3.6 值班机器人中的 EDA 落地模式

在值班机器人自动化框架中，EDA 的具体落地遵循“事件源 → 总线 → 处理器管道 → 动作执行”的经典模式：

1. 事件接入层：通过统一的事件适配器接收来自 Prometheus、Zabbix、自研探针等不同源的事件，并转换为标准格式。
2. 事件路由层：基于事件类型（如 disk.high、service.crash）和严重级别，将事件分发到对应的处理管道。
3. 处理管道层：每个管道由多个事件处理器串联组成，支持动态插入新的处理器（如新增“自动扩容处理器”）。
4. 动作执行层：处理器最终触发恢复动作（如调用 Ansible 执行重启、调用 Kubernetes API 进行 Pod 重建），并将结果作为新事件反馈到总线。