一、做市商系统概述：什么是做市商、核心业务逻辑与技术架构挑战
1.1 做市商到底是什么？
做市商，说白了就是「双边报价的庄家」。
我经常跟团队新人这么解释：你去菜市场买菜，有个摊位永远同时挂着「收购价」和「卖出价」。你急着卖菜，他按收购价收；你急着买菜，他按卖出价卖。他赚的就是中间的差价——这就是做市商。
在金融市场里，做市商是交易所认可的机构。它们对某个品种（比如BTC/USDT、ETH/USDT）同时报出买价和卖价。买价叫Bid，卖价叫Ask。Bid和Ask之间的差距，就是Spread（价差）。
核心定义：做市商 = 持续提供双边报价 + 承担库存风险 + 赚取买卖价差
嗯，这里要注意：做市商不是投机者。投机者赌方向，做市商赚流动性。我见过不少团队把做市做成了方向交易，结果亏得很惨。这是本质区别。
1.2 做市商的核心业务逻辑
做市商的业务逻辑，其实就三件事：
- 报价——在多个价位挂买单和卖单
- 成交——有人买就卖给他，有人卖就买进来
- 风控——控制库存，别让自己爆仓
我画了一张图，帮你理解这个循环：
你看，这四个模块是环环相扣的。报价引擎算出价格，订单管理去执行，风控系统盯着风险，盈亏核算告诉你赚了多少。任何一个环节出问题，整个系统就崩了。
1.3 做市商到底怎么赚钱？
这个问题我经常被问到。做市商的盈利模式其实很清晰：
| 收入来源 | 说明 | 占比（典型） |
|---|---|---|
| 买卖价差 | 低买高卖，赚取Bid-Ask之间的差价 | 40%-60% |
| 交易所返佣 | 做市商提供流动性，交易所给手续费折扣甚至返现 | 20%-30% |
| 资金费率套利 | 永续合约市场，利用资金费率差异套利 | 10%-20% |
| 价差回归收益 | 利用统计套利模型，赚取价格回归的收益 | 5%-10% |
我在做第一个做市商系统时，犯过一个低级错误：只盯着价差收入，忽略了返佣。后来一算账，返佣占了总利润的30%以上。嗯，从那以后我再也不敢小看任何一块收入了。
1.4 技术架构的挑战
做市商系统跟普通交易系统不一样。它的挑战非常具体：
挑战一：超低延迟
做市商拼的就是速度。你报价慢了0.1秒，别人就抢在你前面成交了。我见过一个团队，他们的系统延迟从2毫秒优化到0.5毫秒，月利润直接翻倍。为什么？因为你的报价总是比市场慢半拍，你就是在给市场送钱。
我的经验：延迟优化不是一锤子买卖。从网络层、应用层、数据库层，每一层都有优化空间。我曾经把一台服务器的网卡驱动换了个版本，延迟就降了30%。
挑战二：高并发处理
做市商系统每秒可能要处理几万甚至几十万笔订单。行情数据更是海量。你想想看，光是一个BTC/USDT的深度数据，每秒就能产生上千次变化。系统扛不住，报价就断了。
挑战三：库存风险管理
这是最容易被忽视的。做市商手里永远有库存。市场剧烈波动时，库存可能瞬间亏掉几百万。我见过一个团队，系统在极端行情下没来得及撤单，库存从100个BTC变成了1000个BTC，直接爆仓。
警告：做市商系统必须内置熔断机制。当库存超过阈值时，系统要自动停止报价，甚至反向对冲。这不是可选项，是必选项。
挑战四：多交易所对接
现在的做市商很少只做一个交易所。Binance、OKX、Bybit、Deribit……每个交易所的API都不一样。有的用WebSocket，有的用gRPC，有的用REST。对接一个交易所不难，对接十个就麻烦了。
1.5 技术架构的目标
基于上面的挑战，做市商系统的技术架构应该达到这几个目标：
- 高可用（99.99%+）——系统不能宕机，哪怕1分钟都不行。我建议做多活部署，至少两个机房同时运行。
- 低延迟（<1ms）——从行情接收到报价发出，端到端延迟控制在1毫秒以内。这需要C++或Rust来实现核心链路。
- 高吞吐（10万+ TPS）——系统要能处理每秒10万笔以上的订单。Go语言在这个场景下表现不错。
- 可扩展——加一个交易所、加一个品种，不能改代码。配置化、插件化是必须的。
- 可观测——每个环节都要有监控。延迟、成交率、库存、PnL，全部可视化。我曾经因为一个监控没做好，亏了三天才发现问题。
一句话总结：做市商系统的本质，是用技术手段把「流动性」这个商品卖出去。你的技术越强，流动性越好，赚的钱就越多。
好了，这一章我们聊了做市商是什么、怎么赚钱、技术上面临哪些挑战。下一章我会深入讲「报价引擎」的设计——这是整个系统的心脏。到时候我会分享一些具体的算法和代码，敬请期待。