1. 事件驱动架构概述
事件驱动架构（Event-Driven Architecture, EDA）是一种基于事件的产生、检测、消费和反应来构建系统的软件架构范式。在量化回测与灰度发布场景中，EDA 能够天然地模拟市场行情的非连续到达、订单的异步执行以及策略的实时响应，是构建高仿真回测引擎和灰度路由系统的核心基础。
1.1 核心组件
EDA 由四个核心组件构成，它们协同工作以完成事件的完整生命周期：
| 组件 | 定义 | 回测/灰度场景示例 |
|---|---|---|
| 事件（Event） | 系统中发生的、值得关注的状态变化。是不可变的事实记录。 | Tick 行情到达、订单被交易所确认、策略信号触发、灰度流量切换指令。 |
| 事件源（Event Source） | 产生事件的实体或系统。它只负责发布事件，不关心谁消费。 | 行情数据网关、回测数据回放器、用户操作界面、定时调度器。 |
| 事件处理器（Event Handler） | 订阅并处理特定类型事件的组件。每个处理器独立运行，只关注自己感兴趣的事件。 | 策略引擎（处理行情事件）、风控模块（处理订单事件）、灰度分流器（处理流量事件）。 |
| 事件总线（Event Bus） | 连接事件源与事件处理器的中间层，负责事件的传递、路由和分发。 | 内存队列（回测）、消息中间件如 Kafka/RabbitMQ（灰度生产环境）。 |
关键认知：在 EDA 中，事件源与事件处理器之间是完全解耦的。事件源不需要知道事件被谁处理，处理器也不需要知道事件来自哪里。这种松耦合特性使得系统可以灵活地添加、移除或替换处理器，而不会影响其他组件。
1.2 事件驱动架构 vs. 传统请求-响应模式
传统请求-响应模式（如 REST API、RPC）是同步的、点对点的通信方式；而 EDA 是异步的、多对多的通信方式。两者在核心设计理念上存在本质区别：
| 对比维度 | 传统请求-响应模式 | 事件驱动架构 |
|---|---|---|
| 通信方式 | 同步阻塞，调用方等待响应 | 异步非阻塞，发布后立即返回 |
| 耦合度 | 强耦合，调用方必须知道被调用方的地址和接口 | 松耦合，通过事件类型隐式连接 |
| 扩展性 | 垂直扩展为主，水平扩展需负载均衡 | 天然支持水平扩展，可独立增加处理器实例 |
| 错误处理 | 调用方直接捕获异常，重试逻辑复杂 | 事件可持久化、重放、死信队列处理 |
| 适用场景 | CRUD 操作、实时查询、用户交互 | 流式处理、异步任务、系统解耦、实时风控 |
实战启示：在量化回测中，如果使用传统请求-响应模式模拟撮合，每笔订单都需要等待交易所返回结果，这会导致回测速度严重受限于网络延迟。而采用 EDA，行情事件和订单事件可以异步地在事件总线上流转，回测引擎可以以内存速度处理数百万笔事件，实现毫秒级回测。
1.3 事件驱动架构核心流程
下图展示了 EDA 在回测场景中的典型数据流：行情数据作为事件源，通过事件总线分发到策略引擎和风控模块，策略产生的订单事件再通过总线路由到撮合引擎。
1.4 事件类型与生命周期
在回测与灰度发布系统中，事件通常分为以下三类，每类事件的生命周期管理方式不同：
- 市场事件（Market Event）：由外部数据源驱动，如 Tick 行情、K 线更新、订单簿快照。特点是不可重放（在回测中可模拟重放），时效性要求高。
- 业务事件（Business Event）：由系统内部逻辑产生，如策略信号、订单创建、成交回报、风控告警。特点是可追溯，需要持久化用于审计和复盘。
- 控制事件（Control Event）：用于管理回测或灰度流程，如开始/暂停回测、切换灰度流量比例、重置状态。特点是优先级高，通常需要同步处理。
常见误区：初学者容易将所有事件都放在同一个事件总线上处理。在实战中，建议将市场事件和控制事件分离到不同的通道，避免高优先级的控制指令被海量行情事件阻塞，导致回测暂停指令延迟执行。
1.5 事件驱动架构在回测中的优势
与传统逐行回测（向量化回测）相比，事件驱动回测具有以下不可替代的优势：
- 高仿真性：模拟真实交易环境中的异步消息流，能准确反映滑点、延迟和订单排队效应。
- 灵活扩展：可以轻松接入新的策略模块、风控规则或数据源，只需注册新的事件处理器。
- 可观测性：每个事件都可以被记录、追踪和重放，便于调试和归因分析。
- 灰度兼容：事件驱动架构天然支持流量路由，可以无缝将部分实盘流量导向新策略进行灰度验证。