1. 交易机器人架构设计的核心思路1.1 为什么选择Websocket与REST API双轨协同做交易机器人最怕的一件事就是“慢半拍”。行情来了你还在轮询接口等拿到价格的时候盘口早就变了。我最早写机器人时也踩过这个坑用纯REST API轮询行情结果在波动大的时候延迟能到两三秒挂单价格和实际成交价差出一大截利润全被滑点吃掉了。后来我把架构改成了Websocket负责实时数据流REST API负责交易执行的双轨模式整个机器人的响应速度直接上了一个台阶。这个思路其实不复杂Websocket就像你一直开着的水管数据源源不断推过来不需要你反复去问“有没有新行情”REST API则像你去柜台办业务每次操作都是独立的请求-响应适合下单、撤单、查持仓这类需要明确结果的动作。具体来说双轨协同的分工是这样的Websocket通道订阅行情深度、K线数据、成交记录、账户余额变动、订单状态变化。这些数据的特点是高频、实时、需要持续监听。REST API通道负责下单、撤单、查询历史订单、查询持仓、划转资金。这些操作的特点是低频、需要确认结果、有明确的成功或失败返回。为什么不全用Websocket因为交易指令的可靠性要求极高Websocket是长连接一旦网络抖动导致消息丢失你根本不知道订单到底有没有发出去。而REST API每次请求都有明确的HTTP状态码和响应体能清楚知道操作结果。反过来为什么不全用REST因为轮询行情效率太低不仅延迟高还容易触发交易所的频率限制。注意Websocket连接不是永远稳定的必须要有断线重连机制。我一般会设置心跳检测超过30秒没收到pong就主动重连同时用REST API补拉断线期间缺失的数据。1.2 整体架构分层与模块划分一个能跑得稳的交易机器人不能把所有逻辑塞在一个文件里。我习惯把它分成四层每层各司其职第一层连接层。负责维护Websocket长连接和REST API的HTTP客户端。Websocket这边要处理订阅、心跳、重连、消息分发REST这边要处理签名、请求封装、错误重试、频率控制。第二层数据层。把Websocket推送的原始数据解析成统一格式存入内存中的数据结构。比如行情深度用字典维护买卖盘K线用列表维护最近N根账户余额用对象维护各币种可用和冻结数量。第三层策略层。这是机器人的大脑根据数据层的实时数据计算信号。比如均线交叉、网格挂单、止盈止损触发条件。策略层不直接调用API而是把交易意图交给执行层。第四层执行层。接收策略层的交易指令通过REST API发送到交易所同时监听Websocket的订单状态推送确认成交后回调通知策略层更新状态。这种分层的好处是策略逻辑和底层通信解耦。我想换一个交易所只需要改连接层和数据层的适配代码策略层几乎不用动。我想调整策略参数也不会影响连接稳定性。1.3 技术选型与依赖库对比Python是做交易机器人最顺手的语言生态成熟写起来快。我试过几种组合最终稳定下来的方案是功能模块推荐库备选方案选择理由Websocket客户端websocketswebsocket-client原生asyncio支持适合高并发HTTP请求aiohttprequests异步非阻塞配合asyncio数据解析orjsonjson解析速度快3-5倍异步框架asynciotrioPython原生资料多数据存储内存字典SQLiteRedis轻量无需额外服务如果你之前用过python django websocket实现后台有数据前端推送那套方案会发现Django Channels更适合Web应用的前后端推送而交易机器人是纯后端服务用原生websockets库更轻量、更可控。实操心得不要用requests库做REST请求它是同步阻塞的会卡住整个事件循环。我一开始没注意Websocket消息处理到一半去调REST下单结果行情推送全堵在缓冲区里等下单完成才继续处理延迟直接爆炸。换成aiohttp之后才解决。2. Websocket实时数据流的关键细节2.1 连接建立与订阅管理的完整流程OKX的Websocket公共频道不需要认证直接连就行。但私有频道需要先用REST API的密钥做登录认证。整个流程我拆成几步第一步建立Websocket连接。公共频道地址是wss://ws.okx.com:8443/ws/v5/public私有频道是wss://ws.okx.com:8443/ws/v5/private。我一般开两个连接公共和私有分开避免消息混杂。第二步发送订阅请求。订阅格式是一个JSON对象包含op字段为subscribeargs数组里放要订阅的频道和交易对。比如订阅BTC-USDT的深度数据subscribe_msg { op: subscribe, args: [ {channel: books5, instId: BTC-USDT}, {channel: tickers, instId: BTC-USDT}, {channel: candle1m, instId: BTC-USDT} ] } await ws.send(json.dumps(subscribe_msg))第三步处理订阅确认。OKX会返回一个event为subscribe的消息里面包含订阅成功的频道信息。如果订阅失败会返回error事件需要根据错误码排查。第四步持续接收数据。订阅成功后数据会以推送形式源源不断发来。每条消息都有arg字段标识属于哪个频道data字段是实际数据。注意OKX的Websocket有订阅数量限制单个连接最多订阅64个频道。如果你要监控很多交易对需要开多个连接或者用instType批量订阅。2.2 心跳机制与断线重连的工程实现Websocket连接最怕的就是“假死”——TCP连接还在但实际已经收不到数据了。OKX要求客户端每30秒发送一次字符串ping服务器会回复pong。如果超过一定时间没收到pong就必须主动断开重连。我的心跳实现是这样的async def heartbeat(ws): while True: try: await ws.send(ping) await asyncio.sleep(25) except Exception: break async def listen(ws): while True: try: msg await asyncio.wait_for(ws.recv(), timeout35) if msg pong: continue # 处理业务数据 await handle_message(msg) except asyncio.TimeoutError: # 超时未收到任何消息触发重连 raise ConnectionError(heartbeat timeout)重连策略我采用指数退避第一次断线等1秒重连第二次等2秒第三次等4秒最多等30秒。重连成功后需要重新发送所有订阅请求并且用REST API补拉断线期间缺失的K线数据。实操心得重连后不要立刻发订阅先等连接稳定1-2秒。我有一次重连后马上发订阅结果连接还没完全就绪订阅请求丢了机器人傻等了半天没数据。后来加了个短暂延迟再订阅就没再出过问题。2.3 行情数据解析与本地订单簿维护OKX的深度频道有几种books5是5档books是400档bbo-tbt是逐笔最优报价。做网格策略用books5就够了做高频套利可能需要books。维护本地订单簿是个技术活。books5每次推送的是全量5档直接替换本地数据就行。但books频道首次推送是全量后续推送是增量更新需要自己合并。增量更新的逻辑是每条消息里有bids和asks数组每个元素是[价格, 数量, 0]。数量为0表示删除该价位否则是更新或新增。价格需要按买卖方向分别排序买盘从高到低卖盘从低到高。def update_orderbook(local_book, new_data): for side in [bids, asks]: for price, size, _ in new_data[side]: price float(price) size float(size) if size 0: local_book[side].pop(price, None) else: local_book[side][price] size # 重新排序 local_book[bids] dict(sorted(local_book[bids].items(), reverseTrue)) local_book[asks] dict(sorted(local_book[asks].items()))注意浮点数比较有精度问题价格最好用Decimal或者转成整数处理。我有一次用float比较价格结果0.10.2不等于0.3订单簿里出现了重复价位差点下错单。3. REST API交易执行的实操要点3.1 认证签名与请求封装的正确姿势OKX的REST API认证需要三个头信息OK-ACCESS-KEY、OK-ACCESS-SIGN、OK-ACCESS-TIMESTAMP还有一个OK-ACCESS-PASSPHRASE。签名算法是HMAC SHA256把时间戳、方法、路径、请求体拼接后加密。签名最容易出错的地方是时间戳格式。OKX要求ISO 8601格式比如2024-01-15T10:30:00.000Z精确到毫秒。我一开始用了Unix时间戳一直报签名错误排查了半天才发现是格式问题。import hmac import base64 import hashlib from datetime import datetime, timezone def sign_request(api_secret, method, path, body): timestamp datetime.now(timezone.utc).strftime(%Y-%m-%dT%H:%M:%S.%f)[:-3] Z message timestamp method.upper() path body signature base64.b64encode( hmac.new(api_secret.encode(), message.encode(), hashlib.sha256).digest() ).decode() return timestamp, signature请求封装我建议统一成一个函数传入方法、路径、参数自动处理签名、发送、解析响应、错误重试。这样策略层调用起来就很简单不用关心底层细节。实操心得OKX的REST API有频率限制不同接口限制不同。下单接口一般是每秒10次查询接口是每秒20次。我建议在请求封装里加一个令牌桶限流器避免触发限流被封IP。被限流后OKX会返回429状态码这时候要暂停一段时间再重试。3.2 下单、撤单与订单状态跟踪下单接口是POST /api/v5/trade/order关键参数包括instId交易对、tdMode交易模式cash现货、cross全仓、isolated逐仓、side买卖方向、ordType订单类型market市价、limit限价、sz数量、px价格。市价单和限价单的区别很重要。市价单立即成交但滑点不可控限价单可以控制价格但不保证成交。我做网格策略用限价单做止损用市价单。async def place_order(session, inst_id, side, ord_type, size, priceNone): body { instId: inst_id, tdMode: cash, side: side, ordType: ord_type, sz: str(size) } if price: body[px] str(price) # 签名并发送请求 result await signed_request(session, POST, /api/v5/trade/order, body) return result下单成功后OKX会返回一个ordId。但这个ordId只是表示订单已受理不代表已成交。真正的成交状态要通过Websocket的orders频道推送来跟踪或者用REST API轮询查询订单详情。我推荐用Websocket跟踪订单状态因为实时性更好。订阅orders频道后订单状态变化会主动推送包括live挂单中、partially_filled部分成交、filled完全成交、canceled已撤销。注意下单接口返回成功不代表订单一定成交。我有一次市价单返回了ordId但实际因为流动性不足只成交了一半。所以一定要监听订单状态推送确认最终成交量后再更新策略状态。3.3 频率限制与错误重试的工程实践OKX的频率限制分两种一种是基于IP的一种是基于用户ID的。公共接口按IP限私有接口按用户ID限。每个接口的限速在文档里都有说明比如下单是10次/2秒查询是20次/2秒。我的限流方案是用asyncio.Semaphore加滑动窗口。简单说就是维护一个时间戳队列每次请求前检查最近N秒内的请求数是否超限超了就等待。class RateLimiter: def __init__(self, max_calls, period): self.max_calls max_calls self.period period self.calls [] async def acquire(self): now time.time() self.calls [t for t in self.calls if now - t self.period] if len(self.calls) self.max_calls: wait_time self.period - (now - self.calls[0]) await asyncio.sleep(wait_time) self.calls.append(time.time())错误重试要区分错误类型。网络超时、连接错误可以重试参数错误、余额不足、签名错误重试也没用直接抛异常。我一般设置最多重试3次每次间隔1秒、2秒、4秒。实操心得不要对所有错误都无脑重试。我有一次下单返回“余额不足”代码却一直重试结果发了十几次请求虽然都没成功但触发了频率限制账号被临时限制交易。后来我加了错误码判断只有50011请求超频和50013系统繁忙才重试其他错误直接上报。4. 双轨协同的实战场景与问题排查4.1 行情触发交易信号的完整链路双轨协同最典型的场景就是Websocket推送行情策略层计算信号REST API执行交易Websocket再推送订单状态确认成交。我拿一个简单的网格策略举例。假设BTC-USDT当前价格是50000我设置每下跌1%挂一个买单每上涨1%挂一个卖单。Websocket的tickers频道推送最新成交价策略层收到后判断如果价格跌破49500触发买入信号。执行层通过REST API挂一个49500的限价买单。下单成功后Websocket的orders频道会推送订单状态从live变成filled时策略层记录这笔成交并在50490挂一个卖单。整个链路的关键是状态同步。策略层要知道哪些价位已经挂了单哪些已经成交哪些已经撤销。我一般用一个字典维护所有活跃订单键是ordId值是订单详情。Websocket推送订单状态时更新这个字典策略层根据字典内容决定下一步动作。注意Websocket推送的订单状态可能有延迟不要完全依赖它做实时决策。我一般会在关键操作前用REST API查一次最新状态确保数据准确。4.2 常见异常场景与排查速查表做交易机器人异常处理是重中之重。我把踩过的坑整理成一张速查表异常现象可能原因排查方法解决方案Websocket频繁断线网络不稳定或心跳超时查看断线间隔和错误日志增加心跳频率检查网络质量订阅成功但收不到数据频道参数错误或交易对不存在检查订阅返回的event消息核对频道名和instId格式REST请求返回401签名错误或时间戳偏差检查系统时间是否同步用NTP同步时间重新生成签名下单返回51008余额不足查询账户余额减少下单数量或充值订单状态不更新Websocket私有频道未登录检查登录认证是否成功重新发送登录请求策略重复下单状态同步延迟检查活跃订单字典加锁防止并发重复操作这张表我贴在显示器旁边出问题先对照排查能省不少时间。实操心得日志一定要打全。我一开始只打错误日志结果出问题时根本不知道上下文。后来改成每笔交易都记录时间、行情价格、信号类型、下单参数、订单ID、成交结果。这样复盘时一目了然也能发现策略逻辑的漏洞。4.3 性能优化与稳定性加固建议机器人跑久了性能问题会慢慢暴露。我总结几个优化点第一减少不必要的REST调用。能用Websocket推送的数据就不要轮询。比如账户余额订阅account频道后余额变动会主动推送不需要定时查询。第二用连接池复用HTTP连接。aiohttp的ClientSession默认会复用连接但要注意设置合理的超时和连接数上限。我一般设置connector_limit20timeout10秒。第三数据解析用orjson。Python自带的json库解析速度一般orjson快3-5倍。对于高频行情数据这个差距很明显。第四策略计算和IO操作分离。策略计算是CPU密集型IO操作是等待密集型。我一般把策略计算放在单独的线程池里避免阻塞事件循环。第五加监控和告警。机器人跑起来后要监控几个关键指标Websocket连接状态、REST请求成功率、订单成交率、账户余额变化。一旦异常通过邮件或消息通知我。我有一次半夜Websocket断了没发现第二天起来发现错过了好几波行情从那以后就加了告警。注意不要在生产环境直接跑新策略。我习惯先用模拟盘跑一周确认逻辑没问题再上实盘。OKX有模拟盘环境API地址和实盘不同但接口格式一样很适合做策略验证。4.4 从单机器人到多策略并行的扩展思路单个机器人跑稳之后自然会想跑多个策略。比如一个网格策略、一个趋势策略、一个套利策略同时跑。这时候架构要调整。我的做法是连接层共享策略层隔离。Websocket连接和REST客户端做成全局单例所有策略共用。每个策略有自己的数据视图和订单管理互不干扰。具体实现上用一个StrategyManager管理所有策略实例每个策略注册自己关心的频道和交易对。Websocket收到数据后分发给对应的策略。策略产生交易信号后通过统一的执行层下单执行层负责频率控制和错误处理。这样扩展的好处是新增策略只需要写策略逻辑不用关心连接和通信。我目前同时跑三个策略共用一套连接层资源占用很低稳定性也很好。实操心得多策略并行时要注意订单冲突。比如两个策略同时想买BTC可能会重复下单。我的解决方案是给每个策略分配独立的子账户或者在执行层加一个全局锁同一交易对同一时间只允许一个策略操作。