1. 事件驱动架构概述
各位同学，咱们今天聊聊事件驱动架构。说实话，这个架构模式在流计算领域太重要了。我做了十几年大数据，从最早的批处理到现在的实时流计算，事件驱动架构几乎贯穿了所有现代系统的设计。
先问大家一个问题：你平时写业务代码，是不是习惯一个请求进来，立刻返回一个响应？这种模式叫请求-响应模式。但事件驱动不一样——它不直接响应请求，而是等事件发生，然后异步处理。嗯，这里要注意，这个区别很关键。
1.1 事件驱动架构定义
事件驱动架构，说白了就是：系统里各个组件不直接调用对方，而是通过「事件」来通信。一个组件产生事件，另一个组件消费事件，中间通过事件总线传递。
举个例子。我在做电商平台时，用户下单后需要做库存扣减、积分发放、物流通知。如果用传统方式，下单服务要依次调用三个服务，耦合度高不说，一个挂了全崩。换成事件驱动后，下单服务只管发一个「订单已创建」事件，其他服务自己去订阅处理。爽多了。
核心定义：事件驱动架构是一种软件架构模式，其中系统组件通过产生、检测、消费事件来进行通信，而不是通过直接的方法调用或远程过程调用。
事件驱动架构有几个关键特征：
- 异步通信——生产者发完事件就走，不等待消费者处理
- 松耦合——生产者和消费者互不知道对方存在
- 可扩展性——可以随时增加新的消费者，不影响现有系统
- 容错性——某个消费者挂了，不影响其他组件
1.2 事件驱动架构与微服务的关系
很多人问我：事件驱动和微服务是不是一回事？其实不是，但它们天生一对。
微服务架构强调把系统拆成多个独立服务，每个服务有自己的数据库和业务逻辑。但问题来了——服务之间怎么通信？传统做法是用 REST API 同步调用。你想想看，如果 A 调用 B，B 调用 C，C 又调用 D，这链条一长，延迟和故障率都上去了。
事件驱动架构正好解决了这个问题。它让微服务之间通过事件异步通信，每个服务只管自己的事。
| 对比维度 | 同步REST调用 | 事件驱动通信 |
|---|---|---|
| 耦合度 | 高（调用方依赖被调用方） | 低（双方只依赖事件格式） |
| 响应时间 | 受最慢服务影响 | 生产者立即返回 |
| 容错性 | 链中一个挂，全链失败 | 消费者可独立重试或降级 |
| 扩展性 | 需要修改调用方代码 | 新增消费者无需修改生产者 |
| 数据一致性 | 强一致（但性能差） | 最终一致（但性能好） |
我的建议：新项目如果选型微服务，优先考虑事件驱动通信。但要注意，不是所有场景都适合异步。比如支付扣款这种需要强一致性的操作，还是得用同步事务或分布式事务方案。
1.3 事件驱动架构核心组件
事件驱动架构有三个核心角色：事件生产者、事件消费者、事件总线。咱们一个一个说。
1.3.1 事件生产者
事件生产者就是产生事件的组件。它不关心谁会消费这个事件，也不关心消费结果。生产者的职责很简单：检测到业务状态变化，封装成事件，发给事件总线。
常见的生产者包括：
- 用户操作（点击、下单、支付）
- 系统监控（CPU 超阈值、磁盘满）
- 外部系统回调（支付回调、物流状态更新）
- 定时任务（每天凌晨生成报表事件）
我在项目中遇到过一个问题：生产者发事件太快，把事件总线打爆了。后来加了限流和背压机制才解决。这个后面讲窗口计算时会详细说。
1.3.2 事件消费者
事件消费者订阅感兴趣的事件类型，收到事件后执行对应的业务逻辑。消费者可以是一个，也可以是多个——这就是事件驱动的「广播」能力。
消费者有几个关键设计点：
- 幂等性——同一个事件处理多次，结果必须一致。我曾经因为没做幂等，导致用户积分被重复发放，被业务方追着骂了一周。
- 顺序性——有些场景要求事件按顺序处理（比如先下单后取消）。Kafka 的分区机制可以保证分区内有序。
- 失败重试——消费者处理失败时，要能重试或进入死信队列。
1.3.3 事件总线
事件总线是连接生产者和消费者的中间件。它负责事件的存储、路由、分发。选型时主要看吞吐量、持久化能力、延迟和可用性。
常见的事件总线有：
| 组件 | 特点 | 适用场景 |
|---|---|---|
| Apache Kafka | 高吞吐、持久化、分区有序 | 日志采集、流计算、事件溯源 |
| RabbitMQ | 低延迟、灵活路由、支持多种协议 | 任务队列、RPC、微服务通信 |
| Apache Pulsar | 分层存储、多租户、地理复制 | 云原生、跨机房部署 |
| AWS SQS/SNS | 全托管、自动扩缩容 | 云上轻量级事件处理 |
避坑指南：我曾经选型时只看吞吐量，选了 Kafka 做所有事件总线。结果发现有些场景需要延迟低于 10ms，Kafka 的批量刷盘机制根本满足不了。后来混用了 RabbitMQ 做低延迟通道，Kafka 做高吞吐通道。记住：没有银弹，要根据场景选型。
1.4 事件驱动架构核心流程
下面这张图展示了事件驱动架构的完整流程。我建议你仔细看看，理解每个组件之间的协作关系。
这个流程看起来简单，但实际落地时坑不少。比如事件格式怎么定义？事件丢失怎么办？重复事件怎么处理？这些我们后面章节会逐一展开。
1.5 事件驱动架构的优缺点
任何架构都有两面性。我用了这么多年事件驱动，总结一下它的优缺点。
优点
- 松耦合——改一个服务不影响其他服务，爽
- 高扩展性——加消费者就像加插座一样简单
- 异步处理——用户体验好，不用等
- 事件溯源——所有事件都存着，可以回溯历史状态
缺点
- 调试困难——事件流一长，出问题很难定位。我曾经花了两天查一个事件丢失的问题，最后发现是序列化配置错了。
- 最终一致性——不是强一致，有些业务场景不适用
- 事件版本管理——事件格式变了，老消费者可能崩
- 运维复杂度——需要维护消息中间件集群
我的经验：事件驱动架构不是银弹。如果你的业务逻辑简单、调用链短，用 REST 反而更直接。但如果你要做流计算、实时分析、或者系统需要高扩展性，事件驱动是绕不开的选择。