一、课程导论：为什么需要多交易所路由？

大家好，我是你们这门课的主讲人。

先问大家一个问题：你手头有 100 个 BTC 要卖掉，你会怎么操作？

很多人第一反应是：挂到币安上，慢慢卖呗。

嗯，这确实是个办法。但如果你真的这么干过，你会发现几个让人头疼的问题：

• 滑点太大——大单砸下去，价格直接被打穿好几个点
• 成交太慢——挂个限价单，等半天才成交一小部分
• 手续费贵——有些交易所 Maker 费率看着低，但实际算下来并不划算

说白了，单一交易所就像只有一个菜市场。你非要在一个摊位买完所有菜，要么贵，要么不新鲜。

多交易所路由，就是帮你解决这个问题的。

1.1 我为什么开始做多交易所路由？

2018 年那会儿，我在一家量化基金做策略开发。当时我们跑一个简单的网格策略，只连了币安一家交易所。

结果呢？

有一次行情剧烈波动，我们的订单因为网络延迟，成交价比预期差了 0.3%。别小看这 0.3%，对于高频策略来说，这就是盈亏的分水岭。

后来我尝试接入火币和 OKX，发现一个有趣的现象：同一时刻，三个交易所的 BTC 价格可能差出 0.1%-0.5%。

这不就是套利机会吗？

但问题来了——手动切换交易所根本来不及。你需要一个自动化的路由系统，帮你判断「哪个交易所价格最好」「哪个交易所流动性最足」「哪个交易所手续费最低」。

这就是多交易所路由的核心价值。

1.2 常见交易场景与痛点分析

我总结了一下，大家做多交易所路由，无非是以下几种场景：

场景	痛点	路由能做什么
大单拆分交易	单笔大单容易造成滑点	将大单拆成小单，分散到多个交易所执行
套利策略	价差转瞬即逝，手动来不及	自动监控价差，快速在两个交易所之间对冲
做市策略	需要在多个交易所同时挂单	统一管理多个交易所的订单簿
资金管理	不同交易所的余额分散，难以统一调度	自动归集资金，按需分配

这些场景背后，其实都指向同一个核心问题：如何高效、稳定地管理多个交易所的 API？

我在项目中遇到过最坑的一件事：某个交易所突然改了 API 签名算法，我们的系统直接瘫痪了 3 个小时。嗯，从那以后，我养成了一个习惯——所有交易所的 API 调用，必须做一层抽象封装。这样就算某个交易所改接口，也只需要改一个地方。

1.3 课程目标与学习路径

这门课的目标很明确：让你从零开始，搭建一套能用于生产环境的多交易所路由系统。

你想想看，如果你能掌握以下能力：

• 用 Python 统一封装 5 家以上交易所的 API
• 实现智能路由算法，自动选择最优交易路径
• 处理各种异常情况（网络超时、交易所宕机、API 限频）
• 搭建实时监控和告警系统

那你在量化交易这个领域，基本就具备了独立作战的能力。

学习路径我建议这样走：

1. 先理解基础——交易所 API 的通用结构、认证方式、数据类型
2. 再动手封装——用 Python 写一个统一的 API 适配层
3. 然后做路由——实现订单拆分、价格比较、路径选择
4. 最后上生产——加入异常处理、日志监控、性能优化

我个人习惯是「先跑通，再优化」。别一开始就想着完美架构，先让代码能跑起来，看到效果，你才有动力继续深入。

1.4 知识体系总览

下面这张图，是我对这门课知识体系的梳理。你可以把它当作一张「藏宝图」，后面每学一章，就回来看看自己走到哪了。

这张图其实就回答了「为什么需要多交易所路由」这个问题。你看，从最底层的 API 协议，到最上层的运维监控，每一层都在解决一个具体的痛点。

基础层解决「怎么连」的问题，适配层解决「怎么统一管理」的问题，路由层解决「怎么选最优路径」的问题，运维层解决「怎么保证稳定运行」的问题。

说白了，多交易所路由不是某个单一技术，而是一整套工程实践。

我记得刚开始带团队的时候，有个新人问我：「老师，我们直接用 CCXT 不就行了吗？为什么还要自己封装？」

我的回答是：CCXT 确实是个好工具，但它只是一个「通用框架」。真正到生产环境，你需要处理的东西远比 CCXT 提供的多——比如自定义的限频策略、交易所特有的错误码、以及各种奇葩的网络异常。

所以这门课，我会带你从底层开始，一步步搭建自己的路由系统。你学完之后，不仅能理解 CCXT 的原理，还能在它的基础上做二次开发，甚至写出比 CCXT 更适合自己业务的路由引擎。

好，导论部分就到这里。下一章，我们直接动手，从「交易所 API 的通用结构」开始讲起。

---