一、事件驱动架构基础：事件驱动概念、与传统架构对比、适用场景分析

做量化交易系统这么多年，我越来越觉得——架构选型，本质上是在选一种“世界观”。你如何看待市场？市场是静止的，还是流动的？数据是拉来的，还是推来的？

我个人习惯把事件驱动架构叫做“推模式”。说白了，就是系统不主动去问“你有没有新数据？”，而是等着数据自己找上门来。嗯，这听起来有点懒，但恰恰是这种“懒”，让系统变得异常高效。

1.1 什么是事件驱动？

先别急着看定义。我举个例子你就明白了。

假设你在监控一只股票的价格。传统做法是：你每隔1秒去查一次数据库，“价格变了吗？”。这叫轮询。事件驱动的做法是：你告诉系统，“价格变了就通知我”。这叫订阅。

在量化交易里，事件可以是：

• 行情Tick到达
• 订单成交回报
• 风控阈值触发
• 策略信号生成
• 系统心跳超时

每个事件都是一个“消息”。系统里各个模块之间，不直接调用对方的方法，而是通过事件总线来通信。我刚开始做交易系统时，总觉得这种“绕一圈”的方式多此一举。直到有一次，我需要同时接入三个交易所的数据，还要跑五个策略——嗯，那时候我才明白，直接调用的方式根本撑不住。

1.2 与传统架构的对比

这里我画了一张对比图，帮你快速建立直观印象。

这张图其实已经说得很清楚了。我再补充几个关键差异点：

对比维度	传统架构（轮询）	事件驱动架构
通信方式	模块间直接调用，或轮询数据库	通过事件总线异步通信
耦合度	高耦合，一个模块改了，其他模块也得改	低耦合，模块只关心自己订阅的事件
资源消耗	大量无效轮询，CPU和IO浪费严重	按需触发，资源利用率高
扩展性	加一个新模块，可能要改一堆代码	加一个新模块，注册订阅即可
实时性	取决于轮询间隔，有延迟	事件到达即处理，延迟低
调试难度	调用链清晰，容易追踪	事件流复杂，需要专门的追踪工具

1.3 适用场景分析

不是所有场景都适合事件驱动。我见过有人把简单的CRUD系统也硬套事件驱动，结果代码写得跟蜘蛛网一样。这里我总结了几类适合和不适合的场景：

✅ 适合事件驱动的场景

• 实时行情处理：每秒成千上万的Tick数据，必须推送到策略模块。轮询？不存在的。
• 订单状态机：订单从“已提交”到“部分成交”到“全部成交”，每个状态变化都是一个事件。
• 多策略并行：多个策略订阅同一行情源，事件总线天然支持一对多分发。
• 风控拦截：某个策略触发了风控规则，需要立即通知执行模块撤单。
• 日志与监控：所有事件都可以被监控模块捕获，用于实时看板和事后分析。

❌ 不适合事件驱动的场景

• 简单的增删改查：比如用户管理、配置管理，用REST API就够了。
• 强一致性要求：比如资金结算，需要事务保证。事件驱动的最终一致性模型在这里会出问题。
• 小规模系统：如果只有两三个模块，事件总线的引入反而增加了复杂度。

1.4 事件驱动在量化交易中的典型流程

说了这么多理论，我们来看一个实际的流程。假设你有一个简单的趋势跟踪策略：

// 伪代码：事件驱动流程
1. 行情网关收到交易所的Tick数据
2. 行情网关将Tick包装为 MarketDataEvent，发布到事件总线
3. 策略模块订阅了 MarketDataEvent，收到后计算指标
4. 策略模块生成 BuySignalEvent，再次发布到事件总线
5. 执行模块订阅了 BuySignalEvent，组装订单并发送到交易所
6. 交易所返回 OrderFilledEvent，执行模块更新本地状态
7. 风控模块订阅了所有事件，实时检查风险指标

你看，整个过程没有一个模块直接调用另一个模块。每个模块只做两件事：订阅自己关心的事件，处理完后发布新的事件。这就是事件驱动的精髓。

我个人习惯把这种模式叫做“流水线”。每个模块就像流水线上的一个工位，事件就是传送带上的零件。工位之间互不干扰，但整个流水线却能高效运转。

1.5 小结

事件驱动架构的核心，其实就是四个字：发布-订阅。它让系统从“你问我答”变成了“你说我听”。在量化交易这个场景里，市场本身就是一个永不停止的事件流——你想想看，还有什么架构比事件驱动更适合呢？

嗯，这一章先讲到这里。下一章我们会深入事件总线的具体实现，包括内存队列、消息中间件、以及如何保证事件不丢失。到时候我会分享一些我在生产环境中踩过的坑，保证让你少走弯路。

---

公众号:蓝海资料掘金营，微信deep3321