交易系统接口选型：REST 与 WebSocket 的延迟与架构权衡

作者： /

在构建高频交易或任何对实时性有苛刻要求的系统时，技术选型往往直指系统瓶颈。API 接口作为系统与外部世界交互的咽喉，其设计直接决定了交易指令和市场数据的时效性。本文将面向已有扎实工程经验的技术负责人和高级工程师，深入剖析 REST API 与 WebSocket 这两种主流技术在交易场景下的本质差异。我们不满足于“WebSocket 是长连接，更快”这类浅显的结论，而是要从操作系统内核、TCP/IP 协议栈、服务端架构、容错设计等多个维度，进行一场硬核的延迟与架构权衡分析。

现象与问题背景

在数字货币交易所或股票交易系统中，一个最核心的场景是市场深度（Market Depth）的展示和订单的提交。市场深度，即买卖盘口，可能每秒变动数百次。交易员，无论是人类还是量化策略程序，都需要以最低的延迟获取这些变动，并以最快的速度提交自己的订单。在这里，延迟的每一毫秒都可能意味着金钱的损失或机会的错失。

一个典型的失败案例是，一个交易平台初期为了快速上线，所有接口均采用业界通行的 RESTful API。用户通过轮询（Polling）的方式，每秒调用一次 `GET /api/v1/depth?symbol=BTC_USDT` 来刷新盘口数据。很快，问题浮出水面：

  • 延迟巨大且不稳定： 用户看到的行情至少是几百毫秒前的，有时网络抖动甚至达到秒级。这对于高频交易者是不可接受的。
  • 服务端压力剧增： 假设有 10 万在线用户关注同一个交易对，那么服务端每秒就要处理 10 万次几乎相同的请求，造成巨大的资源浪费。
  • 无效轮询： 在市场平淡的时期，大部分轮询请求返回的数据与上一次完全相同，做了大量的无用功。

这些现象迫使我们思考：对于这种高频、实时的场景，传统的请求-响应模型是否已经达到了它的天花板？我们需要的究竟是什么？答案是：一个低延迟、高效率、由服务端主动推送数据的通信范式。这正是 WebSocket 设计的初衷。

关键原理拆解：从内核到协议栈

要理解 REST 和 WebSocket 在延迟上的根本差异，我们必须像一位严谨的计算机科学家，潜入到操作系统和网络协议的底层，分析一次网络通信的完整开销。这并非钻牛角尖，而是架构师做出正确决策的基础。

HTTP 请求的生命周期与成本

一个看似简单的 REST API 调用，例如 `GET /depth`，在底层经历了漫长而昂贵的旅程：

  1. DNS 解析： （若无缓存）将域名解析为 IP 地址，通常耗时几十到上百毫秒。
  2. TCP 三次握手： 客户端与服务端建立 TCP 连接。这个过程需要 1.5 个往返时延（Round-Trip Time, RTT）。在一个 100ms RTT 的网络环境中，仅此一项就消耗 150ms。
  3. TLS/SSL 握手： 对于 HTTPS，在 TCP 连接建立后，还需要进行 TLS 握手以建立安全信道。这通常需要 1-2 个 RTT，即额外的 100-200ms。
  4. HTTP 请求发送与响应： 客户端构建 HTTP 请求报文，通过 `write()` 系统调用交由内核发送。服务端接收、处理后，再将响应报文通过 `write()` 发回。这个过程至少消耗 1 个 RTT。
  5. TCP 四次挥手： 请求结束后，若连接关闭，则进行四次挥手，又会产生网络交互。

聪明的工程师会说：“我们有 HTTP Keep-Alive！” 的确，HTTP/1.1 的 Keep-Alive 机制允许在一次 TCP 连接上发送多次 HTTP 请求，从而摊销了 TCP 和 TLS 握手的成本。然而，Keep-Alive 并未改变 HTTP 请求-响应的本质。每一次获取数据，无论数据多小，都必须由客户端发起一次完整的 “请求 -> 等待 -> 响应” 流程。这个流程本身就包含内核态与用户态的切换、数据包的封装与解封装、以及至少半个 RTT 的网络延迟。在高频场景下，这种固有的请求开销累加起来，依然是不可忽视的延迟来源。

WebSocket 的协议升迁与全双工信道

WebSocket 则从根本上改变了游戏规则。它始于一个标准的 HTTP 请求，但这个请求是特殊的：


GET /stream HTTP/1.1
Host: api.exchange.com
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Key: dGhlIHNhbXBsZSBub25jZQ==
Sec-WebSocket-Version: 13

服务端如果支持，会返回一个 `101 Switching Protocols` 响应。从这一刻起，这条底层的 TCP 连接就不再遵循 HTTP 协议了。它“升迁”为 WebSocket 协议，变成了一个持久化的、全双工的字节流通道。

这意味着什么？

  • 一次性握手： TCP 和 TLS 的握手成本只在连接建立时支付一次。之后所有的通信都复用这个连接，直到某一方断开。
  • 数据帧（Frame）： 数据不再被包装成臃肿的 HTTP 报文（带有 Headers, Cookies 等），而是被切分成轻量级的数据帧。这极大地降低了协议开销，尤其适合发送大量小消息的场景。
  • 服务端主动推送： 这是最关键的区别。一旦连接建立，服务端可以在任何时候，无需客户端请求，直接将数据（如最新的盘口变化）推送给客户端。客户端的应用层表现为一个事件监听器，被动接收并处理数据。延迟从“客户端轮询间隔 + RTT” 降低到了 “事件产生到服务端推送的内部处理时间 + 0.5 RTT”。

从操作系统的视角看，对于一个 WebSocket 服务端，每个客户端连接对应一个长期存在的文件描述符（File Descriptor）。服务端应用可以通过 `epoll` 或 `kqueue` 这样的 I/O 多路复用机制，高效地管理成千上万个并发连接。当有新数据需要推送时，它直接向对应的文件描述符 `write()` 数据即可，路径极短，效率极高。

系统架构总览：混合模型的实践

理论的探讨最终要落地于架构。纯粹的 REST 或纯粹的 WebSocket 架构都存在缺陷。在真实的交易系统中，最常见也最实用的是一种混合架构。我们可以用文字来描绘这样一幅架构图：

用户（交易员或 API 用户）的请求首先到达负载均衡器（如 Nginx 或 F5）。负载均衡器根据请求的路径进行分发：

  • REST API 流量： 请求路径为 `/api/v*` 的流量，被路由到一个无状态的 REST API 网关集群。这个集群处理所有非实时的、客户端主动发起的请求，例如：
    • 用户注册、登录、身份验证
    • 资金的充值、提现
    • 查询历史订单、历史成交记录
    • 提交、取消订单（在延迟要求不极致的场景下）

    这些服务可以方便地进行水平扩展，因为它们是无状态的。

  • WebSocket 流量： 请求路径为 `/ws` 的流量，被路由到一个有状态的 WebSocket 网关集群。这个集群专门负责处理实时数据流和低延迟的交易指令，例如：
    • 订阅和推送市场行情（Ticker）
    • 订阅和推送市场深度（Depth）
    • 订阅和推送实时成交（Trades）
    • （高级）通过 WebSocket 提交和取消订单，以及接收订单状态更新的实时推送。

无论是 REST 网关还是 WebSocket 网关，它们的后端都连接着同样的核心业务服务，如用户中心、钱包服务、清结算系统，以及最重要的撮合引擎。它们之间通常通过高性能的消息队列（如 Kafka 或自研的消息总线）进行解耦和通信。

这种混合架构，既利用了 REST 的简单、无状态、易于扩展的优点来处理事务性、低频率的操作，又发挥了 WebSocket 在实时、高频场景下的低延迟、高效率优势。

核心模块设计与实现：代码中的魔鬼

让我们切换到极客工程师的视角，看看代码层面的具体实现，感受其中的差异。

REST 轮询获取深度：笨重但直接

这是一个典型的 Go 语言客户端轮询代码。注意，这已经是经过优化的版本，使用了 `http.Client` 来复用底层 TCP 连接（HTTP Keep-Alive）。


package main

import (
	"fmt"
	"io/ioutil"
	"net/http"
	"time"
)

func main() {
	// 使用带连接池的 Client 来实现 Keep-Alive
	client := &http.Client{
		Timeout: time.Second * 5,
	}
	ticker := time.NewTicker(500 * time.Millisecond) // 每 500ms 轮询一次
	defer ticker.Stop()

	for range ticker.C {
		// 每次循环都是一次完整的 HTTP Request-Response
		resp, err := client.Get("https://api.exchange.com/api/v1/depth?symbol=BTC_USDT")
		if err != nil {
			fmt.Println("Request failed:", err)
			continue
		}

		body, err := ioutil.ReadAll(resp.Body)
		if err != nil {
			// 处理错误
		}
		resp.Body.Close() // 必须关闭 body，以便连接可以被复用

		// 在这里处理 body (JSON 反序列化等)
		fmt.Printf("Got depth data, size: %d bytes\n", len(body))
	}
}

代码解读与坑点： 这段代码的“笨重”在于 `for` 循环中的每一次迭代。即使底层 TCP 连接被复用，CPU 和网络依然要完整地走一遍“构建请求、发送、等待、接收、解析”的流程。500ms 的轮询间隔是一个痛苦的权衡：太长，行情延迟大；太短，对客户端和服务器都是巨大的负担。此外，开发者必须正确处理 `resp.Body.Close()`，否则会导致连接泄露，耗尽系统资源。

WebSocket 订阅与事件处理：轻盈且高效

现在我们看一个使用 Go Gorilla WebSocket 库的客户端实现。


package main

import (
	"fmt"
	"log"
	"github.com/gorilla/websocket"
)

func main() {
	// 1. 建立连接 (TCP/TLS 握手 + HTTP Upgrade)
	// 这个过程只执行一次！
	conn, _, err := websocket.DefaultDialer.Dial("wss://stream.exchange.com/ws", nil)
	if err != nil {
		log.Fatal("Dial error:", err)
	}
	defer conn.Close()

	// 2. 发送订阅消息 (一次性)
	subscribeMsg := `{"method": "SUBSCRIBE", "params": ["btcusdt@depth"], "id": 1}`
	err = conn.WriteMessage(websocket.TextMessage, []byte(subscribeMsg))
	if err != nil {
		log.Println("Subscribe failed:", err)
		return
	}

	// 3. 进入无限循环，只做一件事：等待并处理服务端推送的消息
	// 这是一个阻塞操作，由网络事件驱动，没有无效轮询
	for {
		_, message, err := conn.ReadMessage()
		if err != nil {
			log.Println("Read error:", err)
			// 此处应有断线重连逻辑
			return
		}
		// 在这里处理 message (行情数据)
		fmt.Printf("Received depth update: %s\n", message)
	}
}

代码解读与优势： 这段代码的逻辑清晰地分为三步。昂贵的连接建立只在开始时发生一次。之后，主循环 `for` 中的 `conn.ReadMessage()` 是一个阻塞调用，它会挂起当前 goroutine，直到网络上真的有数据到来。CPU 在此期间是空闲的，不会进行任何无效的轮询。当撮合引擎产生新的深度变化，通过 WebSocket 网关推送下来时，`ReadMessage()` 立刻返回，程序对数据进行处理。这是一种纯事件驱动的模式，延迟最低，资源效率最高。

性能优化与高可用设计：对抗复杂性

选择 WebSocket 并非没有代价。它引入了新的复杂性，尤其是在状态管理和高可用方面。

延迟的量化对比

让我们对延迟来源做一个更精细的拆解，假设网络 RTT 为 50ms：

  • REST (Keep-Alive) 获取一次更新：
    • 请求传输：~0.5 RTT = 25ms
    • 服务端处理：~5ms (假设)
    • 响应传输：~0.5 RTT = 25ms
    • 总计：约 55ms 的网络延迟。这还不包括客户端的轮询间隔。如果轮询间隔 500ms，那么平均延迟是 250ms + 55ms。
  • WebSocket 接收一次推送：
    • 建连成本：(1.5 RTT for TCP + 1.5 RTT for TLS) = 150ms (仅一次)
    • 接收推送：
    • 服务端处理：~1ms (从撮合引擎到网关)
    • 数据传输：~0.5 RTT = 25ms
    • 总计：约 26ms 的网络延迟。数据产生后几乎立刻被推送到客户端。

结论是显而易见的。在持续的数据流场景下，WebSocket 在延迟上拥有数量级的优势。

WebSocket 的“状态”之殇与高可用挑战

REST 服务是无状态的，这意味着任何一个请求可以由集群中的任意一台服务器处理。服务器宕机了？负载均衡器把流量切到另一台就好了，对客户端几乎是透明的。

WebSocket 连接是有状态的。客户端 A 的连接在服务器 S1 上。如果 S1 宕机，这个 TCP 连接就断了。客户端必须检测到断线，然后重新连接。这时负载均衡器可能会把它导向服务器 S2。但 S2 如何知道客户端 A 之前订阅了哪些频道（`btcusdt@depth`）？

这就是状态管理的挑战。解决方案通常是：

  1. 客户端负责重连与重新订阅： 这是最简单的方案。客户端在检测到断线后，不仅要重连，还要把之前的订阅请求重新发一遍。
  2. 服务端会话持久化： WebSocket 网关在客户端订阅时，将订阅关系（如 `ClientID -> [sub1, sub2]`）写入一个外部的分布式缓存，如 Redis。当客户端重连到一台新的服务器 S2 时，S2 可以从 Redis 中加载该客户端的会话信息，自动恢复其订阅，对客户端更友好。

心跳与断线检测

另一个复杂性在于连接的健康检查。一个 TCP 连接可能因为中间网络设备（NAT、防火墙）的超时策略而被“静默”地断开。为了避免这种情况，WebSocket 协议内建了 PING/PONG 帧。服务端需要定期向客户端发送 PING 帧，客户端收到后必须在规定时间内回复 PONG 帧。如果服务端在超时时间内未收到 PONG，就可以安全地认为连接已死，并清理相关资源。反之，客户端也可以通过同样机制检测与服务端的连通性。这套心跳机制是保证 WebSocket 连接健壮性的关键，需要双方共同实现。

架构演进与落地路径

对于一个从零开始的交易平台，直接上全套复杂的 WebSocket 架构可能不是明智之举。一个务实的演进路径如下：

  1. 阶段一：RESTful 核心 + 公共数据 WebSocket。

    项目启动初期，快速迭代是关键。使用 REST API 实现所有的核心业务逻辑，包括下单、撤单、账户管理等。这部分最容易开发、测试和部署。同时，对于市场行情、深度这类公共数据，引入 WebSocket 服务。因为这部分数据是“只读”的，即使 WebSocket 服务不稳定，影响的也只是用户的行情展示，不会造成资金损失，风险可控。

  2. 阶段二：交易链路 WebSocket 化。

    当平台用户量和交易量上来后，REST下单的延迟成为瓶颈。此时，可以为专业用户和 API Trader 开放通过 WebSocket 进行下单、撤单的能力。这要求 WebSocket 网关变得更加可靠，并且需要与后端的撮合引擎、订单系统进行低延迟的交互。同时，订单状态的更新（如：已提交、部分成交、完全成交、已撤销）也通过 WebSocket 主动推送给客户端，形成一个完整的交易闭环。

  3. 阶段三：为顶级客户提供原生 TCP/IP 接口。

    对于延迟要求达到极致的机构客户或高频做市商，他们甚至无法忍受 WebSocket 的数据帧封装开销和 TLS 带来的微小延迟。最终极的方案是，为这些客户在数据中心内部或通过专线，提供基于原生 TCP 的二进制协议接口，例如金融行业标准的 FIX/FAST 协议或自研的 SBE (Simple Binary Encoding) 协议。这完全脱离了 Web 技术的范畴，是性能的终极追求，但开发和维护成本也最高。

总而言之，REST 和 WebSocket 不是相互替代的关系，而是在不同场景下各擅胜场的工具。架构师的职责，正是在深刻理解它们底层原理的基础上，结合业务的实际需求和发展阶段，做出最合理的组合与权衡，构建出既能满足当前性能要求，又为未来演进留有余地的稳健系统。

延伸阅读与相关资源

  • 想系统性规划股票、期货、外汇或数字币等多资产的交易系统建设，可以参考我们的
    交易系统整体解决方案。
  • 如果你正在评估撮合引擎、风控系统、清结算、账户体系等模块的落地方式，可以浏览
    产品与服务
    中关于交易系统搭建与定制开发的介绍。
  • 需要针对现有架构做评估、重构或从零规划，可以通过
    联系我们
    和架构顾问沟通细节，获取定制化的技术方案建议。
滚动至顶部