1. 事件驱动架构概述
说实话，事件驱动架构（Event-Driven Architecture，EDA）这个概念，我在刚入行那会儿总觉得有点玄乎。不就是「发生了一件事，然后通知别人去处理」吗？后来真正在跨端项目里踩过坑，才明白这里面门道不少。
今天咱们就从头捋一捋。什么是事件驱动？它到底好在哪、坑在哪？什么场景下该用它？
1.1 什么是事件驱动
事件驱动，说白了就是一种「被动响应」的编程范式。系统不主动轮询、不主动调用，而是等着某个「事件」发生，然后触发对应的处理逻辑。
举个例子你就明白了：
- 传统方式：你每隔 5 秒去检查一下邮箱，看有没有新邮件。这叫轮询。
- 事件驱动方式：邮箱系统有新邮件时，主动给你发个通知。你收到通知再去处理。
在软件架构里，事件驱动的核心角色有三个：
| 角色 | 职责 | 类比 |
|---|---|---|
| 事件生产者 | 检测或产生事件，并发布出去 | 邮局发现新邮件 |
| 事件通道 | 负责事件的传递、路由、缓冲 | 邮递员送信 |
| 事件消费者 | 订阅感兴趣的事件，收到后执行逻辑 | 你收到信后拆开看 |
这三个角色之间是松耦合的。生产者不知道谁在消费，消费者也不关心谁生产的。它们只通过「事件」这个载体沟通。
关键理解：事件驱动不是「回调函数」那么简单。它是一种架构思想，强调的是异步、非阻塞、解耦。你想想看，如果每个事件都要同步等待结果，那跟直接调用函数有什么区别？
下面这张图能帮你快速建立整体认知：
1.2 事件驱动架构的优缺点
任何架构都不是银弹。我在好几个项目里都见过「为了事件驱动而事件驱动」的情况，结果反而把系统搞复杂了。咱们客观聊聊它的优缺点。
优点
- 松耦合：生产者和消费者不需要知道对方的存在。改一个模块，不影响另一个。我在重构一个老项目时，把硬编码的调用改成事件驱动后，改动的范围缩小了 70%。
- 可扩展性：想加新功能？直接注册一个新消费者就行，不用改现有代码。这在大团队协作时特别爽。
- 异步处理：事件发布后，生产者不用等消费者处理完。用户体验更好，系统吞吐量也上去了。
- 故障隔离：一个消费者挂了，不会影响其他消费者和生产者。我曾经遇到过日志服务宕机，但核心业务完全没受影响，就是因为它们通过事件通道解耦了。
缺点
- 调试困难：事件流是异步的，你很难追踪「这个事件是谁发的？谁处理了？处理结果如何？」。我刚开始用事件驱动时，经常为了查一个 bug 翻遍所有消费者代码。
- 一致性难保证：多个消费者处理同一个事件，如果其中一个失败，怎么回滚？分布式事务的复杂度会直线上升。
- 事件风暴风险：如果事件设计得不好，可能会产生「事件风暴」——一个事件触发另一个事件，形成连锁反应，最后系统崩溃。
- 调试工具链不成熟：相比传统的同步调用，事件驱动的调试工具和监控方案还比较薄弱。
避坑提醒：我曾经在一个项目中，把所有的业务逻辑都通过事件来驱动。结果事件数量爆炸，一个用户注册流程触发了 20 多个事件，调试时根本理不清顺序。后来我们定了规矩：只有跨模块、跨服务的交互才用事件，模块内部还是用函数调用。这个原则一直沿用到现在。
1.3 适用场景分析
不是所有场景都适合事件驱动。我总结了几类「天生适合」和「千万别用」的场景，你对照着看：
| 场景类型 | 推荐度 | 说明 |
|---|---|---|
| UI 交互响应 | ✅ 强烈推荐 | 点击、滚动、拖拽等，天然就是事件 |
| 跨端消息同步 | ✅ 强烈推荐 | Web、小程序、Native 之间通过事件通信 |
| 日志/监控采集 | ✅ 推荐 | 异步上报，不影响主流程 |
| 业务流程编排 | ⚠️ 谨慎使用 | 需要保证顺序和一致性的场景，事件驱动会增加复杂度 |
| 强一致性事务 | ❌ 不推荐 | 银行转账、库存扣减等，建议用传统同步方式 |
具体来说，我建议你在以下情况优先考虑事件驱动：
- 跨端统一交互：比如 Web 端和 Native 端都需要响应同一个用户操作，用事件驱动可以做到「一次发布，多处响应」。
- 插件化/可扩展系统：你希望第三方开发者能方便地接入你的系统，事件驱动是最优雅的方式。
- 高并发、低延迟场景：事件驱动天然支持异步，能有效提升系统吞吐量。
- 微服务/模块化架构：服务之间需要解耦，事件驱动是标配。
我的经验：判断一个场景是否适合事件驱动，有个简单的方法——问自己「这个操作需要立即知道结果吗？」。如果需要，用同步调用；如果不需要，或者可以接受异步通知，那事件驱动就是好选择。
嗯，到这里事件驱动架构的概述就差不多了。你可能会问：「这些跟跨端事件模型有什么关系？」别急，后面我们会一步步深入。先把这个基础打牢，后面讲事件流、事件优先级、事件冒泡与捕获时，你才能理解为什么我们要这么设计。