2. 事件驱动架构基础：事件、事件源、事件总线、事件消费者、异步通信模式
事件驱动架构（Event-Driven Architecture, EDA）是构建 Runbook 联动 IaC 配置审计系统的核心通信范式。在传统轮询模型中，审计引擎需要反复查询配置状态，导致延迟高、资源浪费；而 EDA 允许系统在配置发生变更的瞬间做出响应，实现真正的实时合规。
本章将拆解 EDA 的五个核心要素：事件、事件源、事件总线、事件消费者以及异步通信模式，并说明它们如何在配置审计场景中协同工作。
2.1 事件（Event）
事件是“已经发生的、不可变的事实记录”。在 IaC 配置审计上下文中，事件代表一次配置变更或状态偏离。事件通常包含三个部分：
- Header（元数据）：事件 ID、时间戳、事件类型、来源标识。
- Payload（负载）：变更的具体内容，如资源属性、新旧值对比。
- Context（上下文）：触发环境信息，如 Git 提交 SHA、操作人、项目名称。
关键原则：事件是不可变的。一旦发布，不应被修改或删除。审计系统依赖事件的不可变性来保证合规追溯的完整性。
事件类型示例（配置审计场景）
| 事件类型 | 描述 | 示例 Payload |
|---|---|---|
ResourceCreated |
新的基础设施资源被创建 | { "resourceType": "aws_s3_bucket", "name": "prod-logging" } |
ResourceModified |
现有资源的配置属性被更改 | { "changedField": "acl", "oldValue": "private", "newValue": "public-read" } |
ComplianceViolation |
配置偏离了预定义的合规策略 | { "ruleId": "S3_BLOCK_PUBLIC_ACCESS", "severity": "CRITICAL" } |
DriftDetected |
实际运行状态与 IaC 声明状态不一致 | { "resourceId": "i-0abcd1234", "driftType": "UNEXPECTED_TAG" } |
2.2 事件源（Event Source）
事件源是产生事件的实体。在自动化运维体系中，事件源通常分为三类：
- 基础设施变更源：Terraform / Pulumi / CloudFormation 执行后的状态变更通知。
- 监控与审计源：AWS Config、Azure Policy、Prometheus Alertmanager 发出的合规或告警事件。
- 人工操作源：运维人员通过 Runbook 手动执行变更操作时产生的事件。
最佳实践：每个事件源应分配唯一的
sourceId，并在事件 Header 中携带。这有助于在事件总线上进行路由过滤和故障排查。
2.3 事件总线（Event Bus）
事件总线是 EDA 的中枢神经系统。它负责接收来自多个事件源的事件，并根据路由规则将事件分发给一个或多个消费者。事件总线解耦了生产者和消费者，使得双方可以独立扩展和演进。
主流的事件总线实现包括：
| 实现 | 特点 | 适用场景 |
|---|---|---|
| AWS EventBridge | 支持 Schema Registry、内容过滤、跨账户路由 | 多云或 AWS 原生 IaC 审计 |
| Apache Kafka | 高吞吐、持久化、分区有序 | 大规模配置变更流处理 |
| RabbitMQ | 灵活的路由模式（Topic/Direct/Fanout） | 中小规模、需要复杂路由的场景 |
| CloudEvents | 开放标准格式，跨平台互操作 | 多供应商混合架构 |
2.4 事件消费者（Event Consumer）
事件消费者是订阅并处理事件的组件。在配置审计场景中，消费者通常执行以下三类操作：
- 审计评估：将事件中的配置数据与合规策略（如 OPA / Sentinel 策略）进行比对，生成合规评分。
- 自动修复：当检测到
ComplianceViolation或DriftDetected 事件时，触发预定义的 Runbook 进行自动修复。 - 记录与通知：将事件持久化到审计日志，并通过 Slack、PagerDuty 或邮件通知相关责任人。
幂等性要求：事件消费者必须实现幂等处理。由于网络故障或重试机制，同一事件可能被多次投递。消费者应通过事件 ID 去重，避免重复修复或重复告警。
2.5 异步通信模式
异步通信是 EDA 的基石。与同步 RPC 不同，事件源发布事件后立即返回，无需等待消费者处理完成。这种模式为配置审计系统带来三个关键优势：
| 特性 | 同步模式 | 异步模式（EDA） |
|---|---|---|
| 耦合度 | 强耦合，调用方依赖被调用方可用 | 松耦合，事件源与消费者独立部署 |
| 吞吐量 | 受限于最慢的消费者 | 事件总线缓冲，消费者独立伸缩 |
| 故障隔离 | 消费者故障可能导致调用方阻塞 | 消费者故障不影响事件源，事件暂存总线 |
| 审计追溯 | 日志分散在各服务中 | 事件总线提供统一的审计事件流 |
异步通信的三种投递保证
- At-most-once（至多一次）：性能最高，但可能丢事件。适用于非关键指标采集。
- At-least-once（至少一次）：保证事件不丢失，但可能重复。适用于配置审计，配合消费者幂等去重。
- Exactly-once（精确一次）：最严格，通常需要分布式事务或事件总线与消费者协同实现。适用于金融级合规场景。
2.6 配置审计场景中的事件流示例
以下是一个完整的端到端事件流，展示 EDA 如何驱动 IaC 配置审计：
1. 事件源：Terraform Apply 完成
→ 发布 ResourceModified 事件到 EventBridge
→ Payload: { "resource": "aws_security_group", "name": "web-sg", "changedField": "ingress" }
2. 事件总线：EventBridge 根据规则过滤
→ 匹配 "resourceType == aws_security_group"
→ 路由到审计消费者队列
3. 事件消费者：审计引擎消费事件
→ 调用 OPA 策略评估 ingress 规则是否开放了 0.0.0.0/0
→ 发现违规，发布 ComplianceViolation 事件
4. 事件总线：再次路由 ComplianceViolation 事件
→ 发送到自动修复 Runbook 消费者
→ 同时发送到通知服务
5. 事件消费者：自动修复 Runbook
→ 执行 Terraform 计划，移除危险规则
→ 记录修复操作到审计日志
关键洞察：在整个流程中，事件总线充当了审计轨迹的持久化存储。所有事件都被顺序记录，使得事后合规审查和故障根因分析变得简单可靠。