3、路由决策引擎设计：决策流程、核心组件、延迟与成本权衡
路由决策引擎，说白了就是订单路由系统的「大脑」。
我当年刚接触这个模块时，觉得不就是个if-else判断吗？后来被市场狠狠教育了一回——有一次因为决策逻辑里少考虑了一层流动性深度，导致一笔大单被拆成了几十个小单，最后成交均价差了整整两个tick。嗯，从那以后我再也不敢小看这个引擎了。
3.1 决策流程：从订单到路由的完整链路
一个订单进来，引擎要做什么？我习惯把它拆成四个阶段：
- 订单解析：提取订单属性（品种、方向、数量、价格类型）
- 市场状态快照：获取各交易所的实时盘口、延迟、费率
- 路由计算：根据策略模型选出最优路径
- 执行下发：将路由指令发送给交易网关
你想想看，这四个步骤必须在微秒级完成。我见过有些团队把决策流程做成串行的，结果延迟直接飙到毫秒级——这在高频场景下基本等于废了。
核心原则：决策流程必须支持「提前计算 + 运行时查表」的模式。把能预计算的都提前算好，运行时只做最轻量的匹配。
我个人习惯在订单解析阶段就做一次「快速否决」——比如某些交易所根本不支持这个品种，直接跳过，不用等到路由计算阶段再发现。这个优化看似简单，但在高并发下能省下不少CPU周期。
3.2 核心组件：引擎的四大模块
路由决策引擎不是一个大泥球。我把它拆成四个组件，各司其职：
| 组件名称 | 职责 | 性能关键点 |
|---|---|---|
| 市场数据聚合器 | 合并多交易所的实时行情 | 数据对齐、时间戳校准 |
| 路由策略计算器 | 执行具体的路由算法 | 算法复杂度、缓存命中率 |
| 成本评估器 | 计算各路径的显性+隐性成本 | 费率表更新、滑点预估 |
| 延迟监控器 | 实时追踪各交易所的响应时间 | 滑动窗口统计、异常检测 |
这里我要特别说一下「成本评估器」。我在项目中遇到过一个问题：只看手续费率，结果选了最便宜的交易所，但那个交易所流动性极差，滑点成本反而更高。后来我加了一个「综合成本模型」，把手续费、滑点、甚至资金占用成本都算进去。
避坑指南：我曾经把费率表写死在代码里，结果交易所改费率后，系统用了两个小时才反应过来。建议把费率表做成可动态加载的配置，最好支持热更新。
3.3 延迟与成本：一对天生的冤家
做路由决策，本质上就是在延迟和成本之间找平衡。你想想看：
- 选最快的交易所，可能手续费最贵
- 选最便宜的交易所，可能网络延迟高
- 选流动性最好的交易所，可能订单处理慢
我见过一个经典的案例：某团队为了追求最低延迟，把所有订单都发到同一个交易所。结果那个交易所的流动性深度不够，大单进来直接打穿盘口，成交成本反而比分散路由高了30%。
那怎么权衡？我一般用这个公式：
综合成本 = 显性成本（手续费） + 隐性成本（滑点） + 延迟惩罚（时间价值）
延迟惩罚 = 预期延迟 × 单位时间价值系数这个「单位时间价值系数」怎么定？说白了就是你的策略对延迟的敏感度。高频策略这个系数可能设到0.1甚至更高，而套利策略可能只有0.01。
注意：延迟不是越短越好。我见过有人为了省1微秒，把路由逻辑写得极其复杂，结果代码可维护性一塌糊涂。延迟优化要「够用就好」，别过度设计。
3.4 核心逻辑：一张图看懂路由决策
下面这张图是我自己画的路由决策核心流程，你可以看到各个组件是怎么配合的：
这张图里有个细节你可能注意到了——市场数据聚合器和延迟监控器是并行运行的。为什么要并行？因为这两个数据源互不依赖，串行跑只会白白增加延迟。我在实际项目中还加了一层「缓存」，把最近100毫秒的市场快照存下来，避免每次决策都去拉数据。
3.5 实战中的几个关键决策点
说了这么多理论，来点实际的。我总结了几条在项目中踩过的坑：
- 别把所有鸡蛋放一个篮子里：即使某个交易所延迟最低，也要留一个备用路由。我遇到过交易所网络抖动，延迟从100微秒飙到10毫秒，幸好有备用路由顶着。
- 成本模型要动态调整：市场在变，你的成本模型也得跟着变。我习惯每5分钟重新校准一次滑点预估参数。
- 延迟数据要「去毛刺」：单次延迟测量可能不准，用滑动窗口的中位数比平均值更靠谱。我一般取过去20次采样的中位数。
一个小技巧：在路由决策引擎里加一个「快速通道」——对于市价单这种对价格不敏感的订单，直接走延迟最低的交易所，跳过成本评估。这个优化能省下不少计算资源。
嗯，路由决策引擎的设计，说白了就是在「快」和「省」之间找平衡。没有完美的方案，只有最适合你策略的方案。我建议你在做设计时，先想清楚你的策略对延迟和成本的敏感度，然后再决定怎么取舍。
公众号:蓝海资料掘金营，微信deep3321