4、订单路由基础：智能路由的概念、路由规则引擎、最优执行策略
做市商系统里，订单路由这块，说白了就是「把单子送到最合适的地方去」。
你可能觉得，不就是发个单子吗？交易所API一调不就完了？
嗯，我刚开始也这么想。直到有一次，我负责的一个做市策略在币安和OKX两边同时挂单，结果行情剧烈波动时，一边成交了，另一边没成交，导致库存严重偏斜，亏了不少钱。从那以后，我才真正重视起订单路由来。
4.1 智能路由的概念
智能路由，英文叫Smart Order Routing，简称SOR。它不是简单地把订单扔给某个交易所，而是根据实时市场状态，动态决策「去哪下单、下什么单、怎么下」。
我个人习惯把智能路由拆成三个核心能力：
- 感知能力：实时监控多个交易所的深度、价差、延迟、费率
- 决策能力：根据规则或算法，选出最优执行路径
- 执行能力：把大单拆成小单，分批或并行发送到不同场所
你想想看，如果只有一家交易所，那路由就是个摆设。但现实是做市商通常对接5-10家交易所，甚至更多。每家流动性、手续费、网络延迟都不一样，这时候智能路由的价值就体现出来了。
核心观点：智能路由不是「选一个最好的交易所」，而是「在多个交易所之间动态分配订单，使得整体执行成本最低」。
4.2 路由规则引擎
路由规则引擎，是智能路由的大脑。它负责把「业务逻辑」翻译成「机器可执行的决策」。我见过不少团队，把路由规则硬编码在代码里，结果每次改规则都要重新部署，非常痛苦。
我建议用规则引擎的方式来做。说白了，就是定义一组「条件-动作」对：
// 伪代码示例：路由规则引擎的核心结构
Rule {
condition: (order, marketState) => boolean
action: (order, marketState) => RoutingDecision
}
// 一个实际例子：如果A交易所的价差小于B交易所，且延迟低于50ms，则优先路由到A
Rule {
condition: (order, state) => {
return state.exchangeA.spread < state.exchangeB.spread
&& state.exchangeA.latency < 50
}
action: (order, state) => {
return new RoutingDecision('exchangeA', order.quantity)
}
}
常见的路由规则类型，我整理了一下：
| 规则类型 | 说明 | 我在项目中遇到过的问题 |
|---|---|---|
| 价差优先 | 选择价差最小的交易所 | 价差小但深度浅，大单容易滑点 |
| 深度优先 | 选择挂单量最大的交易所 | 深度大但手续费高，小单不划算 |
| 延迟优先 | 选择网络延迟最低的交易所 | 延迟低但偶尔丢包，需要重试机制 |
| 费率优先 | 选择手续费最低的交易所 | 费率低但流动性差，大单执行困难 |
| 综合评分 | 加权计算多个维度的得分 | 权重设置需要回测，否则容易过拟合 |
我的经验：不要只用单一规则。我一般会设计一个「规则链」，按优先级依次判断。比如先看价差，如果价差在可接受范围内，再看深度和费率。这样既灵活又可控。
4.3 最优执行策略
有了规则引擎，接下来就是执行策略了。最优执行策略，解决的是「怎么把订单拆开、分到不同交易所、在什么时间点发出去」的问题。
这里我画了一张图，帮你理解整个流程：
常见的执行策略，我按复杂度排了个序：
- 直接路由：最简单，规则引擎选一个交易所，全量发过去。适合小单、对时效要求高的场景。
- 比例分配：按固定比例把订单分到多个交易所。比如A交易所60%，B交易所40%。适合流动性分散的场景。
- 动态分配：根据实时深度和价差，动态调整分配比例。我一般用这个，效果比较稳。
- 时间切片：把大单按时间切片，每个时间片发一部分。适合大单，避免冲击市场。
- 冰山订单：只暴露小部分订单量，隐藏真实意图。做市商常用，防止被对手盘狙击。
避坑指南：我曾经在动态分配策略里，直接用「当前价差」作为唯一指标。结果遇到一次行情剧烈波动，价差瞬间拉大，系统把所有订单都路由到了同一个交易所，导致那个交易所的订单堆积，执行延迟暴增。后来我加了「延迟阈值」和「最大分配比例」两个限制，才解决这个问题。
4.4 实战中的路由优化
理论说完了，聊聊实战中的几个优化点。
第一，延迟测量要准。路由决策依赖延迟数据，但延迟是动态变化的。我建议用「滑动窗口均值」而不是「瞬时值」。比如取最近100笔订单的往返延迟平均值，这样更稳定。
第二，要有熔断机制。如果某个交易所连续3次路由失败，或者延迟超过200ms，应该暂时把它从路由候选列表中移除。等恢复后再加回来。
第三，日志要详细。每次路由决策，都要记录：时间、订单ID、选择的交易所、分配数量、决策原因。这样出了问题才能回溯。
// 路由日志示例
{
"timestamp": "2025-01-15 14:23:45.123",
"orderId": "ORD-20250115-001",
"symbol": "BTC-USDT",
"side": "BUY",
"quantity": 2.5,
"decisions": [
{"exchange": "Binance", "quantity": 1.0, "reason": "价差最小(0.01%)"},
{"exchange": "OKX", "quantity": 0.8, "reason": "深度最大(120 BTC)"},
{"exchange": "Bybit", "quantity": 0.7, "reason": "费率最低(-0.005%)"}
],
"totalCost": 0.0032,
"executionTime": 45
}
一个小技巧：路由规则引擎的规则，最好做成可配置的，通过配置文件或管理后台动态调整。我见过太多团队，每次改规则都要改代码、走发布流程，效率极低。用规则引擎，改个配置就能生效，省心很多。
嗯，订单路由基础就聊这么多。核心就三件事：感知市场、规则决策、最优执行。把这三点做好了，做市商的订单执行效率能提升不少。