事件驱动内核与可回放确定性
vn.py选择事件驱动，是因为交易系统的关键状态变化天然是离散事件：行情、报单回报、成交回执、账户/持仓更新都可以被序列化为统一输入。事件总线把模块间耦合从“直接调用”变成“订阅与发布”，策略不需要理解网关如何重连、如何限流，也不需要自己维护订单状态转移。并发与I/O复杂度被收敛到引擎与网关层，策略代码可以保持可测试、可审计的纯业务逻辑。更关键的是事件序列可记录可回放，同一份事件流既能驱动回测，也能复现线上问题并做回归对比。
vn.py（VeighNa）把量化交易系统拆成“事件驱动内核 + 可插拔业务模块”的工程骨架：行情推送、委托回报、成交回执、账户与持仓更新被标准化为事件流在引擎中传播，策略只需要订阅事件并输出交易意图，从而把并发、线程与回调复杂度隔离在底层。网关层把不同券商/交易所接口的连接、鉴权、订单状态机与断线恢复收敛为一致API，上层应用复用同一事件总线来组合回测、算法拆单、组合策略、价差/期权工具与前置风控等能力。数据侧提供适配器把Tick、K线与交易日志沉淀到 SQLite、MySQL 或 PostgreSQL，让事件回放驱动回测与线上故障复现成为常规动作，团队可以用“配置+版本”交付策略并持续回归验证。
| ✕传统痛点 | ✓创新方案 |
|---|---|
| 脚本直连交易接口时，重连、限流、线程安全与订单状态机不可避免地侵蚀策略代码，执行层越写越像一团泥，回测复现与线上排障都会失控。 | vn.py 用事件总线定义系统边界：网关负责把外部世界翻译成事件并处理执行细节，策略负责把事件映射为意图，从架构层面降低耦合与并发复杂度。 |
| 研究与实盘拆成两套系统时，数据口径、撮合假设与风控规则容易漂移，回测看似稳定，上线却出现不可解释的行为差异与滑点暴露。 | 统一的数据结构与可插拔应用生态把回测、拆单、风控、数据管理放进同一条工程流水线；事件可记录可回放，回归验证与故障复现可以制度化。 |
1git clone https://github.com/vnpy/vnpy.git && cd vnpy && python -m venv .venv && . .venv/bin/activate1Windows: install.bat | Ubuntu: bash install.sh | macOS: bash install_osx.sh1pip install -U pip && pip install vnpy vnpy_ctastrategy vnpy_ctabacktester vnpy_algotrading vnpy_riskmanager1export VNPY_DATABASE_DRIVER=postgresql && export VNPY_DATABASE_HOST=127.0.0.1 && export VNPY_DATABASE_PORT=5432 && export VNPY_DATABASE_DATABASE=vnpy1python run.py| 核心场景 | 目标人群 | 解决方案 | 最终收益 |
|---|---|---|---|
| 多通道实盘执行闭环 | 私募/交易团队 | 用统一网关接入多个交易通道并启用算法拆单与风控 | 降低通道差异导致的事故率，稳定扩展资金与策略数量 |
| 回放驱动的回测回归 | 量化研究员 | 记录事件流并在同一引擎中回放做回测与回归对比 | 结果更可复现，线上问题可快速定位与复盘 |
| 多账户组合与权限运维 | 机构运维与风控 | 集中化存储交易日志与行情数据并统一规则管控 | 提升审计与合规可追溯性，减少人工操作与配置漂移 |
