CEX API 在生产中怎么用：零售、机构与量化 / HFT 的接入方式

本文介绍不同类型的客户在生产中如何组合使用 CEX 的各类 API：零售（C 端）、机构（B 端）、量化团队和 HFT / 做市商。以 Binance 为例，接口本身的细节见上一篇 CEX API接口架构详解。

总览

客户类型	客户端形态	下单	行情	账户 / 订单状态	部署位置	延迟要求
C 端零售	交易所 App / Web；少数自写脚本或第三方机器人	App 内下单；脚本用 REST	App 内；脚本用 WebSocket Streams	App 内；脚本轮询 REST	用户本地	秒级即可
B 端机构	OMS / EMS、经纪商系统、风控与清算系统	FIX 订单接入或 REST	FIX Market Data 或 WebSocket Streams	FIX Drop Copy + REST 对账	自建机房或云上，交易所同区域	毫秒级
量化团队	自研策略程序	WebSocket API	WebSocket Streams	WebSocket API 用户数据流	AWS 东京，与交易所同 AZ	毫秒到亚毫秒
HFT / 做市商	低延迟交易系统	FIX SBE（9002 端口）	FIX Market Data 或 SBE 行情流	FIX ExecutionReport + Drop Copy	同 AZ，挑选宿主机（EC2 hunting），争取 Colo	微秒级差异都在意

现货和合约的接口体系相似，但入口不同：现货是 api*.binance.com、ws-api.binance.com、stream.binance.com，USDⓈ-M 合约是 fapi.binance.com、ws-fapi.binance.com、fstream.binance.com。量化和 HFT 客户的成交主要在合约上，下面的做法对两者都适用，具体方法名和限额以各自文档为准。

C 端：零售用户

绝大多数零售用户在交易所 App / Web 里下单，并不直接调用公开 API。直接用 API 的，主要是两类：

• 个人开发者：用官方 Connector SDK 或 ccxt 写脚本，REST 下单、查询，WebSocket Streams 看行情。
• 第三方交易机器人 / 跟单工具：用户在交易所生成 API Key 交给第三方，由第三方代为下单。

这类场景最常见的问题：

• 签名时间偏差：请求里的 timestamp 和服务器时间相差超过 recvWindow（默认 5000 ms，最大 60000 ms）就会被拒绝。本机时钟要同步，不要靠调大 recvWindow 掩盖。
• 限频：超过请求权重返回 429，继续请求会被封 IP（418）。轮询要克制，能订阅推送就不要轮询。
• API Key 安全：交给第三方的 Key 只开交易权限、不开提现，并绑定 IP 白名单。

B 端：机构、经纪商与资管

机构客户已有一套订单管理系统（OMS / EMS），它们讲的是 FIX，所以 FIX 是机构接入的主路径：

flowchart LR
    OMS[OMS / EMS] -->|FIX 订单接入 fix-oe| EX[交易所]
    EX -->|ExecutionReport| OMS
    EX -->|FIX Drop Copy fix-dc| RISK[风控 / 清算 / 合规]
    EX -->|FIX Market Data 或 Streams| MDS[行情服务]
    MDS --> OMS
    RECON[对账任务] -->|REST 查询订单与成交| EX

• 订单接入和 Drop Copy 分开：交易系统走订单接入会话（fix-oe）；风控、清算、合规系统接 Drop Copy（fix-dc），只读地接收账户所有订单的 ExecutionReport，不会影响下单链路。
• API Key 按用途拆分：下单用 FIX_API 权限的 Key，Drop Copy 和行情用 FIX_API_READ_ONLY。一个 Key 泄露或被限频，不会波及其他系统。
• 多账户：经纪商和资管通常为每个终端客户或每个策略开独立的子账户，用账户隔离持仓、限额和风险。
• 对账：Binance 的 FIX 目前不支持 Resend Request，断线期间的 ExecutionReport 不会补发。每次重连后、以及每天收盘后，都要用 REST 查询订单和成交，与 OMS 的记录核对。

量化团队：中低频策略

量化团队一般不上 FIX，而是用 WebSocket API 加 WebSocket Streams，在少数几条长连接上完成下单、查询、行情和账户推送：

flowchart LR
    S[策略程序] -->|order.place / order.cancel| WSAPI[WebSocket API]
    WSAPI -->|用户数据流 订单与余额更新| S
    MD[WebSocket Streams 深度 / 成交 / bookTicker] --> BOOK[本地订单簿]
    SNAP[REST depth 快照] --> BOOK
    BOOK --> S
    HIST[data.binance.vision 历史数据] --> BT[回测]
    BT --> S

• 一条 WebSocket API 连接做三件事：用 Ed25519 Key 做 session.logon 后，下单不必逐个签名；在同一连接上 userDataStream.subscribe，订单和余额变化直接推回来。
• 本地订单簿要和快照对齐：订阅增量深度并先缓存事件，再用 REST 拉深度快照；丢掉 u <= lastUpdateId 的事件，从覆盖 lastUpdateId 的那条开始应用；一旦发现 U 大于本地更新 ID + 1，说明丢了事件，重建订单簿。
• 连接生命周期：WebSocket 连接最长 24 小时，收到 serverShutdown 事件要尽快换新连接。重连后先用 REST 查一次挂单和余额，再恢复交易。
• 限频预算：请求权重按 IP 累计，同一 IP 上的所有连接共享；订单数量限制按账户统计。多个策略进程共用出口 IP 时，要统一分配预算。
• 回测数据：历史 K 线、成交等按日 / 按月打包在 data.binance.vision，不必用 REST 慢慢拉。
• 部署位置：Binance 的直连入口（api-gcp 除外）都在 AWS 东京（ap-northeast-1）。把策略部署到同一个 AZ，网络往返能从几十毫秒降到亚毫秒；REST 也要用直连的 api1–api4，而不是走 CloudFront 的 api.binance.com。

HFT / 做市商

HFT 和做市商追求的是 tick-to-trade：从收到行情到订单被交易所确认的总时间。接口选择、部署位置和主机调优都围绕这个指标：

flowchart LR
    MDA[行情连接 A] --> ARB[去重 取最先到达]
    MDB[行情连接 B] --> ARB
    ARB --> BOOK[本地订单簿]
    BOOK --> STRAT[策略]
    STRAT -->|FIX SBE 9002| OE[订单接入 fix-oe]
    OE -->|ExecutionReport| STRAT
    OE -.-> DC[Drop Copy 风控]

• 接口：下单用 FIX 订单接入的纯 SBE 端口 9002；行情用 FIX Market Data（SBE）或 SBE 行情流。行情、策略、下单放在同一台机器上，省掉机器之间的一跳。
• 多路冗余：行情同时订阅多个入口 IP，按序列号去重、取最先到达的一份；下单保持多条到不同网关的连接，按实时延迟选择。
• 直连固定 IP：FIX 等入口的 DNS 只有几个 IP、TTL 60 秒。生产中按 IP 直连（TLS SNI 照填域名），并监控解析结果，交易所换 IP 时自动切换。
• 交易所提供的低延迟渠道：做市商计划、VIP 通常有更高的限额和专用入口，需要单独申请；有共享集群置放组（CPG）或 PrivateLink 的交易所，接入后自然在最近的位置。
• 时间戳：要比较多台机器谁先收到行情，需要微秒级对时，即放进 precision-time placement group，使用 PHC（PTP 硬件时钟）。基础的 Amazon Time Sync（169.254.169.123）误差在几十到几百微秒，只够用来对齐发送时刻。

网络延迟与 EC2 hunting

同一个 AZ 内，不同宿主机到交易所入口的距离也不一样：同机架、同一组 spine、不同机房之间，延迟能差几十微秒。没有 Colo 资格时，做市商的做法是开一批实例实测延迟，留下最近的那台，这就是 EC2 hunting。

可以参考这个开源工具 ec2-hunting-with-partition-placement-group：

• 用 Terraform 在交易所所在 AZ 的 partition placement group 里开一批实例，让它们分散到不同机架；
• 所有实例按同一个时间网格，对每个入口 IP 测 TCP 握手 RTT，按时间点与全体中位数成对比较，排名附带置信区间；
• 按下单、行情两个角色分别排名并加权，给出建议保留的实例；保留赢家后还能再开新一批一起比。

几个实测数据（2026-03-12，东京）：AZ 归属和跨 AZ 数据来自每个 AZ 一台 c7i.large 探测机，ws-fapi 往返和宿主机差距来自 apne1-az4 的 9 台 c8i.2xlarge。

指标	数值
实测的 Binance 现货与合约直连入口所在 AZ	apne1-az4
同 AZ TCP 握手 RTT	约 0.2 ms（跨 AZ 1.3–1.8 ms）
合约 ws-fapi 请求往返	约 0.9 ms，其中约 0.7 ms 是交易所处理时间
不同宿主机在 p50 上的差距	10–30 µs

两个结论：

• 先选对 AZ，收益最大：跨 AZ 多出来 1 ms 以上，远大于同 AZ 内挑宿主机的几十微秒。
• 挑宿主机要用纯网络指标：请求往返里交易所的处理时间和抖动比宿主机之间的差距还大，所以排名要用 TCP 握手 RTT，请求往返只用来确认。

另外，抽样数量决定能不能抽到好位置。如果每台实例的放置是独立的，N 台里至少有一台落在 AZ 前 10% 的概率是 1 − 0.9^N：7 台只有 52%，要 95% 的把握需要约 29 台。同一个分区内的实例共用机架，只算一次抽样。

共性的生产实践

方面	做法
密钥	用 Ed25519；按用途拆分 Key（下单 / 只读 / 行情）；只开必要权限，不开提现；绑定 IP 白名单
时间	主机用 Amazon Time Sync 或可靠的 NTP；recvWindow 保持 5000 ms 以内
限频	按 IP 和账户分别做预算；收到 429 立即退避，避免升级成 418 封 IP
连接	处理 24 小时断连和 serverShutdown；重连后先对账再交易
行情	增量深度必须和快照对齐，检测到序列号断档就重建
监控	按分位数（p50 / p99 / p99.9）监控下单往返和行情延迟，盯延迟的变化而不只是绝对值

小结

• C 端用 App，少数开发者用 REST + WebSocket Streams，重点是时间同步、限频和 Key 安全。
• B 端以 FIX 为主：订单接入、Drop Copy、行情三类会话分开，Key 按用途拆分，用 REST 对账收口。
• 量化团队用 WebSocket API + WebSocket Streams，部署在交易所同 AZ，管好本地订单簿、连接生命周期和限频预算。
• HFT / 做市商用 FIX SBE，多路冗余、按 IP 直连，同 AZ 内再用 EC2 hunting 挑宿主机，并争取交易所的低延迟渠道。