核心概念解析：事件模型的五大基石

说实话，很多同学刚开始接触事件驱动设计时，最头疼的就是这几个概念傻傻分不清。事件、事件源、处理器、总线、流——听起来都差不多，但实际用起来差远了。我当年带团队重构一个电商订单系统时，就因为没搞清楚这些概念，差点把整个架构搞崩了。

今天咱们就把这五个核心概念掰开揉碎，一个一个讲清楚。

事件（Event）—— 发生了什么

事件，说白了就是「已经发生的事情的记录」。它不是指令，不是请求，而是一个事实。

举个例子：用户下单这件事，在传统架构里你会写一个 createOrder() 方法，直接操作数据库。但在事件驱动里，你发布的是一个 OrderCreated 事件，里面只记录「谁在什么时间下了什么单」。

事件的核心特征：

  • 不可变性——事件一旦发生，就不能修改。我见过有人试图去改已发布的事件，结果整个系统的审计对不上账，那叫一个惨。
  • 自描述性——事件本身要包含足够的信息，让消费者不需要去查别的数据就能理解发生了什么。
  • 时间戳——每个事件都必须有发生时间，这是事件排序和溯源的基础。
// 一个典型的事件结构
{
  "eventId": "evt_20240315_001",
  "eventType": "OrderCreated",
  "timestamp": "2024-03-15T10:30:00Z",
  "source": "order-service",
  "data": {
    "orderId": "ORD-20240315-001",
    "userId": "user_12345",
    "totalAmount": 299.00,
    "items": [
      {"productId": "P001", "quantity": 2, "price": 149.50}
    ]
  }
}

我的习惯：事件类型命名用过去分词，比如 OrderCreated、PaymentProcessed、ShipmentDelivered。这样一眼就能看出这是个已经发生的事实，而不是一个待办任务。

事件源（Event Source）—— 谁产生的

事件源就是产生事件的实体。它可以是用户操作、系统定时任务、外部系统回调，甚至是另一个事件处理器的输出。

我在项目中遇到过一个问题：两个服务互相发送事件，结果形成了死循环。A 发了事件，B 处理后又发事件给 A，A 再处理又发回给 B……最后整个消息队列被撑爆了。这就是没搞清楚事件源的责任边界。

事件源类型 典型例子 注意事项
用户行为 点击按钮、提交表单 需要做防抖和限流
系统内部 定时任务、状态变更 避免循环触发
外部系统 支付回调、第三方通知 做好幂等和重试
设备/IoT 传感器数据、设备状态 注意数据量和频率

我曾经踩过的坑：在事件源里直接写业务逻辑。比如在用户点击「下单」按钮时，不仅发布了 OrderCreated 事件，还顺带扣了库存、发了短信。结果后来要加一个「后台代下单」的功能，发现这些逻辑全耦合在按钮点击事件里，根本复用不了。

记住：事件源只负责「发布事实」，不负责「处理后果」。

事件处理器（Handler）—— 谁来响应

处理器就是监听事件并做出反应的组件。一个事件可以有多个处理器，也可以一个都没有——这完全取决于业务需求。

你想想看，在传统架构里，一个方法被调用就必须执行完。但在事件驱动里，处理器可以自由选择「要不要处理」以及「怎么处理」。这种松耦合的设计，让系统的扩展性大大提升。

// 一个典型的事件处理器
public class OrderCreatedHandler implements EventHandler<OrderCreated> {
    
    @Override
    public void handle(OrderCreated event) {
        // 1. 验证事件完整性
        if (!event.validate()) {
            log.warn("收到无效事件: {}", event.getEventId());
            return;
        }
        
        // 2. 执行自己的业务逻辑
        inventoryService.reserveStock(event.getData().getItems());
        notificationService.sendOrderConfirmation(event.getData().getUserId());
        
        // 3. 记录处理结果
        eventStore.save(event);
    }
}

处理器的设计原则：

  • 单一职责——一个处理器只做一件事。比如「发邮件」和「更新库存」应该拆成两个处理器。
  • 幂等性——同一个事件被处理多次，结果应该一样。我见过因为网络重试导致用户收到 3 封确认邮件的惨案。
  • 无状态——处理器不应该依赖内存中的状态，所有状态都应该从事件或外部存储中获取。

事件总线（Event Bus）—— 怎么传递

事件总线就是事件的「高速公路」。它负责把事件从源头发送到所有感兴趣的处理器手里。

说白了，总线解决的是「谁跟谁通信」的问题。没有总线，每个服务都要知道其他所有服务的地址，那跟点对点耦合没什么区别。

我习惯把事件总线分为三种模式：

模式 特点 适用场景 典型实现
内存总线 进程内、低延迟 单体应用、微服务内部 Guava EventBus、Spring ApplicationEvent
消息队列 跨进程、持久化 微服务间通信、异步任务 RabbitMQ、Kafka、RocketMQ
事件存储 持久化、可回溯 事件溯源、审计日志 EventStoreDB、自建事件表

我的建议：刚开始做事件驱动时，别一上来就上 Kafka。先用内存总线把逻辑跑通，等确实需要跨服务通信了再升级。我见过太多团队在单体阶段就上了 Kafka，结果运维成本比业务开发还高。

事件流（Event Stream）—— 按什么顺序

事件流，就是事件按时间顺序排列形成的序列。它解决的是「事件之间的时序关系」问题。

为什么要关心顺序？你想想看：如果「用户下单」事件和「用户取消订单」事件到达的顺序乱了，系统先处理了取消，再处理下单——那库存就全乱了。

事件流有几个关键特性：

  • 有序性——同一个事件源的事件必须保持顺序。不同事件源之间可以乱序。
  • 分区性——按业务维度分区，比如按用户 ID 哈希，保证同一个用户的事件都在同一个分区里。
  • 可回溯——可以从流的起点重新播放所有事件，这是事件溯源的基础能力。
// 事件流的分区策略示例
// 按用户 ID 取模，保证同一个用户的事件顺序一致
int partition = Math.abs(userId.hashCode()) % PARTITION_COUNT;

// 生产者发送时指定分区
producer.send(new ProducerRecord<>("order-events", partition, 
    userId.toString(), event));

我曾经犯过的错：在设计事件流时没考虑分区键的均衡性。用了订单 ID 做分区键，结果大客户一个订单有几百个商品，全挤在一个分区里，其他分区闲得发慌。后来改成按用户 ID 加时间戳的组合键，才把负载均衡了。

五大概念的关系图

说了这么多，咱们用一张图把关系理清楚：

事件驱动五大核心概念关系图 事件源 Event Source 事件 Event 事件总线 Event Bus 事件处理器 Handler 事件流 Event Stream 产生 发布到 分发 持久化 回溯消费 💡 事件源产生事件 → 事件发布到总线 → 总线分发给处理器，同时持久化到事件流 → 处理器可回溯消费事件流

小结一下

这五个概念其实是一个完整的链路：

  • 事件源负责「感知发生了什么」
  • 事件负责「记录发生了什么」
  • 事件总线负责「传递发生了什么」
  • 事件处理器负责「响应发生了什么」
  • 事件流负责「保存发生了什么」
← 上一章 📖 返回目录 下一章 →