标签 外汇行情接口 下的文章

第一次接外汇行情接口的时候，大多数人都会觉得这件事不难。
连上 WebSocket，订阅一个 EURUSD，看着 tick 数据持续推送，基本都会下意识地认为：行情模块已经搞定了。
但只要系统开始长时间运行，或者订阅多个货币对，问题很快就会暴露出来。
连接稳定性、推送结构、字段一致性，这些一开始看起来不起眼的细节，往往会在后期变成系统复杂度的来源。

行情模块的特点：不复杂，但很难返工

和策略、风控相比，行情模块本身并不算复杂。
但它有一个明显特点：
一旦被多个模块依赖，就很难再动。
策略可以反复调整，参数可以不断优化，但行情数据如果在多个地方被使用，只要结构有变化，就会影响整条链路。
所以后来我在系统设计里，会刻意把行情模块当成一层基础设施来看，而不是一个普通功能。
标准也很简单：

  • 能跑只是最低要求

  • 能长期稳定跑，而且结构不变，才算可用

    为什么外汇行情更适合用 WebSocket

    如果只是偶尔获取一次行情，用 REST 接口也不是不行。
    但外汇市场的现实情况是：
    数据更新频率非常高。
    用 REST 拉行情，本质是在做高频轮询，系统不断地在问：
    现在有没有新数据？
    WebSocket 的模式正好相反：
    有数据你再推送，没有就保持连接。
    在系统运行时间拉长之后，这种差异会直接体现在：

  • 延迟稳定性
  • 连接抖动

  • 资源占用情况
    尤其是多品种订阅时，这个差别会更加明显。

    接外汇行情接口，关键不是接口而是边界

    接口文档写得再清楚，也解决不了一个核心问题：
    行情模块的职责边界在哪里？
    在我的实践里，行情接入层只做三件事：

  • 建立连接
  • 订阅行情

  • 把数据原样交给下游
    到这里就应该结束。
    如果在行情层里开始做策略判断、交易时间判断，或者业务状态判断，后期维护成本会明显上升，而且很难拆干净。

    一个相对克制的外汇行情接入示例

    下面这段代码是我常用的一种结构，逻辑非常简单，也刻意保持了“不过界”。

import websocket
import json

WS_URL = "wss://stream.alltick.co/ws"

def on_open(ws):
    ws.send(json.dumps({
        "op": "auth",
        "args": {
            "token": "YOUR_API_KEY"
        }
    }))

    ws.send(json.dumps({
        "op": "subscribe",
        "args": [
            {
                "channel": "tick",
                "symbol": "EURUSD"
            }
        ]
    }))

def on_message(ws, message):
    data = json.loads(message)
    if data.get("channel") == "tick":
        forward_tick(data["data"])

def forward_tick(tick):
    # 到这里为止
    # 行情模块已经完成任务
    pass

ws = websocket.WebSocketApp(
    WS_URL,
    on_open=on_open,
    on_message=on_message
)

ws.run_forever()

forward_tick 之后的处理逻辑，并不属于行情模块的职责范围。
行情模块只负责一件事：
稳定地把外汇行情数据交出去。

多品种订阅时，少做判断反而更稳

当开始同时订阅多个货币对时，很容易在行情层写大量分支逻辑：

  • 不同 symbol 不同处理方式
  • 不同品种不同判断条件
    但实践下来会发现，这些判断大多不该出现在行情层。
    我更倾向于一个简单原则：
  • 行情层只处理 symbol 和数据

  • 含义和业务逻辑交给下游
    这样新增或删除品种时，行情模块几乎不用改动，系统结构也更清晰。

    外汇行情 API 的差异，往往体现在结构稳定性上

    很多外汇行情 API 在功能层面看起来差别不大。
    但系统真正跑起来之后，差异通常体现在这些地方：

  • 数据字段是否长期稳定
  • 不同市场是否统一推送结构

  • 多品种订阅时是否保持一致行为
    有些行情服务在设计时，就把外汇、加密资产、股票等行情统一在同一套推送模型中，比如 AllTick API 这一类实时行情接口，在接入外汇行情时整体适配成本会更低，不太容易被细节反复打断。

    行情模块越“安静”，系统反而越可靠

    写到最后，其实只有一个结论。
    一个好的行情模块，不需要有太强的存在感。
    它不承担业务决策，也不表达逻辑判断，只是持续、稳定地输出数据。
    当行情接口选得合适，边界又控制得住，很多系统层面的问题，往往会自然消失。
    如果你正在搭建一个长期运行的外汇交易系统，行情模块这一步，值得多花一点时间想清楚。