订单路由架构：智能订单路由（SOR）的核心组件与设计原则

跨所套利的核心，说白了就是「快」和「准」。

你同时盯着两个交易所的价差，发现机会了，得把单子发过去。但往哪发？发多少？走哪条线路？这就是智能订单路由（SOR）要干的事。我做了这么多年低延迟系统，见过太多团队在SOR上栽跟头——要么路由逻辑太笨，要么延迟高到套利变亏损。

1. SOR的核心使命

智能订单路由不是简单的「选个交易所发单」。它要回答三个问题：

• 去哪交易？——哪个市场流动性最好？
• 怎么拆单？——大单要不要切碎？
• 走哪条路？——网络延迟最低的路径是哪条？

嗯，这三个问题，每一个都能写一本书。但今天我只讲实战中最关键的组件和原则。

2. 核心组件拆解

2.1 市场状态感知模块

这个模块负责实时拉取各交易所的行情数据。包括：

• 买卖盘口深度（L2/L3数据）
• 最新成交价与成交量
• 交易所状态（正常/熔断/维护）

我在项目中遇到过一个问题：某交易所的行情推送偶尔会延迟200ms。如果你不感知这个延迟，SOR会以为那个市场流动性很好，结果单子发过去时价格已经变了。所以，一定要给每个数据源打上时间戳。

2.2 路由决策引擎

这是SOR的大脑。它根据市场状态和策略参数，决定：

• 目标交易所
• 订单类型（限价单/市价单）
• 订单数量
• 路由优先级

决策引擎的典型伪代码长这样：

// 伪代码：路由决策逻辑
function routeOrder(order, marketState):
    // 1. 过滤不可用交易所
    available = filterByStatus(marketState)
    
    // 2. 按流动性排序
    sorted = sortByLiquidity(available)
    
    // 3. 检查价差是否满足阈值
    for exchange in sorted:
        if checkSpread(exchange, order) > minSpread:
            return exchange
    
    // 4. 如果都不满足，等待或取消
    return null

你想想看，这个逻辑看起来简单，但实际坑很多。比如排序算法本身就有延迟，如果你用冒泡排序去排100个交易所，那黄花菜都凉了。我建议用预排序+增量更新的方式。

2.3 订单执行与监控模块

决策完了，得把单子发出去。这个模块负责：

• 建立并维护到各交易所的连接
• 发送订单并接收确认
• 监控订单状态（已提交/部分成交/完全成交/已撤销）
• 处理异常（超时、拒单、连接断开）

3. 设计原则

3.1 低延迟优先

跨所套利，延迟就是生命。SOR的每个环节都要考虑延迟：

• 数据路径：行情数据走UDP组播，不要走TCP
• 决策路径：用C++或Rust实现核心逻辑，避免GC停顿
• 网络路径：尽量与交易所同机房，或者走专线

我记得有一次，我们把路由决策从Python改成C++，延迟从50微秒降到了3微秒。嗯，这个优化直接让套利策略的年化收益提升了15%。

3.2 容错与降级

交易所一定会出问题。不是如果，而是什么时候。所以SOR必须设计容错机制：

• 熔断：如果某个交易所连续3次拒单，自动熔断5秒
• 降级：如果主线路断了，自动切换到备用线路
• 回退：如果所有交易所都不可用，取消订单并报警

3.3 可观测性

你没法优化你看不到的东西。SOR必须暴露关键指标：

指标	说明	告警阈值
路由决策延迟	从收到行情到发出订单的时间	> 100μs
订单成交率	发出的订单最终成交的比例	< 80%
交易所连接状态	各交易所的连接是否正常	断开即告警
滑点统计	实际成交价与决策时价格的差异	> 0.1%

4. SOR架构图

下面这张图展示了SOR的核心组件和数据流。我建议你把它打印出来贴在工位上。

5. 总结

智能订单路由不是银弹。它解决的是「在多个市场间高效分配订单」的问题，但前提是你得有足够好的行情数据和低延迟网络。

我个人习惯是：先做对，再做快。先把路由逻辑跑通，确保不会出现「发错交易所」这种低级错误，然后再一点点抠延迟。你想想看，如果路由逻辑本身有bug，延迟再低又有什么用？