2. 系统架构设计：分层架构思想、核心模块划分、技术选型

好，咱们直接进入正题。这一章聊的是系统架构，说白了就是搭骨架。你想想看，一个量化交易系统，每天要处理海量行情、跑几百个策略、还要保证下单不出错——这玩意儿要是没个清晰的架构，迟早要崩。

我个人习惯，做系统设计第一件事就是「分层」。为什么？因为分层能让你把复杂问题拆开。每一层只关心自己的事，出了问题也好定位。我在项目中遇到过好几次，就是因为层与层之间耦合太紧，改一个 bug 牵出一串问题，那叫一个头疼。

2.1 分层架构思想

先看一张图，这是我常用的四层架构模型：

这张图我画了很多遍。每一层都有明确的职责，箭头表示数据流向。注意看风控层那条虚线——它不只是一层，而是像「监控探头」一样横跨所有层级。嗯，这里要特别强调：风控不是事后诸葛亮，而是实时拦截。

2.2 核心模块划分

咱们把每一层拆开细说。我按实际开发顺序来讲，这样你更容易理解。

2.2.1 数据层

这是地基。数据搞不定，后面全是空中楼阁。我在项目中见过太多人一上来就写策略，结果发现历史数据对不上、tick 数据有缺失——白忙活一场。

• 行情接入： 支持多交易所、多品种。TCP 直连还是 WebSocket？我建议用 WebSocket，连接管理更省心。
• 数据清洗： 去重、补全、时间对齐。别小看这一步，脏数据能让你策略回测结果完全失真。
• 存储设计： 高频用时序数据库（如 InfluxDB），低频用关系型（如 PostgreSQL）。别混着用，各司其职。
• 历史回放： 模拟真实行情推送，用于回测。速度要可调，1倍、10倍、100倍都支持。

2.2.2 策略层

这是整个系统的「大脑」。策略层要足够灵活，因为你会不断迭代策略。我见过有人把策略写死在代码里，每次改策略都要重新编译——这太痛苦了。

• 信号生成： 基于技术指标、机器学习模型等。建议做成插件式，新增策略不用改主程序。
• 组合管理： 多策略、多品种的资金分配。别把所有鸡蛋放一个篮子里。
• 回测引擎： 模拟历史行情，计算收益、回撤、夏普比率等。注意要支持「逐笔回测」，精度更高。
• 参数优化： 网格搜索、遗传算法等。但小心过拟合——我见过有人把参数优化到历史数据上完美拟合，实盘一跑就亏。

2.2.3 执行层

策略层算出了买卖信号，执行层负责把它变成真实的订单。这一层最考验工程能力，因为市场瞬息万变。

• 订单路由： 把信号转换成交易所能识别的订单格式。支持限价单、市价单、冰山订单等。
• 滑点控制： 大单拆小单，减少市场冲击。我常用的算法是 TWAP 和 VWAP。
• 成交管理： 跟踪订单状态：已提交、部分成交、全部成交、已撤销。状态机要设计好。
• 仓位同步： 本地仓位和交易所仓位保持一致。每天收盘后做一次对账，防止出现「幽灵仓位」。

2.2.4 风控层

这一层是「刹车系统」。没有风控，赚再多钱也可能一夜归零。我见过太多爆仓案例，都是风控没做好。

• 资金监控： 实时计算账户权益、保证金占用、风险度。超过阈值自动报警或减仓。
• 限仓检查： 单品种、单策略的最大持仓限制。防止某个策略失控。
• 异常熔断： 连续亏损、成交异常、网络中断等情况下，自动暂停交易。
• 合规审计： 记录所有操作日志，方便事后追溯。监管要求越来越严，这个不能省。

2.3 技术选型：Python vs C++

这个问题几乎每个做量化的人都会问。我的回答是：看场景。没有银弹。

我个人建议的选型策略：

• 策略研发和回测： 用 Python。快速迭代、验证想法。我 80% 的时间都在 Python 里写策略。
• 实盘执行和行情接入： 用 C++。延迟敏感的部分必须用 C++。我见过有人用 Python 做高频，结果行情还没处理完，价格已经变了。
• 混合架构： Python 做上层策略，C++ 做底层执行。中间通过消息队列（如 ZeroMQ）通信。这是目前业界的主流做法。

你想想看，一个系统从零到一，最怕的是什么？是「过度设计」。我见过有人一开始就用 C++ 写了个完整的交易系统，结果写了半年还没跑通回测。而用 Python 的话，两周就能看到效果。先跑起来，再优化，这才是正道。

好了，这一章的内容就到这里。记住：架构设计没有标准答案，只有最适合你当前场景的方案。数据层要稳，策略层要活，执行层要快，风控层要严。把这四个模块搞清楚了，你的系统就成功了一半。

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