事件驱动架构：从“轮询”到“响应”的思维转变
我记得刚入行那会儿，做的是一个电商后台系统。订单状态变了，怎么办？最简单粗暴的方式——每隔几秒查一次数据库。嗯，这就是典型的“轮询”模式。后来系统用户量上来，数据库扛不住了，DBA 天天找我喝茶。
那时候我就想：能不能让系统主动告诉我“订单变了”，而不是我一遍遍去问？这就是事件驱动架构的雏形。说白了，事件驱动就是让系统里的各个模块，通过“事件”来沟通，而不是通过“方法调用”。
事件驱动架构的核心概念
事件驱动架构（Event-Driven Architecture，EDA）是一种软件架构模式。它的核心思想是：组件之间不直接调用，而是通过事件进行异步通信。
我习惯把事件驱动架构拆成三个角色：
- 事件生产者（Producer）：负责发布事件。比如订单服务在订单创建后，发布一个“OrderCreated”事件。
- 事件通道（Channel）：负责传递事件。常见的有消息队列（Kafka、RabbitMQ）或事件总线。
- 事件消费者（Consumer）：负责处理事件。比如库存服务收到“OrderCreated”事件后，扣减库存。
你想想看，这种模式最大的好处是什么？解耦。生产者不需要知道谁在消费事件，消费者也不需要知道事件从哪来。大家只关心事件本身。
核心要点：事件驱动架构的本质，是把“请求-响应”的同步模型，转变为“发布-订阅”的异步模型。这能显著提升系统的伸缩性和容错性。
我在项目中遇到过这样一个场景：用户注册后，需要发送欢迎邮件、初始化用户空间、记录审计日志。如果用同步调用，注册接口的响应时间会很长。改用事件驱动后，注册服务只发布一个“UserRegistered”事件，其他服务异步处理，用户体验瞬间提升。
事件溯源（Event Sourcing）
事件溯源，这个名字听起来有点唬人。其实说白了就是：不存当前状态，只存状态变更的历史事件。
传统做法是：用户账户余额是100元，消费20元后，直接更新为80元。事件溯源的做法是：记录一条“消费20元”的事件。要查当前余额？把该账户的所有事件重放一遍，就能算出来。
为什么会有人用这么“麻烦”的方式？因为事件溯源有几个杀手级优势：
- 完整的审计日志：每一个状态变更都有记录，谁、什么时间、做了什么，一目了然。
- 时间旅行：可以回溯到任意历史时刻的状态。调试Bug时特别有用。
- 事件重放：如果发现Bug，修复后可以重放历史事件，重建正确的状态。
避坑指南：我曾经在一个金融项目中过度使用事件溯源，结果发现事件数量增长极快，重放耗时越来越长。后来我学乖了：事件溯源适合需要完整审计的场景，但别忘了做“快照”（Snapshot）。定期把当前状态存下来，重放时从最近的快照开始，而不是从头开始。
下面是一个简单的事件溯源示例（伪代码）：
// 事件定义
class AccountCreated {
constructor(accountId, initialBalance) { ... }
}
class MoneyDeposited {
constructor(accountId, amount) { ... }
}
class MoneyWithdrawn {
constructor(accountId, amount) { ... }
}
// 事件存储
class EventStore {
events = [];
save(event) {
this.events.push(event);
}
getEvents(accountId) {
return this.events.filter(e => e.accountId === accountId);
}
}
// 通过重放事件重建状态
function replayEvents(events) {
let balance = 0;
for (let event of events) {
if (event instanceof AccountCreated) {
balance = event.initialBalance;
} else if (event instanceof MoneyDeposited) {
balance += event.amount;
} else if (event instanceof MoneyWithdrawn) {
balance -= event.amount;
}
}
return balance;
}CQRS模式：读写分离的终极形态
CQRS 是 Command Query Responsibility Segregation 的缩写。翻译过来就是“命令查询职责分离”。
我个人的理解是：把“写数据”和“读数据”彻底分开。写操作走命令模型，读操作走查询模型，两者使用不同的数据模型，甚至不同的数据库。
你可能会问：有必要搞得这么复杂吗？嗯，这要看场景。在传统CRUD系统中，读写用的是同一个数据模型。但当系统复杂到一定程度，读和写的需求会严重冲突。
举个例子：写操作需要强一致性，读操作需要高性能。如果共用同一个数据库，写操作加锁会影响读性能，读操作的复杂查询又拖慢写操作。CQRS 就是来解决这个矛盾的。
| 维度 | 命令模型（写） | 查询模型（读） |
|---|---|---|
| 数据模型 | 面向业务逻辑，通常用领域模型 | 面向展示，通常用扁平化DTO |
| 数据库 | 可用关系型数据库（保证ACID） | 可用NoSQL、缓存、搜索引擎 |
| 一致性 | 强一致性 | 最终一致性 |
| 扩展性 | 垂直扩展为主 | 水平扩展为主 |
提示：CQRS 和事件溯源是天然搭档。事件溯源负责记录命令侧的事件，CQRS 负责构建查询侧的投影（Projection）。我习惯的做法是：命令侧用事件溯源，查询侧用专门的读模型，通过事件同步数据。
三者如何协同工作？
事件驱动架构、事件溯源、CQRS，这三者经常一起出现。它们的关系是这样的：
- 事件驱动架构是通信机制，负责事件的生产、传递和消费。
- 事件溯源是持久化策略，负责把事件作为真理源（Source of Truth）。
- CQRS是读写分离模式，负责优化查询性能。
下面这张图展示了它们如何协同工作：
从图中可以看到：用户发送命令，命令处理器把事件保存到事件存储，同时发布到事件总线。投影器消费事件，更新读模型。用户查询时，直接从读模型获取数据，完全不经过命令侧。
关键洞察：这种架构下，命令侧和查询侧可以独立扩展。如果读压力大，可以增加读模型的副本；如果写压力大，可以优化命令处理器的性能。两者互不影响。
实际项目中的取舍
说实话，不是所有项目都需要事件溯源和CQRS。我个人的经验是：
- 简单CRUD系统：用传统架构就够了，别过度设计。
- 需要完整审计日志的系统（如金融、医疗）：事件溯源是很好的选择。
- 读写负载差异巨大的系统（如电商、社交）：CQRS能帮你优化性能。
- 微服务架构：事件驱动几乎是标配，服务间通过事件通信。
曾经踩过的坑：我在一个项目中同时引入了事件溯源和CQRS，但忽略了事件版本管理。后来事件结构变了，旧事件重放时直接报错。从那以后，我养成了一个习惯：每个事件都带版本号，重放时做版本兼容处理。
事件驱动架构不是银弹，但它确实解决了很多传统架构解决不了的问题。理解它的核心概念，知道什么时候该用、什么时候不该用，这才是架构师的价值所在。