1. 事件驱动架构概述
1.1 事件驱动架构（EDA）核心概念
事件驱动架构（Event-Driven Architecture, EDA）是一种基于事件产生、检测、消费和响应的软件设计范式。在 EDA 中，组件之间不直接调用，而是通过事件总线进行松耦合通信。核心要素包括：
- 事件（Event）：系统中发生的、值得关注的状态变化，例如“CPU 使用率超过 90%”、“磁盘空间不足 5%”。
- 事件生产者（Producer）：检测并发布事件的组件，如监控 Agent、日志采集器。
- 事件通道（Channel）：传输事件的中间件，如消息队列（Kafka、RabbitMQ）、事件流平台。
- 事件消费者（Consumer）：订阅并处理事件的组件，如告警自愈引擎、自动化脚本执行器。
- 事件处理器（Processor）：对事件进行过滤、聚合、转换的逻辑单元。
关键特征：EDA 强调“发布-订阅”模式，生产者与消费者完全解耦，事件是唯一的通信载体。
1.2 事件驱动架构在告警自愈中的价值
在告警自愈场景中，EDA 将告警事件作为驱动自愈流程的触发器，实现从“被动响应”到“主动闭环”的转变。具体价值体现在：
| 价值维度 | 说明 | 典型场景 |
|---|---|---|
| 实时响应 | 事件产生后立即触发处理流程，无需轮询等待 | CPU 飙高 → 立即执行扩容脚本 |
| 松耦合 | 告警源与自愈动作解耦，新增监控项不影响现有流程 | 新增 Redis 监控 → 订阅对应事件即可 |
| 异步处理 | 事件可缓冲、排队，避免突发告警压垮系统 | 大规模节点同时故障 → 事件队列削峰 |
| 可追溯 | 事件持久化存储，支持历史回溯和审计 | 故障复盘 → 查询事件时间线 |
| 弹性伸缩 | 消费者可水平扩展，处理能力随事件量动态调整 | 业务高峰期 → 增加自愈引擎实例 |
实践建议：在告警自愈平台中，EDA 通常作为“事件触发引擎”的核心，将 Prometheus Alertmanager、Zabbix 等告警源产生的事件标准化后，路由到对应的自愈剧本执行器。
1.3 与传统轮询架构的对比
传统轮询架构（Polling Architecture）依赖监控系统定期查询目标状态，与 EDA 在多个维度存在本质差异：
| 对比维度 | 事件驱动架构（EDA） | 传统轮询架构 |
|---|---|---|
| 触发方式 | 事件发生时立即推送 | 按固定间隔主动查询 |
| 资源消耗 | 低（仅在事件产生时消耗） | 高（持续占用网络和计算资源） |
| 实时性 | 毫秒级响应 | 受轮询间隔限制（通常 30s-5min） |
| 系统耦合度 | 松耦合，生产者和消费者独立演进 | 紧耦合，查询逻辑依赖目标系统接口 |
| 扩展性 | 天然支持水平扩展 | 轮询节点增多时压力线性增长 |
| 适用场景 | 高频变化、需要快速自愈的场景 | 低频变化、对实时性要求不高的场景 |
注意：轮询架构并非完全不可用。对于“磁盘使用率”这类变化缓慢的指标，30 秒轮询一次完全足够；但对于“服务宕机”这类需要秒级自愈的事件，EDA 是唯一可行的方案。
1.4 小结：为什么告警自愈必须选择 EDA？
从上述对比可以看出，告警自愈场景对实时性、可靠性、可扩展性有极高要求，EDA 天然匹配这些需求：
- 秒级自愈闭环：事件从产生到触发自愈动作，端到端延迟可控制在 1 秒以内。
- 故障隔离：单个事件处理失败不影响其他事件流，系统整体可用性高。
- 剧本编排灵活：通过事件路由规则，可动态调整不同告警对应的自愈剧本，无需重启服务。
- 审计与复盘：所有事件持久化存储，为故障根因分析提供完整数据链。