一、做市工具全景图：分类、模块、技术栈与选型考量
做市商这行，说白了就是跟市场赛跑。你跑得比对手快，就能吃到价差；慢了，就得给别人买单。而工具，就是你的跑鞋。
我入行那会儿，团队还在用Excel手动算报价，后来换成了C++写的内部系统，再到现在主流的Python+FPGA混合架构。这中间踩过的坑，够写一本血泪史了。今天我就把做市工具的全景图摊开来讲，帮你少走弯路。
1.1 做市工具的分类
做市工具五花八门，但按用途分，其实就三大类：
- 报价引擎：核心中的核心。负责计算双边报价、管理订单簿、执行对冲策略。我见过不少团队在这块用现成的开源库，结果遇到极端行情直接崩了。
- 风险管理模块：实时监控敞口、希腊值、资金利用率。说白了，就是防止你一把亏光。
- 数据与回测系统：没有历史数据回测，你就是在赌。我习惯把回测和实盘环境做成同一套代码，避免「回测猛如虎，实盘亏成狗」的尴尬。
嗯，这里要注意：很多新手会把「行情数据源」也当成工具的一部分。其实它更像基础设施，我后面会单独讲。
1.2 核心功能模块
一个成熟的做市系统，至少包含以下模块：
| 模块 | 功能 | 我踩过的坑 |
|---|---|---|
| 订单管理 | 下单、撤单、改单、订单状态同步 | 曾经因为订单ID冲突，导致重复下单，亏了十几万 |
| 风险控制 | 敞口限制、止损、资金监控 | 有一次忘记设置最大持仓，被一波行情打爆了 |
| 策略引擎 | 报价算法、对冲逻辑、参数热加载 | 热加载没做好，每次改参数都要重启，错过行情 |
| 日志与审计 | 全量交易日志、性能监控、异常告警 | 早期日志写得太随意，出问题根本查不到原因 |
你想想看，如果订单管理模块延迟高了10毫秒，在抢单的时候可能就永远排不上队。所以每个模块的延迟，我都要求控制在微秒级。
1.3 技术栈概览
做市系统的技术栈，我一般分成三层：
- 底层通信层：FPGA、C++、ZeroMQ、NATS。这一层追求极致的低延迟。我个人习惯用FPGA做行情解析，C++做核心交易逻辑。
- 策略逻辑层：Python、Cython、Rust。Python开发快，但性能不够时我会用Cython重写热点代码。Rust是最近两年开始用的，内存安全确实香。
- 数据与监控层：InfluxDB、ClickHouse、Grafana。时序数据库存行情数据，ClickHouse做回测分析，Grafana看实时监控。
为什么会这样分层？因为不同层对延迟和开发效率的要求完全不同。底层要快，上层要灵活。
核心原则：不要为了炫技而用新技术。我见过有人用Kafka做订单流，结果延迟比Redis高了两个数量级。选技术栈，先看业务场景。
1.4 选型的关键考量因素
选工具的时候，我一般问自己三个问题：
- 延迟要求是多少？高频做市需要微秒级，中低频毫秒级就够了。别一上来就上FPGA，成本高得吓人。
- 团队技术栈是什么？如果团队全是Python背景，硬上C++会死得很惨。我建议先用Python快速迭代，等业务稳定了再优化性能。
- 维护成本高不高？开源工具虽然免费，但出了问题得自己修。商业工具贵，但有技术支持。我个人的经验是：核心模块用商业的，外围用开源的。
避坑指南：我曾经选了一个很冷门的消息队列，结果社区没人维护，出了bug只能自己改源码。后来我学乖了，只选活跃度高的项目，比如Redis、NATS、ZeroMQ。
1.5 做市工具全景结构图
下面这张图，是我自己总结的做市工具全景结构。它把上面讲的分类、模块、技术栈串在了一起：
这张图我画了好几个版本，最后定稿成这样。你看，数据从底层往上流，策略在中间层做决策，执行层负责跟交易所打交道，监控层兜底。每一层都有对应的技术栈和核心模块。
注意：别想着一步到位。我见过太多团队一开始就追求全栈自研，结果半年过去了连个能用的报价引擎都没跑起来。我的建议是：先用现成的工具搭个最小可行系统，跑通了再逐步替换。
好了，做市工具的全景图就讲到这里。下一章我会深入讲报价引擎的设计，那是做市系统的灵魂。到时候我会拿我实际写过的代码来举例，保证干货满满。