第2章做市商系统架构

第2章：做市商系统架构：系统整体架构设计、核心模块划分、技术栈选型与数据流

做市商系统，说白了就是一台精密的「赚钱机器」。但机器要跑得稳，架构得先搭对。我见过不少团队，一上来就写代码，结果做到一半发现数据流不通，或者风控模块成了摆设——嗯，这种坑我踩过不少。

今天咱们就聊聊，一个靠谱的做市商系统，到底该怎么搭。

我个人习惯把做市商系统分成四层。为什么是四层？因为每一层都有它自己的「脾气」，混在一起容易出乱子。

你想想看，如果风控和策略写在一个进程里，策略崩了风控也跟着挂——那还控个啥？所以分层不只是为了好看，是为了保命。

  核心原则：每一层都可以独立升级、独立重启，不影响其他层。

模块划分这事儿，我踩过最大的坑就是「过度设计」。一开始恨不得把每个功能都拆成微服务，结果光服务间通信就占了30%的CPU。后来我学乖了——该合的就合，该拆的才拆。

行情是系统的「眼睛」。它负责从交易所拉取深度、成交、Ticker等数据。这里要注意的是：行情数据是有时效性的。延迟超过100ms，你的报价可能就已经过时了。

小技巧：我曾经用Redis的Stream做行情广播，比直接发消息队列延迟更低。但要注意内存占用，别把全量深度都塞进去。

策略引擎是系统的「大脑」。它接收行情，计算报价，生成订单。我个人建议把策略做成「插件化」的——这样换策略不用重启整个系统。

// 伪代码示例：策略接口
type Strategy interface {
    OnTick(tick *Tick) []*Order
    OnOrderFilled(order *Order)
    OnOrderCancelled(order *Order)
}

你看，接口就这么简单。但实际实现时，要考虑的东西就多了——比如订单状态管理、重试逻辑、滑点控制。

风控是系统的「刹车」。没有刹车的车，你敢开吗？我曾经见过一个团队，风控模块只是个「日志记录器」——出了事才回头看日志，那还有什么用？

注意：风控模块必须独立部署，且拥有「最高权限」。策略不能绕过风控直接发单。

订单管理是系统的「手」。它负责把策略生成的订单发到交易所，并跟踪订单状态。这里有个坑：交易所的订单状态回调可能延迟或丢失。所以一定要有「主动查询」机制。

技术栈选型这事儿，没有银弹。我根据自己的经验，给出一套经过实战检验的组合：

我的建议：不要为了「炫技」而用新技术。做市商系统追求的是稳定和可维护性。Go + Python的组合，我用了三年，没出过大问题。

数据流是系统的「血管」。血流通畅，系统才能健康。我画了一张图，帮你理解数据是怎么流动的：

数据流的核心逻辑其实很简单：

  关键点：数据流必须是「单向」的。策略不能直接发单，必须经过风控。风控不能修改订单内容，只能通过或拒绝。

最后，分享几个我亲身踩过的坑：

嗯，架构设计这块，今天就聊到这儿。记住一句话：好的架构不是设计出来的，是改出来的。先跑起来，再优化，别一开始就想搞个完美的。