交易系统架构基础：订单生命周期、核心组件与常见架构模式
做量化交易这些年，我见过不少团队一上来就急着写策略代码。结果呢？策略跑得挺好，一到实盘就各种问题——订单发不出去、成交回报丢了、系统卡死。说白了，交易系统的根基是架构，不是策略。今天我们就聊聊这个根基。
订单生命周期：一笔交易的前世今生
先问个问题：你点下「买入」按钮后，到底发生了什么？
我习惯把订单的生命周期分成六个阶段。每个阶段都有坑，我一个个说。
- 创建：策略生成订单，包含品种、方向、数量、价格等信息。嗯，这里要注意，订单的ID生成策略很关键。我曾经用UUID做主键，结果数据库写入性能直接崩了。
- 校验：检查账户余额、持仓、风控限制。说白了，就是看看你有没有资格下这个单。
- 路由：把订单送到正确的交易所或经纪商。这个环节容易出问题，我后面细讲。
- 执行：交易所撮合引擎处理订单，生成成交回报。
- 确认：系统收到成交回报，更新本地状态。
- 结算：更新账户余额、持仓、交易记录。
核心要点：订单生命周期中的每个阶段都可能失败。你的系统必须能处理这些异常情况。比如订单创建后网络断了怎么办？成交回报丢了怎么办？
你想想看，如果订单状态管理不好，会出现什么情况？重复下单、漏单、资金对不上。这些我都踩过坑。
核心组件：网关、路由、执行引擎
交易系统里，有三个组件是绕不开的。我按重要性排个序。
1. 网关（Gateway）
网关是系统的「门面」。它负责和外部系统打交道——交易所、经纪商、行情源。
我个人习惯把网关设计成无状态的。为什么？因为无状态才好水平扩展。你想想看，如果网关里存了订单状态，那重启一个实例就麻烦了。
网关的核心职责：
- 协议转换：把内部消息格式转成交易所的协议格式
- 连接管理：维护与交易所的长连接，处理心跳、重连
- 流量控制：防止发送过快被交易所限流
- 日志记录：记录所有进出消息，方便排查问题
避坑指南：我曾经在网关层忽略了消息去重。结果交易所重传了一次成交回报，系统就重复计算了持仓。从那以后，我每个网关都加上了消息ID去重逻辑。
2. 路由（Router）
路由负责把订单送到正确的目的地。听起来简单？其实不然。
举个例子：你有三个交易所，每个交易所又有多个交易对。订单来了，你要决定送到哪个交易所、哪个账户、哪个网关。
路由的决策逻辑：
- 品种映射：把内部品种代码转成交易所的代码
- 账户选择：根据策略、资金、风控选择交易账户
- 网关选择：根据延迟、负载、可用性选择网关
- 优先级：支持紧急订单插队
我见过一个系统，路由逻辑写成了if-else的意大利面条。后来改成基于规则的引擎，可维护性好了很多。
3. 执行引擎（Execution Engine）
执行引擎是系统的「大脑」。它负责把策略信号变成实际的订单操作。
执行引擎要处理的事情：
- 拆单：大单拆成小单，减少市场冲击
- 择时：选择最佳时机下单
- 撤单：处理未成交订单，重新下单
- 风控：实时监控交易风险
注意：执行引擎的性能瓶颈往往不在CPU，而在I/O。每次下单、撤单、查询都是网络操作。我建议用异步非阻塞模型，别用同步阻塞。
常见架构模式
做交易系统这么多年，我总结出三种主流架构模式。每种都有适用场景。
模式一：直连模式
最简单粗暴的方式。策略直接调用交易所API。
优点：延迟低、实现简单。
缺点：扩展性差、容错性差。
适合：个人交易者、小团队、低频率策略。
模式二：代理模式
中间加一层代理服务。策略通过代理访问交易所。
优点：统一管理连接、方便做风控、支持多策略共享。
缺点：多一跳延迟、代理可能成为瓶颈。
适合：中等规模团队、多策略并行。
模式三：微服务模式
把网关、路由、执行引擎拆成独立服务。每个服务可以独立部署、扩展。
优点：高可用、易扩展、故障隔离。
缺点：复杂度高、运维成本大。
适合：大型机构、高频交易、多市场覆盖。
我的建议：别一上来就搞微服务。我见过太多团队把简单问题复杂化了。先跑通直连模式，等业务量上来了再逐步拆分。
架构对比一览
| 特性 | 直连模式 | 代理模式 | 微服务模式 |
|---|---|---|---|
| 延迟 | 低 | 中 | 中高 |
| 扩展性 | 差 | 中 | 好 |
| 容错性 | 差 | 中 | 好 |
| 运维复杂度 | 低 | 中 | 高 |
| 适用规模 | 小 | 中 | 大 |
核心架构流程图
下面这张图展示了交易系统的核心数据流。我画的时候特意简化了，只保留最关键的部分。
这张图展示的是最简化的流程。实际系统中，每个组件之间还有心跳检测、重连机制、消息队列等。嗯，这些细节我们后面章节再展开。
个人经验：我建议你在设计架构时，先画数据流图。把每个组件的输入输出、异常处理都标清楚。这样做的好处是，开发阶段就能发现很多潜在问题。
好了，交易系统架构的基础就聊到这里。记住一句话：架构设计没有银弹，适合你的才是最好的。下一节我们会深入订单管理系统的实现细节。