4.1 交易系统组成：一次点击背后的完整链路

4.1 交易系统组成：一次点击背后的完整链路

本节摘要：交易系统不是"下单软件"，而是一条由行情接入、信号引擎、风控模块、执行网关与监控运维组成的流水线。本节按订单的旅程逐段拆解每个模块的职责、数据流与典型故障，为后续的执行算法、低延迟与偏差排错提供地图。上一章的策略族谱决定了订单"为什么来"，本章决定它"怎么去"。

给交易系统下一个工程定义

交易系统是这样一个进程集合：它持续消费市场数据，驱动策略产生目标持仓，把目标与现状的差额转成合法订单，在约束内把订单送达交易所，并全程留痕可审计。这个定义里有四个常被低估的词。"持续"——系统是全天候运转的流水线，不是按一下鼠标的动作；"差额"——订单源于目标仓位与当前持仓的偏差计算，这个计算错一分，后面全错；"约束内"——风控不是系统外的裁判，是链路上的强制关卡；"留痕"——任何一笔成交都必须能回答"为什么"，这是运维与排错的本钱。

五个模块各自的职责与脾气

行情接入负责把交易所的行情流转成系统内部统一格式的数据。它的脾气是：丢一行数据不会报错，只会让下游的计算悄悄失真。行情接入层必须自带完整性校验（序号连续性、心跳超时、快照与逐笔的对账），断线重连后的数据补齐策略要明确——是重放、请求快照还是标记缺口等待修复，每种选择对策略语义的影响都不同。

信号引擎持有策略逻辑，输入行情快照，输出目标仓位。设计要点是纯粹性：它只做计算，不做执行、不做风控、不直接碰资金。保持纯粹，策略才能离线回测与实盘共用同一份代码——这是消除"回测与实盘两套逻辑"类偏差的根本手段。

风控模块是链路上的强制关卡：持仓限额、单品种敞口、账户总回撤阈值、下单频率上限、自成交防护。它必须独立于策略进程，且在策略逻辑出错时依然生效——风控被绕过的方式有一百种，其中九十九种来自"为了方便"。

执行网关负责把内部订单格式翻译成交易所协议、管理连接与会话、上报成交回报。它是延迟最敏感的一段，也是故障恢复最讲究的一段：重连后挂单状态的对账、部分成交的续单策略、报单被拒绝时的重试语义，都需要显式设计。

监控与运维是唯一不碰订单的模块，却是故障发现速度的决定因素：行情时延、订单状态机卡死、账户权益异常、成交价与参考价的偏差超阈——每一项都要有独立告警。交易系统的故障哲学是假设任何模块都会坏，监控的职责是让坏在三秒内被知道。

数据流与状态一致性

链路上流淌着三条流：行情流（交易所到信号引擎）、订单流（风控到网关到交易所）、回报流（反向回来）。三者速度不同、可能乱序、可能中断，系统的一致性全部押在对账上：本地订单状态与交易所回报逐笔对齐、内部持仓与柜台持仓定时核对、目标仓位与实际仓位差额的再计算周期。经典事故模式几乎都发生在状态不一致的窗口里——重连后以为订单已死其实还活着，导致双倍持仓；回报迟到导致重复报单。防御工事是给每个订单一个状态机（待报、已报、部分成交、全成、已撤、废单），状态迁移只由回报驱动，任何超时未回报的订单进入人工核查队列。

复用与两套逻辑的陷阱

团队最常犯的结构性错误，是为回测和实盘维护两套策略实现。表面上省了架构设计的功夫，代价是两份代码在细节上不可逆地漂移：回测版用收盘价、实盘版用盘口中间价；回测版允许任意下单量、实盘版受最小交易单位约束。漂移的每一处都是 4.4 节偏差表的候选来源。工程解法是把策略逻辑写成纯函数——输入数据快照、输出目标仓位——回测引擎与实盘引擎只是这个纯函数的两个不同"宿主"。宿主可以不同，内核必须同源。

⚠️ 常见坑：风控规则写在策略代码内部。策略崩溃或逻辑死循环时，内嵌风控与策略同归于尽。风控必须活在独立进程里，用独立的输入做判断。

深入一步：复盘一次典型的重连事故

把状态一致性的重要性演成一个事故。某日下午，行情会话闪断八秒。系统自动重连成功，但重连后的第一笔行情是快照而非逐笔流——中间八秒里发生的四笔成交与两次挂单变动被跳过。信号引擎拿着"跳跃后"的盘口计算出与真实状态不同的信号，发出一笔限价单；与此同时，断线前发出的一笔订单其实已经成交，回报却在断线期间丢失，本地持仓与柜台持仓差了一笔。接下来的连锁反应：因为本地以为那笔订单未成交，风控计算的敞口偏小，放行了第二笔同方向订单；两笔成交叠加后，实际持仓达到目标的两倍。收盘对账时差额浮出水面。这次事故的三条教训都写进了系统：重连后必须先做持仓与挂单的全量对账、对账完成前信号引擎冻结开仓、所有"本地认为"与"柜台回报"的分歧必须落盘待查。链路系统的可靠性，正是在这类八秒的缝隙里建立的。

常见疑问

问：小团队起步，系统做到什么程度就够用？ 以"能完整回答三问"为及格线：出了问题能不能在三分钟内知道（监控）、问题发生时能不能一键停（风控开关）、事后能不能完整还原（留痕）。图形界面、性能优化、自动恢复都可以后置，三问不达标的系统不应接入真实资金。

问：策略内核同源之后，回测与实盘还会有合理差异吗？ 会有，而且是应该有的差异：数据来源（历史库与实时行情的口径差）、撮合实现（模拟撮合与真实撮合的语义差）无法完全消除。同源的意义是把差异压缩到"仅剩这两类已知差异"，让 4.4 节的偏差排查有明确的搜索边界。

问：系统日志记到什么粒度合适？ 以"能独立复现任意一笔交易的决策链"为标准：该笔交易依赖的行情快照、信号计算的关键中间值、风控检查的每一项结果、订单的完整状态迁移。粒度不足的日志等于黑匣子里没有录音，粒度过剩的日志则拖垮性能与检索——拿"复现一笔交易"当标尺去裁剪，是最实用的平衡方法。

本节要点回顾

• 交易系统是流水线不是软件：行情、信号、风控、网关、监控五段，订单旅程贯穿全部；
• 行情层防静默失真：丢数据不报错，完整性与对账是接入层的底线职责；
• 信号引擎保持纯粹：只算不执行，回测与实盘共用同一份策略内核；
• 风控独立成进程：限额、敞口、频率、自成交防护，规则在策略之外强制生效；
• 一致性靠对账与状态机：订单状态只由回报驱动，超时订单进人工队列。

💡 关键直觉：评估一个交易系统的成熟度，别看它行情好时的表现，看三类时刻——断线重连的那一分钟、部分成交的订单、以及周五收盘后的对账单。三类时刻都干净，系统才算及格。

链路看清了，下一站研究订单本身的艺术：大单怎么拆、按什么节奏铺。