CEX API接口架构详解

文档概述

本文档详细介绍加密货币交易所(CEX)对外提供的各类API接口，分析不同接口的功能、特点和适用场景。

接口架构总览

对于CEX交易所,通常会采用分层接口架构:

1. 核心层: FIX API - 服务机构客户和做市商
2. 专业层: WebSocket - 服务量化交易者和专业个人交易者
3. 普通层: REST API - 服务普通零售用户
4. 优化层: SBE - 为极致性能需求提供选项

这种分层设计既能满足不同用户群体的需求,又能合理分配系统资源。

以Binance为例(参考 Binance API文档):

交易所对外提供的主要接口类型及其功能如下:

接口对比与选择

接口功能对比

接口性能对比

注: SBE不是独立接口，而是FIX API的一种编码格式（见下文详细说明） 

适用场景对比

接口选择决策树

需要下单?
├─ 是 → 需要极致性能?
│      ├─ 是 → FIX API (SBE编码, 端口9002)
│      └─ 否 → REST API
│
└─ 否 → 只需要行情?
       ├─ 机构级性能 → FIX Market Data (SBE编码)
       └─ 普通需求 → WebSocket Streams (JSON)

接口特性对比

接口性能与功能对比

DNS负载均衡策略对比

一、FIX API接口

1.1 协议概述

FIX (Financial Information eXchange) 是金融行业标准的电子交易协议，专为高频交易和机构级交易设计。

开发工具:

• QuickFIX: C++/Java/Python FIX引擎
• SBE工具: 官方SBE代码生成器

关键步骤:

1. 生成Ed25519密钥对
2. 配置API Key权限
3. 实现Logon签名算法
4. 处理心跳和TestRequest
5. 实现消息序列号管理
6. 处理ExecutionReport
7. 实现错误处理和重连

1.2 三种会话类型

1.2.1 订单接入会话 (Order Entry Session)

端点:

• tcp+tls://fix-oe.binance.com:9000 - FIX文本编码
• tcp+tls://fix-oe.binance.com:9001 - FIX请求 → FIX SBE响应
• tcp+tls://fix-oe.binance.com:9002 - FIX SBE请求 → FIX SBE响应

DNS策略:

• 采用Route 53加权轮询策略 (50:50权重)
• 后端为2个独立EC2实例 (ap-northeast-1):
  • 13.115.103.47 (ec2-13-115-103-47.ap-northeast-1.compute.amazonaws.com)
  • 52.196.126.248 (ec2-52-196-126-248.ap-northeast-1.compute.amazonaws.com)
• DNS TTL: 60秒
• 建议: 测试两个IP的延迟稳定性，选择更优的IP硬编码连接

支持操作:

• 下单 (NewOrderSingle)
• 撤单 (OrderCancelRequest)
• 改单 (OrderCancelRequestAndNewOrderSingle)
• 批量撤单 (OrderMassCancelRequest)
• 订单列表 (NewOrderList - OCO/OTO/OTOCO)
• 查询限制使用情况 (LimitQuery)

性能指标:

• 消息限制: 每10秒10,000条消息
• 连接限制: 每账户最多10个并发TCP连接
• 延迟: 亚毫秒级

权限要求:

• API Key必须配置 FIX_API 权限
• 仅支持 Ed25519 密钥

1.2.2 Drop Copy会话 (订单副本会话)

端点:

• tcp+tls://fix-dc.binance.com:9000
• tcp+tls://fix-dc.binance.com:9001
• tcp+tls://fix-dc.binance.com:9002

DNS策略:

• 采用Route 53加权轮询策略 (50:50权重)
• 后端为2个独立EC2实例 (ap-northeast-1):
  • 54.64.43.188 (ec2-54-64-43-188.ap-northeast-1.compute.amazonaws.com)
  • 54.64.88.217 (ec2-54-64-88-217.ap-northeast-1.compute.amazonaws.com)

功能:

• 接收账户所有订单的ExecutionReport
• 接收所有ListStatus消息
• 只读模式，不支持下单或撤单

性能指标:

• 消息限制: 每60秒60条消息
• 连接限制: 每账户最多10个并发TCP连接

权限要求:

• API Key可配置 FIX_API 或 FIX_API_READ_ONLY 权限

适用场景:

• 风控系统监控
• 订单审计
• 多系统订单同步
• 合规报告

1.2.3 Market Data会话 (市场数据会话)

端点:

• tcp+tls://fix-md.binance.com:9000
• tcp+tls://fix-md.binance.com:9001
• tcp+tls://fix-md.binance.com:9002

DNS策略:

• 采用Route 53加权轮询策略 (50:50权重)
• 后端为2个独立EC2实例 (ap-northeast-1):
  • 18.178.146.157 (ec2-18-178-146-157.ap-northeast-1.compute.amazonaws.com)
  • 35.75.126.120 (ec2-35-75-126-120.ap-northeast-1.compute.amazonaws.com)

功能:

• 市场数据流订阅
• 活跃交易对查询
• 不支持下单或撤单

性能指标:

• 消息限制: 每60秒2000条消息
• 连接限制: 每账户最多100个并发TCP连接
• 单连接最多监听1000个数据流

权限要求:

• API Key可配置 FIX_API 或 FIX_API_READ_ONLY 权限

1.3 FIX编码格式

重要: FIX API支持两种编码格式，通过不同端口访问：

1.3.1 FIX文本编码 (端口9000)

特点:

• 人类可读的文本格式
• 使用 | (SOH字符) 作为字段分隔符
• 便于调试和日志分析
• 消息体积较大

示例消息:

8=FIX.4.4|9=114|35=D|34=2|49=qNXO12fH|52=20240611-09:01:46.228|56=SPOT|11=1718096506197867067|38=5|40=2|44=10|54=1|55=LTCBNB|59=4|10=016|

1.3.2 FIX SBE编码 (端口9001/9002)

SBE (Simple Binary Encoding) 是FIX协议的二进制编码格式，不是独立的接口。

特点:

• 二进制格式，机器高效
• 消息体积减少30-50%
• 序列化/反序列化速度更快
• 使用schema文件定义消息格式
• 需要专门的SBE解码器

消息结构:

<SOFH (8字节)> <消息头 (20字节)> <消息体 (N字节)>

端口配置:

• 端口9001: 发送FIX文本请求，接收FIX SBE响应（混合模式）
• 端口9002: 发送FIX SBE请求，接收FIX SBE响应（纯SBE模式）

性能优势:

• 更小的网络带宽占用
• 更快的消息处理速度
• 更低的CPU使用率
• 适合极致性能要求的HFT场景

1.4 FIX API核心特性

1.4.1 消息处理顺序

UNORDERED模式 (推荐):

• 客户端消息可以按任意顺序发送到撮合引擎
• 提供更好的并发性能
• 适合多线程下单场景

SEQUENTIAL模式:

• 消息严格按 MsgSeqNum 顺序处理
• 保证消息顺序性
• 可能影响性能

1.4.2 响应模式

EVERYTHING模式 (默认):

• 接收账户所有订单的ExecutionReport
• 包括其他连接和非FIX API下的订单

ONLY_ACKS模式:

• 仅接收ACK消息
• 禁用ExecutionReport推送
• 减少网络流量

1.4.3 时间同步安全

• 所有请求需要 SendingTime 字段
• 可选 RecvWindow 参数指定请求有效期
• 默认RecvWindow: Logon请求5000ms，其他请求无限制
• 最大RecvWindow: 60000ms

1.4.4 连接生命周期

连接管理:

• 会话尽可能长时间保持开放
• 无最短连接时间保证
• 服务器维护时会提前10分钟通知

心跳机制:

• HeartBtInt范围: 5-60秒
• 服务器在间隔内无消息时发送HeartBeat
• 服务器在间隔内无收到消息时发送TestRequest
• 客户端必须响应TestRequest，否则连接断开

优雅断开:

• 客户端应发送Logout消息关闭会话
• 未发送Logout会导致2x HeartBtInt时间内无法重连

1.5 限制和配额

消息限制

• 订单接入: 每10秒10,000条消息
• Drop Copy: 每60秒60条消息
• Market Data: 每60秒2000条消息

连接限制

• 订单接入:
  • 30秒内最多15次连接尝试
  • 每账户最多10个并发TCP连接
• Drop Copy:
  • 30秒内最多15次连接尝试
  • 每账户最多10个并发TCP连接
• Market Data:
  • 300秒内最多300次连接尝试
  • 每账户最多100个并发TCP连接
  • 单连接最多1000个数据流

未成交订单计数

• 按账户统计
• 不同订单类型占用不同计数
• 订单完全成交后释放计数

1.6 适用场景

HFT下单操作: 必须使用FIX API订单接入会话，推荐使用FIX SBE编码(端口9002)以获得最佳性能。

最适合:

• 高频交易(HFT)公司
• 做市商
• 机构投资者
• 量化交易团队
• 需要极致性能的专业交易者

优势:

• 行业标准协议
• 超低延迟
• 高吞吐量
• 成熟的生态系统
• 丰富的工具链

劣势:

• 学习曲线陡峭
• 实现复杂度高
• 需要专业知识
• 调试相对困难

二、WebSocket接口

WebSocket接口支持两种编码格式：

2.1 WebSocket Streams (JSON编码) - 推荐大多数用户

基本信息

端点:

• wss://stream.binance.com:9443
• wss://stream.binance.com:443
• wss://data-stream.binance.vision (仅市场数据，无账户信息)

DNS策略:

• stream.binance.com: 采用随机负载均衡策略，后端为约170个EC2实例池 (ap-northeast-1)
• data-stream.binance.vision: 采用多值应答策略，一次返回8个EC2实例IP (ap-northeast-1)

协议: WebSocket (基于HTTP升级) 编码: JSON (文本格式) 连接有效期: 24小时 认证: 无需API Key (公开市场数据)

开发工具:

• ws (Node.js)
• websocket-client (Python)
• okhttp (Java)

关键步骤:

1. 建立WebSocket连接
2. 实现PING/PONG处理
3. 订阅所需数据流
4. 解析JSON消息
5. 实现断线重连
6. 维护本地order book

2.1.2 支持的数据流

交易数据:

• 归集交易 (@aggTrade) - 实时
• 逐笔交易 (@trade) - 实时

K线数据:

• UTC K线 (@kline_) - 1s/2s更新
• 带时区偏移的K线 (@kline_@+08:00)
• 支持间隔: 1m, 3m, 5m, 15m, 30m, 1h, 2h, 4h, 6h, 8h, 12h, 1d, 3d, 1w, 1M

Ticker数据:

• 精简Ticker (@miniTicker) - 1000ms
• 完整Ticker (@ticker) - 1000ms
• 全市场Ticker (!miniTicker@arr, !ticker@arr)
• 滚动窗口统计 (@ticker_<window_size>) - 1h/4h/1d

深度数据:

• 最优挂单 (@bookTicker) - 实时
• 有限档深度 (@depth) - 1000ms/100ms, levels=5/10/20
• 增量深度 (@depth) - 1000ms/100ms

其他数据:

• 平均价格 (@avgPrice) - 1000ms

2.1.3 连接管理

订阅方式:

• 直接访问: /ws/<stream_name>
• 组合streams: /stream?streams=<stream1>/<stream2>/<stream3>

实时订阅/取消:

// 订阅
{"method":"SUBSCRIBE","params":["btcusdt@aggTrade","btcusdt@depth"],"id":1}

// 取消订阅
{"method":"UNSUBSCRIBE","params":["btcusdt@depth"],"id":312}

// 查询已订阅
{"method":"LIST_SUBSCRIPTIONS","id":3}

心跳机制:

• 服务器每20秒发送PING
• 客户端必须在1分钟内回复PONG
• 未回复会导致连接断开

2.1.4 连接限制

• 每秒最多5条消息(包括PING/PONG/JSON消息)
• 单连接最多订阅1024个streams
• 每IP每5分钟最多300次连接请求

2.1.5 时间单位

默认: 毫秒 可选: 微秒 - 在URL中添加 timeUnit=MICROSECOND

/stream?streams=btcusdt@trade&timeUnit=MICROSECOND

2.2 WebSocket Streams (SBE编码) - 高性能专业用户

基本信息

端点:

• wss://stream-sbe.binance.com:9443
• wss://stream-sbe.binance.com:443

协议: WebSocket (基于HTTP升级) 编码: SBE (二进制格式) 连接有效期: 24小时 认证: 需要API Key (仅支持Ed25519密钥)

与JSON版本的区别

支持的数据流

• 实时成交 (@trade)
• 最优买卖价 (@bestBidAsk) - 支持自动剔除过时事件
• 增量深度 (@depth) - 50ms更新
• 部分深度快照 (@depth20) - 50ms更新

使用方式

1. 在请求头添加API Key:

X-MBX-APIKEY: <your_api_key>

2. 订阅请求用JSON发送（text frame）
3. 市场数据用SBE推送（binary frame）

适用场景

• 对性能有极致要求的专业应用
• 需要减少网络带宽的场景
• 机构级行情系统
• 高频交易的行情部分

选择建议:

• 普通用户 → WebSocket (JSON)
• 专业/机构 → WebSocket (SBE)

2.3 WebSocket User Data Stream (用户数据流)

2.3.1 功能

推送内容:

• 账户更新 (余额变动)
• 订单更新 (订单状态变化)
• 交易执行报告

2.3.2 使用流程

1. 通过REST API创建listenKey

POST /api/v3/userDataStream

2. 连接WebSocket

wss://stream.binance.com:9443/ws/<listenKey>

3. 定期续期listenKey (每60分钟)

PUT /api/v3/userDataStream

4. 关闭时删除listenKey

DELETE /api/v3/userDataStream

2.3.3 特点

• listenKey有效期60分钟
• 需要定期续期
• 实时推送账户事件
• 与市场数据流可在同一连接

2.4 适用场景

最适合:

• 实时行情监控
• 交易机器人
• 量化交易策略
• 行情展示应用
• 移动端应用
• Web应用

优势:

• 实现简单
• JSON格式易于解析
• 延迟低
• 支持广泛
• 调试方便

劣势:

• 不支持下单操作
• 延迟高于FIX API
• JSON解析开销

三、REST API接口

开发工具:

• requests (Python)
• axios (JavaScript)
• OkHttp (Java)

关键步骤:

1. 实现API Key认证
2. 实现HMAC SHA256签名
3. 处理timestamp同步
4. 实现频率限制控制
5. 处理错误和重试

3.1 基本信息

端点: https://api.binance.com

DNS策略:

• 采用CloudFront CDN全球分发
• CNAME: d3h36i1mno13q3.cloudfront.net
• 后端: 全球边缘节点

协议: HTTP/HTTPS 编码: JSON 模式: 请求-响应

3.2 主要功能

账户管理:

• 账户信息查询
• 资产余额查询
• 交易历史查询
• 存取款记录

订单操作:

• 下单 (POST /api/v3/order)
• 撤单 (DELETE /api/v3/order)
• 查询订单 (GET /api/v3/order)
• 查询所有订单 (GET /api/v3/allOrders)
• 当前挂单 (GET /api/v3/openOrders)

市场数据:

• 交易对信息 (GET /api/v3/exchangeInfo)
• 深度信息 (GET /api/v3/depth)
• 最近成交 (GET /api/v3/trades)
• K线数据 (GET /api/v3/klines)
• 24小时价格变动 (GET /api/v3/ticker/24hr)

用户数据流:

• 创建listenKey (POST /api/v3/userDataStream)
• 续期listenKey (PUT /api/v3/userDataStream)
• 删除listenKey (DELETE /api/v3/userDataStream)

3.3 认证机制

API Key认证:

• 在请求头添加 X-MBX-APIKEY
• 敏感操作需要签名

签名算法:

• HMAC SHA256
• 签名参数: timestamp + queryString
• 签名放在请求参数中

3.4 频率限制

权重系统:

• 每个接口有不同权重
• 按分钟和秒级别限制
• 超限会被封禁

限制类型:

• REQUEST_WEIGHT: 请求权重限制
• ORDERS: 订单数量限制
• RAW_REQUESTS: 原始请求数限制

3.5 适用场景

最适合:

• 普通交易应用
• 账户管理
• 历史数据查询
• 移动端应用
• Web应用
• 不需要极致性能的场景

优势:

• 实现简单
• 标准HTTP协议
• 易于调试
• 支持广泛
• 文档完善

劣势:

• 延迟较高
• 不适合高频交易
• 有频率限制

接口关系澄清

FIX API 与 SBE 的关系

关键理解: SBE 不是独立的接口，而是 FIX API 的一种编码格式。

FIX API (协议层)
  ├─ FIX 文本编码 (端口 9000) - 传统格式，人类可读
  └─ FIX SBE 编码 (端口 9001/9002) - 二进制格式，机器高效

FIX Market Data 与 WebSocket Streams 的区别

这是两个完全独立的市场数据接口：

选择建议:

• 机构级HFT行情 → FIX Market Data (SBE编码)
• 普通用户行情 → WebSocket Streams (JSON)

 参考资料

• FIX Protocol官方文档
• SBE编码规范
• Binance FIX API文档
• Binance WebSocket文档
• Binance REST API文档