3. Broker生态概览
在构建多Broker适配层之前，必须先回答一个基础问题：我们究竟要适配哪些Broker？不同Broker在账户体系、行情推送、订单语义、协议栈和接入门槛上差异巨大，如果把它们简单抽象成“下单接口”，适配层会在真实交易场景中迅速崩塌。本节从Broker类型、API差异、接入方式、协议特点和选型考量五个维度建立全景认知。
一、主流Broker类型与业务定位
按业务定位，Broker大致可分为四类。第一类是零售互联网券商，如富途、老虎、盈透（IBKR）等，面向个人投资者，提供REST/WebSocket API，文档完善但权限分级严格。第二类是机构经纪商，如高盛、摩根士丹利的执行服务，通常通过FIX协议对接，强调低延迟和算法交易。第三类是加密货币交易所，如Binance、OKX、Coinbase，API风格统一但限频严格，且存在现货、合约、期权多套接口。第四类是国内券商，多通过CTP、恒生UFT、QMT等柜台系统接入，协议私有化程度高，需要专门的交易前置。
二、API差异：从REST到FIX的谱系
Broker API的差异主要体现在四个维度：传输协议、消息格式、认证方式和推送机制。零售券商普遍采用REST+JSON做查询、WebSocket做行情推送，认证用+Secret或OAuth。机构经纪商则使用FIX 4.2/4.4，消息为Tag=Value文本，认证通过Logon消息携带SenderCompID和TargetCompID。加密货币交易所多为REST+WebSocket，但签名机制复杂，涉及HMAC、RSA或Ed25519。
下面是一段典型的FIX Logon消息与REST下单请求的对比，能直观看出协议差异：
# FIX Logon (Tag=Value)
8=FIX.4.4|9=...|35=A|49=CLIENT|56=BROKER|34=1|
52=20250101-09:30:00|98=0|108=30|141=Y|10=...
# REST下单 (JSON)
POST /v1/order
{
"symbol": "AAPL",
"side": "BUY",
"type": "LIMIT",
"price": 185.50,
"qty": 100,
"timeInForce": "DAY"
}适配层的核心任务，就是把这两种截然不同的表达统一成内部订单模型。差异越大，适配层需要的“翻译”逻辑就越厚。
三、接入方式与协议特点
接入方式可分为直连、网关和托管三类。直连是客户端直接连接Broker API，延迟低但需要自行处理重连、限频和证书轮换。网关是在客户端与Broker之间加一层代理，统一鉴权、限流和日志，适合多账户场景。托管则是把策略部署在Broker或云厂商的托管环境，网络路径最短，但灵活性受限。
协议特点方面，REST适合请求-响应型操作，如查持仓、下单；WebSocket适合行情和订单状态推送；FIX适合高频、低延迟的机构场景；而国内CTP使用私有二进制协议，需通过C++或Python封装库接入。理解这些特点，才能在适配层中为不同Broker选择正确的连接策略。
四、选型考量与常见误区
选型时建议从六个维度打分：市场覆盖、API成熟度、限频与稳定性、成本结构、合规要求和技术栈匹配度。下表给出一个简化的评估清单，可直接用于团队内部评审。
| 维度 | 关键问题 | 权重建议 |
|---|---|---|
| 市场覆盖 | 是否覆盖目标交易所与品种？ | 高 |
| API成熟度 | 文档、SDK、沙箱是否完善？ | 高 |
| 限频与稳定性 | 每秒请求上限、断线重连策略？ | 高 |
| 成本结构 | 佣金、数据费、API调用费？ | 中 |
| 合规要求 | 是否满足当地监管与审计？ | 高 |
| 技术栈匹配 | 是否支持Python/Java/Go？ | 中 |
五、案例：一个跨市场适配场景
假设策略需要同时交易和加密货币。走IBKR的FIX接口，加密货币走Binance的REST+WebSocket。适配层需要做三件事：第一，定义统一的Order结构，包含symbol、side、type、price、qty、timeInForce；第二，为IBKR实现FIX会话管理，为Binance实现签名与限频；第三，统一订单状态机，把FIX的ExecType和Binance的orderStatus映射到内部状态。这个案例说明，Broker生态的差异最终会沉淀为适配层的映射表和连接管理器。
复盘来看，成功的适配层不是追求“一套代码适配所有Broker”，而是建立清晰的边界：连接层负责协议差异，映射层负责语义差异，业务层只面对统一接口。理解Broker生态的全貌，是设计这层边界的前提。