REST API vs WebSocket: 交易系统延迟的毫秒之争

作者： /

在高频交易、实时风控和数字货币撮合等对延迟极度敏感的场景中，选择合适的应用层通信协议并非一个简单的技术选型问题，而是一个决定系统生死存亡的架构决策。本文将面向有经验的工程师，从操作系统内核、网络协议栈的底层视角出发，深入剖析 REST API 与 WebSocket 在真实交易场景下的本质差异。我们将不仅停留在“REST是短连接，WebSocket是长连接”的表层认知，而是穿透到TCP握手、TLS开销、内核态/用户态切换、数据帧结构等核心，并结合实战代码与架构演进路径，量化分析它们在延迟、吞吐与资源消耗上的权衡。

现象与问题背景

想象一个典型的数字货币交易所场景。用户界面需要同时展示两类核心信息：一是毫秒级更新的盘口（Order Book）和最新成交价（Ticker），二是在用户发起交易后，其实时订单状态（开仓、部分成交、完全成交、已撤销）。

如果采用传统的 RESTful API 架构，我们会面临两个经典的反模式：

  • 获取实时行情：客户端为了获取最新价格，不得不以极高的频率（例如每 100 毫秒）轮询服务端的 GET /api/v1/ticker/BTC-USDT 接口。这导致了巨大的资源浪费。首先，绝大多数请求可能返回的是相同的数据，因为市场并未在那 100ms 内发生变化。其次，每一次 HTTP 请求，都意味着一次完整的“请求-响应”生命周期，背后是网络、服务器CPU和带宽的持续消耗。更致命的是，轮询机制本身带来了固有延迟和信息滞后性，你永远只能拿到“上一个时间切片”的数据。
  • 执行交易与获取状态：用户点击“买入”按钮，客户端发起一个 POST /api/v1/orders 请求。请求发出后，客户端并不知道订单何时被撮合引擎处理、何时成交。为了获取订单状态，客户端又必须开始轮询 GET /api/v1/orders/{orderId}。这种体验是割裂且低效的。在价格剧烈波动的市场中，当用户看到订单成交时，可能已经错过了最佳的止损或止盈点。

这些问题的根源在于 HTTP 协议的无状态、请求-响应模型。它被设计用于文档获取，而非为双向、实时的流式通信服务。在这种模型下，服务端永远是被动的，无法主动将数据的变更推送给客户端。这正是 WebSocket 需要解决的核心痛点。

关键原理拆解

要理解 REST 和 WebSocket 的天壤之别，我们必须回到计算机科学的基础原理，像一位教授一样，从协议栈的底层向上剖析。

TCP 连接的建立与消耗

无论是 HTTP 还是 WebSocket，它们的应用层数据都承载于 TCP 协议之上。一个 TCP 连接的建立，并非零成本。它至少包含：

  • 三次握手 (Three-Way Handshake): 客户端与服务端通过交换 SYN 和 ACK 包来建立连接。这个过程至少需要 1.5 个 RTT (Round-Trip Time)。在一个跨国网络环境中，一个 RTT 可能就是 200ms。这意味着仅建立连接，延迟就已是百毫秒级别。
  • TLS/SSL 握手: 在 HTTPS 和 WSS (Secure WebSocket) 场景下，TCP 握手之后还需要进行 TLS 握手，用于密钥交换和身份验证。根据加密套件的不同，这可能需要额外的 1-2 个 RTT。

对于频繁请求的 REST API，即使使用了 HTTP Keep-Alive 来复用 TCP 连接，也存在连接被服务器或中间网关（如Nginx）因超时而关闭的可能。一旦连接关闭，下一次请求就必须承担这数百毫秒的“启动惩罚”。在高频场景下，这种不确定性是不可接受的。

协议开销与数据帧

HTTP/1.1 协议是文本协议，其头部信息（Headers）冗长且重复。在一个典型的 REST API 请求中，Host, User-Agent, Accept, Cookie 等字段在每次请求中都会被发送，即使它们的值完全没有变化。这在小包高频的场景下，造成了极大的带宽浪费。HTTP/2 通过头部压缩（HPACK）缓解了这个问题，但其请求-响应的本质并未改变。

相比之下，WebSocket 在通过 HTTP Upgrade 握手建立连接后，后续的数据传输使用的是 WebSocket 自己的数据帧格式。其帧头非常小，通常只有 2-10 字节。这使得它在传输小块数据（如一次价格变动）时，协议开销极低，信噪比极高。

更重要的是，WebSocket 是一个全双工 (Full-Duplex) 的协议。连接建立后，客户端和服务端处于对等的地位，双方可以随时向对方主动推送消息，无需任何“请求”作为前置。数据在同一个 TCP 连接上双向流动，彻底打破了 HTTP 的请求-响应枷锁。

内核态与用户态的切换

在服务端，每一次独立的 HTTP 请求到达，操作系统内核都需要通过网络中断将其唤醒，将数据包从网卡缓冲区拷贝到内核空间，再由内核通知并拷贝给处于用户态的 Web 服务器进程（如 Nginx worker）。这个过程涉及多次上下文切换和内存拷贝。对于一个每秒处理数万次轮询请求的服务器，这些底层的开销会迅速累积，成为性能瓶颈。

而 WebSocket 服务器，一旦与客户端建立长连接，它就可以在相当长的一段时间内持有一个文件描述符（File Descriptor）。当有数据需要推送时，它可以直接将数据写入该描述符对应的 TCP 发送缓冲区，后续由内核负责发送。这个路径更短、更高效。服务器不再需要为每个客户端的“下一次轮询”做准备，而是转变为一个事件驱动模型：仅当有真实数据（如行情更新、订单成交）产生时，才去遍历所有订阅了该数据的连接，并进行一次写操作。这极大地降低了 CPU 的空转和上下文切换开销。

系统架构总览

一个成熟的交易系统，通常会采用 REST 和 WebSocket 混合的架构，各司其职，发挥其最大优势。我们可以用文字勾勒出这样一幅架构图：

  • 用户端 (Client): 浏览器或移动 App。
  • 接入层 (Access Layer):
    • Nginx/API Gateway: 作为流量入口，负责 SSL 卸载、路由分发和限流。所有形如 /api/* 的 RESTful 请求被路由到后端的 REST 服务集群。所有形如 /ws/* 的 WebSocket 连接请求，通过 proxy_pass 并设置特定的 `Upgrade` 和 `Connection` 头，被升级并代理到后端的 WebSocket 网关集群。
  • 服务层 (Service Layer):
    • REST 服务集群: 一组无状态的微服务，处理那些非实时的、操作性的请求。例如：用户注册/登录、查询历史订单、充值提现等。这些服务可以独立扩缩容。
    • WebSocket 网关集群: 一组有状态的服务。每个网关节点都维护着成千上万条与客户端的持久化 WebSocket 连接。它的核心职责是管理连接的生命周期、维护客户端的订阅关系（哪个客户端订阅了哪个交易对的行情）。
  • 消息中间件 (Message Queue):
    • Kafka/RocketMQ: 系统的神经中枢。所有需要实时广播的数据，如行情数据、撮合结果，都由上游的生产者（如行情引擎、撮合引擎）发布到特定主题（Topic）中。
  • 核心业务域 (Core Business Domain):
    • 行情引擎 (Market Data Engine): 从上游交易所或数据源获取原始数据，清洗、聚合后，将标准化的行情数据（Ticker, Order Book）推送到 Kafka 的行情主题中。
    • 撮合引擎 (Matching Engine): 负责处理交易订单的撮合，一旦有成交，就将成交结果推送到 Kafka 的成交主题中。

在这个架构中，数据流是清晰的单向流动。例如，行情更新的路径是：行情引擎 -> Kafka Topic -> WebSocket 网关 -> 客户端。WebSocket 网关作为 Kafka 的消费者，一旦从特定主题消费到新消息，就会立即查询内部的订阅关系表，找到所有关注该主题的客户端连接，并将消息推送下去。这种发布-订阅模式完美解耦了数据生产者和消费者，具有极高的可扩展性。

核心模块设计与实现

现在，让我们切换到极客工程师的视角，深入到代码层面，看看这些模块是如何实现的，以及其中的坑点。

REST API 轮询的“反模式”代码

这是一个典型的、糟糕的客户端轮询实现。虽然简单，但它是一切性能问题的根源。


// Bad Practice: Client-side polling for ticker data
async function pollTicker() {
    while (true) {
        try {
            const response = await fetch('https://api.exchange.com/api/v1/ticker/BTC-USDT');
            if (response.ok) {
                const data = await response.json();
                updateUI(data); // Update UI with the latest price
            }
        } catch (error) {
            console.error('Polling error:', error);
        }
        // Wait for 1 second before the next poll, introducing at least 1s of latency.
        await new Promise(resolve => setTimeout(resolve, 1000));
    }
}

pollTicker();

犀利点评： 这种代码在开发原型时很方便，但在线上就是灾难。setTimeout 的 1 秒延迟，意味着你看到的价格永远是至少 1 秒前的。如果把间隔改到 100ms，客户端和服务端的压力都会骤增 10 倍。更糟糕的是，JavaScript 的定时器并不精确，并且网络延迟是变化的，你无法保证稳定的更新频率。这种实现方式，让你的服务器大部分时间都在处理重复的查询和构建相同的响应，CPU 都在执行无效劳动。

WebSocket 网关的核心实现 (Go 语言示例)

一个健壮的 WebSocket 网关需要处理连接管理、并发读写和订阅逻辑。以下是一个简化的 Go 语言实现骨架，展示了核心思想。


package main

import (
	"log"
	"net/http"
	"sync"
	"github.com/gorilla/websocket"
)

// Hub maintains the set of active clients and broadcasts messages to the clients.
type Hub struct {
	clients    map[*Client]bool
	broadcast  chan []byte
	register   chan *Client
	unregister chan *Client
	mu         sync.Mutex // Protects clients map
}

// Client is a middleman between the websocket connection and the hub.
type Client struct {
	hub  *Hub
	conn *websocket.Conn
	send chan []byte
}

var upgrader = websocket.Upgrader{
	ReadBufferSize:  1024,
	WriteBufferSize: 1024,
	CheckOrigin: func(r *http.Request) bool { return true }, // Allow all origins
}

// serveWs handles websocket requests from the peer.
func serveWs(hub *Hub, w http.ResponseWriter, r *http.Request) {
	conn, err := upgrader.Upgrade(w, r, nil)
	if err != nil {
		log.Println(err)
		return
	}
	client := &Client{hub: hub, conn: conn, send: make(chan []byte, 256)}
	client.hub.register <- client

	// Start reader and writer goroutines for this client
	go client.writePump()
	go client.readPump()
}

// readPump pumps messages from the websocket connection to the hub.
func (c *Client) readPump() {
	defer func() {
		c.hub.unregister <- c
		c.conn.Close()
	}()
	// Handle incoming messages, e.g., subscribe/unsubscribe commands
	for {
		_, message, err := c.conn.ReadMessage()
		if err != nil {
			break
		}
		// In a real system, you'd parse this message for commands.
		// For example: {"action": "subscribe", "topic": "ticker.BTC-USDT"}
		log.Printf("Received message: %s", message)
	}
}

// writePump pumps messages from the hub to the websocket connection.
func (c *Client) writePump() {
	defer c.conn.Close()
	for {
		select {
		case message, ok := <-c.send:
			if !ok {
				c.conn.WriteMessage(websocket.CloseMessage, []byte{})
				return
			}
			c.conn.WriteMessage(websocket.TextMessage, message)
		}
	}
}

// This is a simplified broadcaster. A real system would use Kafka.
func (h *Hub) run() {
    for {
        // Mocking data coming from Kafka
        time.Sleep(200 * time.Millisecond)
        message := []byte(`{"topic":"ticker.BTC-USDT", "price":"50000.00"}`)
        
        h.mu.Lock()
        for client := range h.clients {
            select {
            case client.send <- message:
            default:
                // If the send buffer is full, we assume the client is slow
                // and disconnect it. This prevents a slow client from blocking the hub.
                close(client.send)
                delete(h.clients, client)
            }
        }
        h.mu.Unlock()
    }
}

犀利点评： 这是更接近工程现实的模式。每个连接由独立的 `readPump` 和 `writePump` 两个 goroutine 处理，实现了读写分离，避免了相互阻塞。`hub` 结构负责管理所有客户端连接。注意 `client.send` 是一个带缓冲的 channel，这是个关键的保护机制。如果某个客户端网络很差，导致 `writePump` 消费不及时，这个 channel 会被填满。在 `default` case 里关闭 channel 并移除客户端，可以防止一个“慢消费者”拖垮整个服务器。真正的生产级网关，`Hub` 不会自己生产数据，而是会有一个或多个 Kafka consumer goroutine，它们负责从 Kafka 拉取消息，然后分发到 `broadcast` channel 中。

性能优化与高可用设计

单纯选择 WebSocket 并不意味着一劳永逸，它引入了新的复杂性，尤其是在状态管理和高可用方面。

WebSocket 的挑战：状态与“连接风暴”

REST 服务的无状态特性使其极易水平扩展。你可以随时增加或减少实例，负载均衡器会均匀地分发请求。但 WebSocket 网关是有状态的，每个节点都维持着一部分客户端的长连接。这就带来了几个严峻的挑战：

  • 单点故障： 如果一个网关节点宕机，该节点上承载的所有客户端连接会瞬间全部断开。
  • 连接风暴 (Connection Storm)： 宕机后，这些客户端会几乎在同一时间尝试重连。如果你的负载均衡策略是将它们随机打到其他健康的节点上，可能会导致这些节点因为瞬间接入大量连接而过载，引发雪崩效应。
  • 数据一致性： 在客户端重连到新的网关节点后，它需要重新订阅之前的主题。在此期间，它可能会丢失几条关键消息。

对抗策略与权衡

  1. 客户端优雅重连： 客户端必须实现带指数退避和随机抖动的重连机制（Exponential Backoff with Jitter）。这可以避免所有客户端在同一时刻冲击服务器。
  2. 网关层面的负载均衡： 使用支持 WebSocket 的 L7 负载均衡器（如 Nginx），但需要 careful planning。简单的轮询策略会导致用户在不同页面刷新时连接到不同的后端节点。更优的方案是基于用户ID或设备ID做一致性哈希，让同一个用户的连接尽可能落在同一个网关节点上，便于状态管理和问题排查。
  3. 心跳机制 (Heartbeating)： TCP Keepalive 在很多复杂的网络环境（如NAT网关）下可能会失效。应用层必须实现自己的心跳机制。由客户端定时发送 ping 帧，服务端在收到后立即回复 pong 帧。如果在规定时间内未收到对方的响应，则认为连接已死，主动关闭并清理资源。这能及时发现“僵尸连接”。
  4. 服务发现与状态迁移： 更高级的架构中，网关节点可以设计成半状态的。连接元数据（如用户ID、订阅列表）可以存储在外部的分布式缓存（如 Redis）中。当一个节点即将进行优雅停机时，它可以通知客户端进行重连，或者由控制平面将连接主动迁移到其他节点。但这极大地增加了系统复杂度。

最终的权衡是：用 WebSocket 连接的状态复杂性，换取了极致的低延迟和高效率。 对于交易系统而言，这笔交易是值得的。

架构演进与落地路径

一个团队不可能一步就建成一个完美的全球分布式实时系统。演进路径至关重要。

  • 阶段一：单体混合模式。 在项目初期，可以快速搭建一个单体应用，同时提供 RESTful API 和 WebSocket 服务。REST 处理低频操作，WebSocket 处理核心行情推送。使用一个简单的内存 Map 来管理订阅关系。此阶段重点是快速验证业务模型，容忍单点故障。
  • 阶段二：服务化与解耦。 随着业务量增长，将单体应用拆分为独立的 REST 服务集群和 WebSocket 网关集群。引入 Kafka 作为核心消息总线，实现生产者和消费者的彻底解耦。此时，WebSocket 网关可以水平扩展，前端部署 Nginx 做负载均衡。这是大多数中型交易所采用的经典架构。
  • 阶段三：全球化与多活。 为了服务全球用户，降低物理距离带来的网络延迟，需要在全球多个数据中心（如东京、伦敦、纽约）部署 WebSocket 网关集群。通过 DNS 智能解析（如 GeoDNS）将用户导向最近的接入点。后端通过专线或可靠的公网传输，实现多地域间 Kafka 集群的数据同步，确保无论用户连接到哪个地区的网关，都能收到一致的实时数据。这一阶段对运维和架构能力提出了极高的要求。

总而言之，REST API 与 WebSocket 并非简单的替代关系，而是在现代复杂系统中相互协作、优势互补的两种工具。为非实时、命令式的交互选择 REST，能享受其简单、无状态、易于缓存和扩展的优点。而对于那些需要服务器主动、低延迟推送数据的实时场景，如交易行情、实时通知、在线协作等，拥抱 WebSocket 及其背后的事件驱动架构，才是通往高性能、优秀用户体验的必由之路。

延伸阅读与相关资源

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