第二章：系统架构总览——分层架构设计

做量化交易系统这么多年，我最大的体会是：架构设计决定了系统的天花板。你策略再牛，如果底层架构撑不住，行情一来就崩盘，那一切都是白搭。

今天咱们聊聊系统架构的总览。说白了，就是搞清楚一个量化交易系统到底该长什么样，各个模块怎么分工，以及我们做技术选型时该遵循什么原则。

一、分层架构设计：数据层、策略层、执行层

我个人习惯把量化交易系统拆成三层：数据层、策略层、执行层。为什么这么分？因为每一层的关注点完全不同，混在一起会出大问题。

1. 数据层：系统的“血液”

数据层负责搞定所有市场数据的接入、清洗、存储和分发。你想想看，没有数据，策略就是无源之水。

• 行情数据：Tick级、1秒级、分钟级……不同频率的数据，存储和查询方式天差地别。
• 历史数据：回测用的，通常存到数据库或文件系统里。
• 实时数据：生产环境用的，要求低延迟、高吞吐。

我在项目中遇到过一个问题：行情数据源突然断流，结果策略层还在傻等新数据，导致交易信号延迟了整整3秒。嗯，后来我们加了一层数据缓冲和心跳检测，才彻底解决。

2. 策略层：系统的“大脑”

策略层是量化交易的核心。它接收数据层推送的行情，运行交易逻辑，生成买卖信号。

• 策略引擎：负责加载和管理多个策略实例。
• 信号生成：根据策略逻辑，计算指标、判断买卖点。
• 风险管理：仓位控制、止损止盈、资金管理。

3. 执行层：系统的“手脚”

执行层负责把策略生成的信号，转化为真实的交易指令，并发送到交易所。

• 订单管理：创建、修改、撤销订单。
• 路由管理：选择最优的交易所或经纪商。
• 成交反馈：处理成交回报，更新持仓状态。

执行层最怕什么？延迟。我见过一个系统，从信号生成到订单发出，中间走了5个微服务调用，结果行情都变了，单子还没出去。所以执行层一定要轻、要快。

二、微服务 vs 单体架构

这是架构选型时绕不开的话题。我两种架构都用过，说说我的感受。

1. 单体架构

把所有功能都塞进一个进程里。优点是简单、开发快、调试方便。缺点是……一旦业务复杂起来，改一处可能影响全局。

适合场景：个人交易者、小团队、初期验证阶段。

2. 微服务架构

把系统拆成多个独立服务，每个服务负责一块功能。比如数据服务、策略服务、执行服务、风控服务……

优点很明显：

• 独立部署：改一个服务不影响其他服务。
• 弹性伸缩：行情高峰时，可以单独给数据服务加机器。
• 技术异构：数据层用C++追求性能，策略层用Python方便开发，执行层用Java保证稳定。

但微服务也有代价：网络开销、运维复杂度、数据一致性。我记得有一次，策略服务调用执行服务超时，结果订单重复提交了……后来加了幂等性校验才解决。

对比维度	单体架构	微服务架构
开发效率	高（初期）	低（初期）
部署复杂度	低	高
扩展性	差	好
故障隔离	差	好
适合团队	1-5人	5人以上

我的建议是：先单体，后拆分。别一上来就搞微服务，等业务逻辑稳定了、团队规模上来了，再逐步拆解。

三、技术选型原则

技术选型这事儿，说白了就是权衡。没有银弹，只有最适合你当前场景的方案。

1. 性能优先原则

量化交易对延迟极其敏感。我个人习惯：数据层和执行层用C++或Java，策略层用Python或C#。

为什么？数据层要处理海量行情，C++的内存管理和并发能力是顶级的。执行层要跟交易所交互，Java的Netty框架在低延迟网络编程上表现很好。策略层嘛，Python开发快，适合快速迭代。

2. 可维护性原则

别为了炫技选冷门技术。你想想看，如果团队里只有你会用某个语言或框架，万一你请假了，系统出问题谁来修？

我选技术栈时，会优先考虑：

• 社区活跃度：遇到问题能搜到解决方案。
• 文档完善度：新成员上手快。
• 人才储备：市场上容易招到人。

3. 渐进式演进原则

不要试图一步到位。我见过一个团队，花了大半年时间搞了一套“完美”的微服务架构，结果业务需求变了，很多服务白做了。

正确的做法是：先跑通核心流程，再逐步优化。比如先做一个能跑的单体系统，等发现性能瓶颈了，再把瓶颈部分拆成独立服务。

四、系统架构总览图

下面这张图是我画的一个简化版架构总览，展示了三层之间的数据流和交互关系。

这张图里，数据从底层往上流动。数据层采集行情后，推送给策略层；策略层算出信号后，交给执行层去下单。每一层各司其职，互不干扰。

好了，关于系统架构总览，今天就聊这么多。记住一句话：架构不是设计出来的，是演进出来的。别追求完美，先跑起来再说。

---