第三章：量化交易系统架构
聊到量化交易系统架构，我脑子里第一个蹦出来的词就是「分层」。
为什么？因为我在早期做量化系统时，踩过一个坑——把所有逻辑揉在一个大模块里。结果呢？改一个参数要重启整个系统，策略回测和实盘代码混在一起，出了bug都不知道是数据问题还是策略问题。后来我花了整整两周重构，才把系统拆成三层。嗯，从那以后，我对「架构分层」这四个字有了刻骨铭心的理解。
3.1 经典三层架构：数据层、策略层、执行层
说白了，三层架构就是把量化系统切成三块：数据层负责「拿数据」，策略层负责「想逻辑」，执行层负责「下订单」。各干各的，互不干扰。
核心原则：每一层只依赖下一层，绝不跨层调用。数据层不能直接下单，策略层不能直接连交易所。
3.1.1 数据层
数据层是地基。我习惯把它再拆成两个子模块：
- 数据采集：从交易所、数据商拉取行情和成交数据。我个人习惯用WebSocket做实时行情，用REST API做历史数据补全。
- 数据存储：行情数据用时序数据库（比如InfluxDB），交易数据用关系型数据库（比如PostgreSQL）。
这里有个避坑指南：我曾经把行情数据和交易数据全塞进MySQL，结果一张表几亿行，查询慢到怀疑人生。后来换成时序数据库，查询速度提升了两个数量级。
3.1.2 策略层
策略层是大脑。它从数据层拿行情，跑策略逻辑，生成交易信号。
你想想看，策略层最怕什么？最怕数据层出问题。所以我在策略层里加了一层「数据校验」——行情时间戳是否连续、价格是否异常跳动。如果数据有问题，策略层直接报警，不生成信号。
# 伪代码：策略层核心逻辑
class Strategy:
def __init__(self, data_layer):
self.data = data_layer
def on_tick(self, tick):
# 数据校验
if not self._validate_tick(tick):
return # 数据异常，跳过
# 策略逻辑
signal = self._generate_signal(tick)
if signal:
self.execution_layer.submit_order(signal)3.1.3 执行层
执行层是手脚。它接收策略层的信号，负责把订单发到交易所，并管理订单生命周期。
执行层有个关键点：订单状态机。一个订单从「已提交」到「部分成交」到「全部成交」或「已撤销」，状态转换必须严格管理。我在项目中遇到过因为状态机没写好，导致重复下单的惨案——嗯，那次亏了不少手续费。
| 状态 | 说明 | 常见转换 |
|---|---|---|
| PENDING | 已提交，等待交易所确认 | → OPEN |
| OPEN | 订单在交易所挂单中 | → PARTIAL_FILLED / FILLED / CANCELLED |
| PARTIAL_FILLED | 部分成交 | → FILLED / CANCELLED |
| FILLED | 全部成交 | 终态 |
| CANCELLED | 已撤销 | 终态 |
3.2 微服务架构在量化系统中的应用
三层架构虽然清晰，但有个问题：耦合还是太紧。比如策略层要升级，得停掉整个系统。微服务架构就是来解决这个问题的。
我参与过一个项目，把三层架构拆成了十几个微服务：行情服务、数据清洗服务、策略引擎服务、风控服务、订单路由服务、账户管理服务……每个服务独立部署，独立扩容。
我的建议：不要一上来就搞微服务。如果你的策略少于5个，资金量小于100万，三层架构完全够用。微服务带来的运维成本，小团队扛不住。
3.2.1 微服务拆分原则
- 按业务边界拆分：行情、策略、风控、执行，各是一个服务。
- 按数据访问频率拆分：高频访问的数据（如实时行情）单独服务，低频访问的数据（如历史回测）另起服务。
- 按变更频率拆分：经常改的策略代码单独部署，不常改的数据服务稳定运行。
3.2.2 服务间通信
微服务之间怎么通信？我常用的两种方式：
- 消息队列（如Kafka、RabbitMQ）：适合异步、解耦的场景。比如行情服务把tick数据扔到Kafka，策略服务从Kafka消费。
- gRPC：适合同步、低延迟的场景。比如策略服务需要实时查询账户余额，用gRPC调用账户服务。
这里有个经验：千万不要让服务之间直接HTTP调用。延迟高不说，一旦某个服务挂了，整个调用链都崩。用消息队列做缓冲，至少能保证数据不丢。
3.2.3 微服务架构的坑
说实话，微服务不是银弹。我见过一个团队，把三层架构拆成20个微服务，结果运维成本爆炸，每天光处理服务间调用失败就花掉半天时间。
避坑指南：
- 不要为了微服务而微服务。先问自己：这个服务独立部署的价值是什么？
- 做好服务治理：服务注册、发现、熔断、限流，一个都不能少。
- 数据一致性是最大的坑。跨服务的事务，尽量用「最终一致性」方案，别强求强一致性。
3.3 架构选型建议
讲了这么多，到底选三层架构还是微服务？我个人的判断标准很简单：
| 场景 | 推荐架构 | 理由 |
|---|---|---|
| 个人/小团队，策略少于10个 | 三层架构 | 开发快，运维简单 |
| 团队5人以上，策略多且复杂 | 微服务架构 | 独立部署，独立扩容 |
| 高频交易，延迟敏感 | 三层架构（优化版） | 微服务通信延迟不可控 |
| 多市场、多品种、多策略 | 微服务架构 | 每个市场独立服务，互不影响 |
最后说一句：架构是活的。我见过不少团队，一开始用三层架构，后来业务复杂了，慢慢把某些层拆成微服务。这很正常。别想着一步到位，先跑起来，再优化。