📚 课程目录第2章事件驱动架构基础

2. 事件驱动架构基础：事件、事件源、事件总线、事件消费者、事件驱动与消息驱动的区别

在构建事件驱动的基础设施即代码（IaC）与 Error Budget 联动体系之前，必须透彻理解事件驱动架构（EDA）的核心概念。本章将拆解 EDA 的五大基础要素，并厘清“事件驱动”与“消息驱动”这两个常被混淆的范式。

2.1 核心概念定义

概念	定义	在 IaC + Error Budget 场景中的实例
事件（Event）	表示“已经发生的事实”的不可变记录。事件包含状态变化的数据，但不包含“下一步该做什么”的指令。	`DeploymentCompleted`（部署完成）、`ErrorBudgetExhausted`（错误预算耗尽）、`NodeHealthCheckFailed`（节点健康检查失败）。
事件源（Event Source）	产生事件的实体。它负责检测状态变化并发布事件，不关心谁消费该事件。	CI/CD 流水线（GitHub Actions）、监控系统（Prometheus Alertmanager）、Kubernetes API Server、Terraform Cloud Run。
事件总线（Event Bus）	事件传输与路由的中介层。它解耦了事件源与消费者，支持发布/订阅（Pub/Sub）模式。	Apache Kafka、AWS EventBridge、NATS、Redis Streams。
事件消费者（Event Consumer）	订阅并处理事件的组件。消费者对事件做出反应，执行副作用（如触发回滚、调整告警阈值）。	自动回滚机器人、ChatOps 通知服务、Error Budget 恢复策略执行器。

SRE 视角提示： 在 Error Budget 联动中，事件必须是“不可变的事实记录”。例如，ErrorBudgetExhausted 事件一旦发布，即使后续指标恢复，也不应撤回该事件；正确的做法是发布一个新的 ErrorBudgetRecovered 事件。这保证了审计链路的一致性。

2.2 事件驱动 vs 消息驱动：关键差异

许多团队将“事件驱动”与“消息驱动”混为一谈，但两者在架构意图和耦合度上有本质区别。下表从 SRE 关心的维度进行对比：

对比维度	事件驱动（Event-Driven）	消息驱动（Message-Driven）
核心意图	通知“发生了什么”（事实广播）	请求“做什么”（任务分配）
数据内容	仅包含状态快照或变更增量（Payload 轻量）	包含完整的处理指令或目标（Payload 可能较重）
耦合度	时间解耦 + 空间解耦。生产者不关心消费者数量或状态。	通常空间解耦，但时间耦合较强（点对点队列要求消费者在线）。
路由方式	基于主题（Topic）的发布/订阅，一个事件可被多个消费者独立处理。	基于队列（Queue）的点对点或竞争消费者模式，一条消息通常只被一个消费者处理。
失败处理	消费者失败不影响其他消费者；事件通常持久化，可重放。	消息消费失败后进入死信队列（DLQ），需要手动或自动重试。
典型场景	基础设施状态变更通知、审计日志、Error Budget 阈值告警广播。	CI/CD 任务调度、配置下发、RPC 调用替代。

常见误区： 使用 Kafka 发送“执行回滚”指令属于消息驱动，而非事件驱动。正确的做法是：事件总线只发布 DeploymentFailed 事件，由专门的消费者（如 Rollback Controller）根据该事件决定是否执行回滚。事件总线不承载“命令”语义。

2.3 事件驱动架构核心流程

下图展示了事件驱动架构在 IaC 部署与 Error Budget 联动中的典型数据流：

2.4 事件驱动在 IaC 部署中的优势

解耦部署流水线： 部署的每个阶段（构建、测试、发布、验证）通过事件连接，而非硬编码的 API 调用。任一阶段失败，仅发布失败事件，不影响其他阶段的消费者。
Error Budget 实时联动： 当错误预算耗尽事件发布时，多个消费者可以同时响应：暂停自动部署、提升告警级别、触发事后复盘（Postmortem）流程。
事件重放与审计： 事件总线持久化所有基础设施变更事件。当需要排查“为什么某个版本导致 SLO 违规”时，可以重放历史事件，重建现场。
弹性伸缩： 消费者可以根据事件吞吐量独立扩缩容。例如，Error Budget 计算器可以运行在 Serverless 函数上，仅在事件涌入时消耗资源。

2.5 事件驱动 vs 消息驱动：选择指南

在构建 IaC 与 Error Budget 联动系统时，应根据场景选择正确的模式：

使用事件驱动： 当需要广播“状态变更”时（如 DeploymentStarted、ErrorBudgetWarning、ConfigDriftDetected）。多个消费者需要独立处理同一事实。
使用消息驱动： 当需要精确分配“工作任务”时（如“执行 Terraform Apply”、“重启 Nginx 容器”）。通常只需要一个消费者执行一次。

  实战建议： 在同一个系统中，事件驱动和消息驱动可以共存。例如，使用事件总线广播 DeploymentFailed 事件，同时使用消息队列将“回滚任务”精确分配给某个空闲的 Worker。事件总线负责“通知”，消息队列负责“调度”。

2.6 事件驱动架构的常见反模式

反模式	问题描述	正确做法
事件中包含命令	事件 Payload 中包含 `action: rollback` 字段，暗示消费者必须执行特定操作。	事件只包含事实：`status: failed`、`reason: health_check_timeout`。消费者自行决定动作。
消费者产生副作用事件	消费者在处理事件时，直接修改事件源的状态，形成循环依赖。	消费者只发布新的事件到总线，由其他消费者或事件源监听并响应。
过度依赖事件顺序	假设事件一定按发生顺序到达消费者（尤其在分布式系统中不可靠）。	使用事件时间戳和版本号，消费者应设计为幂等且能处理乱序事件。
事件总线成为单点故障	所有事件流经单一 Kafka 集群或单一 EventBridge，未做容灾。	采用多区域事件总线复制，或使用支持跨可用区高可用的事件存储。