architecture-paradigm-event-driven

事件驱动架构范式

适用场景

• 构建异步、松耦合的系统
• 具有复杂事件处理流水线的系统

不适用场景

• 无需异步处理的简单请求-响应应用
• 要求强事务一致性的系统

采用此范式的场景

• 对于实时或突发性工作负载（例如 IoT、金融交易、物流），松耦合和异步处理会带来益处。
• 多个彼此独立的子系统必须对相同的业务或领域事件作出响应。
• 系统可扩展性至关重要，需允许添加新组件而不修改现有服务。

采用步骤

1. 建模事件：定义规范的事件架构，制定清晰的版本控制策略，并明确每种事件类型的所有权。
2. 选择合适的拓扑结构：针对每种数据流，审慎选择编排方式（例如简单的发布/订阅模型）或集中式编排方式（例如中央控制器或 saga 编排器）。
3. 构建事件平台：选择合适的事件代理或消息网格。配置消息顺序、主题分区和数据保留策略等关键参数。
4. 规划故障处理：实施适用于生产环境的消息故障处理机制，包括死信队列（DLQ）、自动重试逻辑、幂等消费者和事件重放工具。
5. 增强可观测性：实施详细监控，跟踪消费者滞后、消息吞吐量、架构验证失败和各个消费者应用的健康状况等关键指标。

关键交付成果

• 一份架构决策记录（ADR），记录事件分类、所选代理技术和治理策略（例如命名、版本控制和保留策略）。
• 一个集中的架构仓库，配备自动化 CI 验证和消费者驱动的契约测试。
• 用于监控全系统吞吐量、消费者滞后和 DLQ 深度的运维仪表板。

风险与缓解措施

• 事件导致的隐性耦合：
  • 缓解措施：消费者可能会隐式依赖未记录的事件语义或数据字段。发布正式的事件目录或架构注册表，并使用代码检查工具强制执行事件结构。
• 运维复杂性和“噪声”：
  • 缓解措施：缺乏强大的可观测性时，诊断失败或“卡住”的消费者会极其困难。要求所有事件驱动组件使用分布式追踪和标准化告警。
• “事件风暴”分析陷入僵局：
  • 缓解措施：事件风暴研讨会很有价值，但管理不当时可能会变得低效。为建模会议设置时间限制，并优先聚焦高价值业务场景。

具体组件

描述此范式的实现通常会包含的工具和抽象的词汇表。这些不是依赖项，也不是 tools: frontmatter。

• message-broker：Kafka、NATS、RabbitMQ；生产者与消费者之间的持久化通道
• event-stream-processor：Flink、Faust 或类似工具；消费数据流并发出派生事件
• distributed-tracing：跨异步跳转的 OpenTelemetry 风格关联 ID

退出标准

• 已生成 ADR，记录事件分类、所选代理技术、命名约定、版本控制策略和数据保留设置。
• 已建立集中的架构仓库或注册表，并配置 CI 验证，阻止未注册的事件架构进入生产环境。
• 在部署任何消费者之前，已为每个消费者指定死信队列（DLQ）配置和重试策略。
• 可观测性仪表板至少涵盖：消费者滞后、消息吞吐量、架构验证失败率和 DLQ 深度。