1. 事件驱动架构概述：从轮询到事件驱动
大家好，我是老张。做了十几年消息中间件，今天咱们聊聊事件驱动架构。说实话，这个概念被炒了很多年，但真正用好的团队并不多。我见过太多项目，号称用了事件驱动，结果代码写得比轮询还糟糕。
先别急着上代码。咱们得搞清楚一件事：事件驱动到底解决了什么问题？
1.1 从轮询说起
轮询，说白了就是“主动去问”。你写个循环，每隔几秒去查一下数据库，看看有没有新订单。代码大概长这样：
while (true) {
List<Order> orders = orderDao.findNewOrders();
for (Order order : orders) {
processOrder(order);
}
Thread.sleep(5000); // 每5秒查一次
}有什么问题？我列几个：
- 浪费资源：大部分时间查到的都是空结果，CPU和IO白白消耗
- 延迟不可控：最坏情况要等5秒才能处理新订单
- 负载波动大：高峰期查到的数据多，处理不过来；空闲期又空转
我曾经踩过的坑：有个电商项目，用轮询查订单，每秒查一次。平时没问题，双十一流量上来，数据库连接池直接被打满。DBA半夜打电话骂人。后来改成事件驱动，数据库压力降了80%。
1.2 事件驱动的核心思想
事件驱动的思路完全反过来——别主动问，等通知。系统里发生什么事（订单创建、支付成功、库存变更），就发一个事件。谁关心这个事件，谁自己去订阅。
用代码表达就是：
// 生产者：订单创建后发布事件
eventBus.publish(new OrderCreatedEvent(orderId, userId, amount));
// 消费者：订阅事件，收到后处理
eventBus.subscribe(OrderCreatedEvent.class, event -> {
sendNotification(event.getUserId());
updateInventory(event.getOrderId());
// ... 其他处理
});你看，生产者不用关心谁在处理，消费者也不用轮询。各干各的，解耦了。
1.3 核心概念速览
我习惯把事件驱动架构拆成四个角色：
| 角色 | 职责 | 类比 |
|---|---|---|
| 事件 | 描述“发生了什么”的数据结构 | 快递包裹 |
| 生产者 | 产生并发布事件 | 发件人 |
| 消费者 | 订阅并处理事件 | 收件人 |
| 通道 | 事件传输的管道（消息队列/总线） | 快递运输网络 |
嗯，这里要注意：事件是不可变的。一旦发布，就不能修改。你想想看，如果事件能被改，那消费者拿到的数据到底算谁的？
1.4 事件驱动 vs 传统架构
我整理了一张对比表，方便你理解差异：
| 维度 | 轮询/同步调用 | 事件驱动 |
|---|---|---|
| 耦合度 | 高（调用方依赖被调用方） | 低（双方只依赖事件契约） |
| 延迟 | 取决于轮询间隔 | 接近实时（毫秒级） |
| 资源利用率 | 低（大量空轮询） | 高（按需触发） |
| 扩展性 | 线性扩展困难 | 天然支持水平扩展 |
| 故障隔离 | 调用链断裂影响全局 | 消费者故障不影响生产者 |
| 调试难度 | 低（调用链路清晰） | 高（异步追踪复杂） |
我的建议：不要为了用事件驱动而用。如果你的系统只有两三个服务，同步调用更简单。事件驱动适合的是“多个服务需要响应同一个业务动作”的场景。
1.5 事件驱动架构的核心优势
说白了，事件驱动最大的好处就三个：
- 解耦：生产者和消费者互不知道对方存在。我可以在不通知任何人的情况下，新增一个消费者。
- 弹性：消费者挂了，事件还在队列里。等它恢复，继续处理。不会丢数据。
- 异步：生产者发布事件后立刻返回，不用等消费者处理完。系统吞吐量大幅提升。
我记得有个支付系统，原来同步调用，每秒只能处理500笔。改成事件驱动后，峰值到了8000笔。为什么？因为支付网关的响应时间从50ms变成了2ms（发布事件就返回），剩下的交给消费者异步处理。
1.6 适用场景分析
不是所有场景都适合事件驱动。我根据实战经验，给你画个判断标准：
适合用事件驱动的场景：
- 一个业务动作需要触发多个后续操作（如：下单后发短信、扣库存、更新积分）
- 系统需要高吞吐、低延迟（如：实时风控、交易撮合）
- 服务之间需要解耦，独立部署和扩展
- 业务流程需要异步化，避免阻塞主链路
不适合用事件驱动的场景：
- 需要强一致性的金融交易（如：转账扣款必须同步完成）
- 业务流程简单，只有两三个服务
- 团队对异步编程不熟悉，调试能力弱
- 事件顺序敏感且难以补偿的业务
1.7 事件驱动架构全景图
下面这张图，是我自己画的事件驱动架构核心流程。你看一眼，就能明白整体脉络：
你看这个流程：生产者发布事件，事件进入通道，通道把事件分发给所有订阅的消费者。每个消费者独立处理，互不干扰。这就是事件驱动的精髓。
1.8 本章小结
事件驱动架构，说白了就是从“主动问”变成“等通知”。它解决了轮询的资源浪费和延迟问题，让系统更解耦、更弹性、吞吐更高。
但别急着上。我见过太多团队，一上来就上Kafka，结果连基本的事件契约都没定义清楚。最后代码写得比同步调用还乱。