做市商业务体系全景图：业务模块划分
大家好，我是你们的老朋友。今天咱们聊聊做市商业务体系的全景图。
说实话，我刚入行那会儿，对做市商的理解特别狭隘。我以为就是挂单、吃单、赚价差。后来真正上手搭建系统，才发现这玩意儿是个系统工程。你想想看，一个完整的做市业务体系，至少得包含五个核心模块：策略、风控、交易执行、清算、监控。每个模块都有自己的脾气，彼此之间还得配合默契。
嗯，咱们一个一个来看。
策略模块：做市的大脑
策略模块是整个体系的核心。说白了，它就是决定「什么时候报价、报什么价、报多少量」的决策中心。
我个人习惯把策略模块拆成三层：
- 信号层：负责计算各种指标，比如订单簿不平衡度、波动率、库存偏离度。我在项目中遇到过一个问题——信号层计算太慢，导致报价跟不上市场变化。后来我们改用事件驱动架构，把计算延迟从毫秒级降到了微秒级。
- 定价层：根据信号生成报价。这里有个经典公式——
报价 = 参考价 + 库存调整 + 风险溢价。我曾经踩过一个坑：库存调整系数设得太激进，结果一次大行情直接把我打穿了。避坑指南：系数一定要做压力测试。 - 参数层：管理策略参数，比如最大持仓、报价宽度、撤单频率。这些参数不能写死，得支持热加载。我建议用配置中心统一管理，方便动态调整。
核心要点：策略模块的输出是「报价指令」，包括价格、数量、方向、有效期。这些指令会传给交易执行模块。
风控模块：做市的刹车
风控模块，说白了就是防止你亏得裤衩都不剩。我见过太多做市商，策略赚钱的时候风控形同虚设，等爆仓了才后悔莫及。
风控模块的职责包括：
- 事前风控：报价前检查。比如检查当前持仓是否超限、账户余额是否充足、市场是否处于异常状态。我曾经因为没检查市场状态，在交易所宕机恢复后直接报了一堆废单，被交易所罚了钱。
- 事中风控：实时监控。比如监控成交速度、库存变化、盈亏波动。一旦触发阈值，立即熔断。我建议设置三级熔断：警告、降频、停机。
- 事后风控：复盘分析。每天跑一遍风控报告，看看哪些单子有问题。我习惯用
盈亏归因分析来定位问题——是策略问题还是执行问题？
注意：风控模块不能影响正常交易。我见过有些团队把风控做得太严，结果策略根本跑不起来。平衡点很重要。
交易执行模块：做市的手脚
交易执行模块负责把策略的报价指令变成真实的订单，并发送到交易所。这个模块对延迟极其敏感。
我把它分为三个子模块：
- 订单管理：管理订单生命周期——创建、提交、修改、撤销、成交。这里要注意订单状态的同步问题。我遇到过因为网络延迟导致订单状态不一致，结果重复撤单的惨案。
- 路由管理：如果对接多个交易所，需要智能路由。比如哪个交易所流动性好就优先发单，哪个交易所手续费低就优先发单。我建议用
延迟加权算法来做路由决策。 - 网关适配：每个交易所的API都不一样，需要做适配层。我习惯用
协议转换器模式，把交易所API统一成内部接口。
小技巧：交易执行模块一定要做幂等性处理。我曾经因为没做幂等，导致一笔订单被重复提交了三次，直接爆仓。嗯，血的教训。
清算模块：做市的账房
清算模块负责算账。包括交易对账、资金结算、费用计算、盈亏统计。
清算模块的难点在于：
- 多源对账：本地记录 vs 交易所记录 vs 银行记录。我建议每天做一次
三方对账，发现差异及时处理。 - 费用计算：手续费、返佣、利息、税费。不同交易所的费率结构不一样，有的按成交额收，有的按笔数收。我习惯用
规则引擎来管理这些复杂的计费逻辑。 - 盈亏计算：已实现盈亏 vs 未实现盈亏。这里要注意估值方法的选择——是用最新价还是用中间价？我建议用
加权平均价，更接近真实情况。
核心要点：清算模块的输出是「结算报告」，包括每日盈亏、持仓汇总、资金流水。这些数据会传给监控模块做可视化展示。
监控模块：做市的仪表盘
监控模块负责把整个系统的运行状态展示出来。说白了，就是让你一眼看出系统有没有问题。
监控模块包括：
- 实时监控：延迟监控、成交率监控、库存监控、盈亏监控。我建议用
Grafana + Prometheus搭建实时监控面板，延迟数据用热力图展示，一目了然。 - 告警管理：设置告警规则，比如延迟超过100ms告警、库存偏离超过阈值告警。告警方式要多样化——邮件、短信、钉钉、电话。我曾经因为只设了邮件告警，结果周末出问题没人看邮件，亏了一晚上。
- 日志管理：记录所有操作日志和系统日志。我建议用
ELK（Elasticsearch + Logstash + Kibana）做日志分析，方便排查问题。
小技巧：监控模块要支持历史回放功能。我遇到过一个问题——某个策略在特定行情下表现异常，但当时没记录足够的数据，导致无法复现。后来我们加了全量数据录制功能，问题就好解决了。
各模块交互关系
这五个模块不是孤立的，它们之间有紧密的交互关系。我画了一张图，方便大家理解：
从图中可以看出：
- 策略模块生成报价指令，传给风控模块检查
- 风控模块检查通过后，传给交易执行模块发送到交易所
- 交易所返回成交数据，传给清算模块做对账结算
- 清算模块生成结算报告，传给监控模块做可视化展示
- 监控模块把反馈数据传回策略模块，形成闭环
- 风控模块可以随时发送熔断信号给交易执行模块，紧急停止交易
技术栈选型概览
技术栈选型是个大话题。我根据自己的经验，给出一套参考方案：
| 模块 | 推荐技术栈 | 说明 |
|---|---|---|
| 策略模块 | Python + C++ | Python做原型开发，C++做核心计算 |
| 风控模块 | Go + Redis | Go高并发，Redis做实时状态存储 |
| 交易执行 | Java + Netty | Java生态成熟，Netty做高性能网络 |
| 清算模块 | Python + PostgreSQL | Python做数据处理，PostgreSQL做持久化 |
| 监控模块 | Grafana + Prometheus + ELK | Grafana做可视化，Prometheus做指标采集，ELK做日志分析 |
| 消息队列 | Kafka / RabbitMQ | 模块间异步通信 |
| 配置中心 | Consul / etcd | 统一管理配置，支持热更新 |
小提示：技术栈选型没有银弹。我见过用纯Python跑做市系统的团队，也见过全栈C++的团队。关键是看你的业务场景和团队能力。我个人建议：核心链路用高性能语言，非核心链路用开发效率高的语言。
好了，这一章的内容就到这里。做市商业务体系的全景图，说白了就是五个模块各司其职、协同工作。下一章咱们会深入策略模块，聊聊具体的定价模型和参数优化。嗯，到时候见。