2. 系统总体架构设计：分层架构设计原则、微服务 vs 单体架构选型、核心模块划分
好，咱们直接进入正题。做市系统这东西，说白了就是跟时间赛跑。你想想看，行情数据每秒几千笔，你的系统要是慢个几毫秒，可能就被对手盘吃掉了。所以架构设计的第一原则，不是花里胡哨，而是稳、快、可扩展。
2.1 分层架构设计原则
我个人习惯把做市系统拆成四层。为什么是四层？因为我在项目中吃过亏——一开始只分了三层，结果业务逻辑和行情处理搅在一起，改一个策略要重启整个系统，那叫一个痛苦。
- 接入层：负责行情接入、订单路由、交易所协议转换
- 核心层：做市策略引擎、风险管理、定价模型
- 服务层：账户管理、资金核算、日志审计
- 数据层：历史行情存储、策略回测、报表生成
每一层只做自己的事。接入层不关心你怎么定价，核心层不关心数据存哪里。这样改起来才爽——比如换一个交易所接口，只动接入层，其他层完全不动。
2.2 微服务 vs 单体架构选型
这个问题我经常被问到。其实没有绝对的好坏，关键看你的场景。
| 维度 | 单体架构 | 微服务架构 |
|---|---|---|
| 开发速度 | 初期快，后期慢 | 初期慢，后期快 |
| 部署复杂度 | 低，一个包搞定 | 高，需要容器编排 |
| 故障隔离 | 差，一个模块挂了全挂 | 好，单个服务挂了不影响其他 |
| 扩展性 | 只能整体扩展 | 可以按需扩展 |
| 适合场景 | 团队小、业务简单 | 团队大、业务复杂 |
我个人建议：做市系统初期用单体就够了。为什么？因为做市的核心逻辑就那么几个模块，微服务带来的网络延迟和运维成本，对高频场景来说是致命的。我见过一个团队，一上来就搞了十几个微服务，结果行情处理链路多了好几毫秒，策略根本跑不赢。
但如果你做的是多市场、多品种的做市，比如同时做美股、A股、期货，那微服务就有优势了——每个市场独立部署，互不影响。这时候我会建议用微服务，但核心的行情处理和策略引擎一定要放在同一个进程里。
2.3 核心模块划分
好了，咱们来看看做市系统到底要拆成哪些模块。我按功能把它们分成几组：
2.3.1 行情模块
- 行情接入：对接交易所的行情源，支持多种协议（FIX、UDP、WebSocket）
- 行情缓存：本地维护一个快照，避免每次都去查数据库
- 行情分发：把处理好的行情推给策略引擎和其他模块
这里要注意，行情模块是系统的入口，它的性能直接决定了整个系统的延迟。我一般会用C++或者Rust来写行情接入层，Java写上层逻辑。
2.3.2 策略引擎模块
- 定价模型：计算期权的理论价格，常用的有Black-Scholes、二叉树、蒙特卡洛
- 做市策略：根据定价结果生成买卖报价，比如Delta中性策略、Gamma scalping
- 订单管理：管理已发出的订单，处理撤单、改单
2.3.3 风控模块
- 实时风控：检查每笔报价是否超出风险限额，比如最大持仓、最大敞口
- 事前风控：在报价发出前检查，比如价格是否合理、是否超过涨跌停
- 事后风控：成交后检查，比如是否出现异常交易
嗯，这里要特别强调一下。风控模块必须独立于策略引擎，而且要有独立的进程。为什么？因为策略引擎可能会出bug，如果风控和策略在同一个进程里，策略挂了风控也挂了，那就没人拦着系统乱报价了。我曾经就遇到过策略死循环，结果风控模块因为共享内存被锁住，也跟着挂了，最后爆仓了。从那以后，我坚持风控必须独立部署。
2.3.4 数据与监控模块
- 日志系统：记录所有交易日志，用于事后分析
- 监控告警：监控系统状态，比如延迟、吞吐量、错误率
- 回测系统：用历史数据验证策略效果
这些模块虽然不直接参与交易，但少了它们，你就像在黑暗中开车。我习惯把监控做成实时仪表盘，延迟、报价次数、成交率一目了然。
2.4 架构图：核心模块与数据流
下面这张图展示了做市系统的核心模块和数据流向。我画的是简化版，但核心逻辑都在里面了。
从图上你能看到，行情从交易所进来，经过缓存后推给策略引擎。策略引擎生成报价后，先过风控模块，风控通过了才发到订单路由，最后送到交易所。所有模块的数据都会汇总到数据与监控模块，方便你事后分析。
好了，这一章的内容就这些。记住，架构设计没有银弹，关键是根据你的业务场景做取舍。下一章我们会深入策略引擎的设计，聊聊定价模型和做市策略的具体实现。
公众号:蓝海资料掘金营，微信deep3321