1. 事件驱动架构概述
大家好，我是老张。今天咱们聊聊事件驱动架构——这个在圈子里被炒得火热，但真正用明白的人其实不多的东西。
我最早接触事件驱动，是在做一个电商订单系统的时候。那时候系统越做越复杂，一个下单操作要同步调用库存、支付、物流、积分……十几个服务串在一起，改一个环节就得重新部署整个链路。说实话，那段时间我做梦都在改代码。
后来我意识到，很多业务动作其实不需要「立刻知道结果」。比如用户下单后，库存扣减晚几秒有什么关系？积分累积晚几分钟又怎样？这就是事件驱动思想的萌芽。
什么是事件驱动架构
事件驱动架构，说白了就是「发生了什么事，就通知相关方去处理」。它不像传统架构那样，A调用B，B调用C，而是A发布一个事件，谁感兴趣谁自己去订阅。
举个例子：用户下单后，系统发布一个「订单已创建」事件。库存服务、支付服务、物流服务各自订阅这个事件，然后并行处理自己的逻辑。互不干扰，各干各的。
核心思想：生产者不关心谁消费了事件，消费者也不关心事件是谁产生的。双方通过事件总线解耦。
我个人习惯把事件驱动架构比作「微信群聊」。你发一条消息，群里所有人各自决定要不要回复、什么时候回复。而不是你挨个打电话通知每个人。
与传统架构的对比
传统架构，尤其是微服务刚兴起那会儿，大家都喜欢用同步RPC调用。A服务调B服务，B服务调C服务，形成一条长长的调用链。
这种模式有什么问题？我踩过不少坑：
- 耦合太紧：下游服务挂了，上游也跟着挂。我曾经因为物流服务宕机，导致整个下单链路瘫痪了半小时。
- 性能瓶颈：整个链路的响应时间取决于最慢的那个服务。你想想看，一个下单操作要等库存、支付、物流全部返回，用户不骂娘才怪。
- 扩展困难：想加一个新功能，比如下单后发送短信通知，你得改下单服务的代码，重新部署。这合理吗？
事件驱动架构正好解决了这些问题：
| 对比维度 | 传统同步架构 | 事件驱动架构 |
|---|---|---|
| 耦合度 | 强耦合，调用方依赖被调用方 | 松耦合，通过事件总线通信 |
| 响应时间 | 取决于最慢的服务 | 异步处理，主流程快速返回 |
| 扩展性 | 需要修改调用方代码 | 新增订阅者即可，无需修改生产者 |
| 容错性 | 下游故障导致上游失败 | 事件持久化，下游恢复后可重试 |
| 可观测性 | 调用链清晰，但排查复杂 | 事件流可追溯，但需要额外工具 |
注意：事件驱动不是银弹。如果你的业务场景要求强一致性、实时响应，传统同步架构可能更合适。我曾经在一个金融交易系统里强行用事件驱动，结果对账对到怀疑人生。
核心概念：事件、命令、消息
这三个概念经常被混淆，我简单梳理一下：
- 事件（Event）：表示「已经发生的事情」。比如「订单已创建」、「支付已完成」。事件是不可变的，过去就过去了。
- 命令（Command）：表示「要求做某事」。比如「创建订单」、「扣减库存」。命令通常有明确的接收方。
- 消息（Message）：是事件和命令的载体。它可以是JSON、XML、Protobuf等格式。
嗯，这里要注意：事件和命令的区别在于「时态」。事件是过去时，命令是将来时。我在项目中见过不少人把命令当事件发，结果消费者不知道是该执行还是该记录。
我的建议：命名规范很重要。事件用过去分词，比如 OrderCreated、PaymentCompleted；命令用动词原形，比如 CreateOrder、DeductInventory。这样一看就明白。
应用场景分析
事件驱动架构适合哪些场景？我根据自己的实战经验，总结了几类：
- 跨服务数据同步：比如用户信息变更后，通知所有下游服务更新缓存。我曾经用事件驱动同步用户数据，从原来的分钟级延迟降到了秒级。
- 业务流程编排：比如订单创建后，依次触发库存检查、支付、物流、积分累积。每个步骤独立部署，互不影响。
- 日志和审计：所有操作都发布事件，方便后续追溯。我在金融项目里就是这么做的，审计人员查起来特别方便。
- 实时通知：比如用户下单后，发送短信、邮件、App推送。这些操作不需要同步等待结果。
- 系统解耦：新旧系统迁移时，事件驱动可以充当「胶水」。老系统发布事件，新系统订阅，逐步替换。
下面这张图展示了事件驱动架构的核心流程，我画了很久才满意：
你看这张图，生产者只管发布事件，消费者各自订阅自己感兴趣的事件。互不干扰，各干各的。这就是事件驱动架构的精髓。
避坑指南：我曾经在一个项目里，把所有业务逻辑都塞进事件处理器，结果事件流变得极其复杂，一个事件触发十几个下游事件，最后根本没法排查。记住：事件驱动是用来解耦的，不是用来制造混乱的。保持事件粒度适中，别搞成「事件风暴」。
好了，这一章就到这里。事件驱动架构的核心思想其实不复杂，难的是在实际项目中用好它。后面几章我会结合具体案例，一步步带大家落地。