系统架构剖析：做市商系统的三层架构
做市商系统，说白了就是一台高速运转的印钞机——前提是你得把它调教好。我见过太多团队，代码写得花里胡哨，结果一到实盘就卡成PPT。今天咱们就来拆解一下，典型的做市商系统到底长什么样，以及每一层最容易在哪儿翻车。
一、整体架构概览
先画个图，让你对整体有个直观印象。我个人习惯把做市商系统分成三层：行情层、策略层、交易层。每一层都有自己的职责，也都有自己的坑。
你想想看，这三层就像一条流水线。行情层负责把原始数据喂进来，策略层负责算该不该下单，交易层负责把单子发出去。哪一层慢了，整个系统都得跟着遭殃。
二、行情层：数据管道的第一个瓶颈
行情层是系统的入口，也是我见过问题最多的地方。很多团队一上来就追求高吞吐，结果忽略了最基础的东西。
2.1 行情层的核心职责
- 数据源接入：从交易所、数据商获取原始行情
- 行情解码：解析二进制协议（如FIX、Binary、UDP组播）
- 行情缓存：维护快照、增量、订单簿状态
- 行情分发：将处理后的数据推送给策略层
2.2 常见性能瓶颈
| 瓶颈模式 | 典型表现 | 根因分析 |
|---|---|---|
| 解码延迟高 | 行情到达后，CPU占用飙升 | 使用了低效的解析库，或者频繁内存分配 |
| 缓存竞争激烈 | 多线程访问订单簿时锁冲突严重 | 读写锁设计不合理，或者用了全局锁 |
| 分发阻塞 | 一个慢消费者拖慢整个行情流 | 无背压机制，队列无界增长 |
| 内存带宽瓶颈 | 行情数据量大，内存拷贝频繁 | 未使用零拷贝技术，数据在堆内外反复搬运 |
我在项目中遇到过最离谱的一次，是某团队用Python的json库解析行情。嗯，你没听错，用json解析高频行情。结果就是行情还没解析完，下一笔已经来了。后来换成C++手写的二进制解析器，延迟直接降了两个数量级。
三、策略层：算力与延迟的博弈
策略层是做市商的大脑。这里要算的东西很多：订单簿深度、价差、库存风险、信号生成。算得快不一定赚钱，但算得慢一定亏钱。
3.1 策略层的核心职责
- 订单簿管理：维护买卖盘口的实时状态
- 定价引擎：根据市场状态计算最优报价
- 风险管理：检查净头寸、最大订单量、资金限制
- 信号生成：决定是否调整报价、撤单、对冲
3.2 常见性能瓶颈
| 瓶颈模式 | 典型表现 | 根因分析 |
|---|---|---|
| 订单簿重建慢 | 每次快照到来都要全量重建 | 未使用增量更新，或者数据结构选择不当 |
| 定价计算超时 | 策略循环超过行情间隔 | 算法复杂度高，或者使用了浮点运算 |
| 风险检查过重 | 每次下单前都要做全量风控 | 风控逻辑未分层，高频检查与低频检查混在一起 |
| GC暂停 | Java/C#等语言出现STW停顿 | 对象分配频繁，GC来不及回收 |
我曾经在一个项目中，发现策略层每次定价都要遍历整个订单簿。当时我就觉得不对劲——你想想看，一个深度100档的订单簿，每次遍历就是O(n)的复杂度。后来改成只维护前10档的局部视图，定价延迟从15微秒降到了2微秒。嗯，有时候优化就是这么简单。
四、交易层：最后一公里的生死时速
交易层是系统的出口。行情算得再快，单子发不出去也是白搭。这里最怕的就是「发出去没响应」或者「响应回来了但已经晚了」。
4.1 交易层的核心职责
- 订单管理：维护订单状态机（新单、部分成交、完全成交、撤单）
- 路由决策：选择最优交易所或交易通道
- 交易所接口：封装FIX、REST、WebSocket等协议
- 成交回报：处理交易所返回的成交确认
4.2 常见性能瓶颈
| 瓶颈模式 | 典型表现 | 根因分析 |
|---|---|---|
| 网络延迟抖动 | 同一交易所，延迟忽高忽低 | 未使用专用线路，或者TCP拥塞控制导致 |
| 序列化/反序列化慢 | FIX消息编码解码耗时高 | 使用了通用XML解析器，而非手写优化 |
| 订单状态机阻塞 | 一个订单卡住，后续订单无法处理 | 状态机设计为单线程串行，无超时机制 |
| 日志写入拖慢 | 每条订单都写磁盘，导致IO等待 | 同步日志写入，未使用异步日志或内存缓冲 |
五、三层之间的交互模式
三层之间不是孤立的，它们通过消息传递来协作。这里也有几个常见的坑。
5.1 消息传递方式
- 共享内存：延迟最低，但需要处理并发访问
- 无锁队列：适合单生产者单消费者场景
- Ring Buffer：适合高吞吐、低延迟的场景
- TCP/UDP Socket：适合跨进程或跨机器通信
5.2 常见交互问题
| 问题模式 | 影响 | 解决方案 |
|---|---|---|
| 行情层到策略层：数据拷贝 | 每次传递都复制一份行情数据 | 使用零拷贝技术，传递指针或索引 |
| 策略层到交易层：信号丢失 | 策略生成了信号，但交易层没收到 | 使用确认机制，或者带超时的重试 |
| 交易层回传：成交回报延迟 | 成交回报走的是另一个通道，时序错乱 | 使用时间戳对齐，或者统一时钟源 |
说白了，三层之间的交互就是「快」和「稳」的平衡。太快了容易丢数据，太稳了又容易慢。我个人习惯的做法是：行情层到策略层用无锁队列，策略层到交易层用带确认的共享内存。这样既保证了速度，又不会丢单。
六、总结：性能优化的核心思路
好了，咱们把三层架构和各自的瓶颈都过了一遍。最后总结几个核心思路：
- 先测量，再优化：别凭感觉改代码。用perf、火焰图、延迟直方图先定位瓶颈在哪一层。
- 分层隔离：每一层的问题不要扩散到其他层。行情层慢了别影响策略层，策略层卡了别阻塞交易层。
- 关注尾部延迟：平均延迟好看没用，P99延迟才是做市商的生命线。一次卡顿可能就让你错过一个价差。
- 减少不必要的抽象：做市商系统不是企业级应用，别搞什么工厂模式、观察者模式。越直接越好，越简单越快。
公众号:蓝海资料掘金营，微信deep3321