为实时 JavaScript 应用选择传输方式与架构

用户已不再愿意通过刷新页面来查看是否有变化。聊天消息、正在移动的送货员、比赛比分或价格变动都应在其发生瞬间立即显示，任何可见的延迟都会被视为产品存在缺陷。本指南将介绍 JavaScript 为打造此类体验所提供的各种功能，从传输层到扩展性与可观测性，帮助你为聊天系统、流媒体功能或网页游戏选择合适的组件，并了解在流量增加时可能出现的问题。

从页面刷新到推送更新

早期的网络就像按需配送的印刷报纸。你打开一个页面，阅读内容，点击链接后等待下一份文档加载。除非主动请求，否则不会有新信息出现，而每次请求都需要完成一次完整的往返传输。

现代产品颠覆了这种关系。消息在有人点击发送的瞬间就会送达，比赛比分会在比赛中实时更新，交易界面会持续刷新，多人游戏能让众多玩家保持同步，而直播视频只需很短的延迟就能传递给大量观众。这些应用的共同点在于服务器主动发起操作：不再是客户端不断轮询“有新消息吗？”，而是后端在事件发生时将数据推送到每个感兴趣的连接端。

这就是实时应用的实际定义：将事件发生与用户看到其效果之间的时间差控制在尽可能小的范围内。典型的应用包括：

• 消息应用和实时通知
• 多人游戏和视频会议
• 交易及其他金融数据面板
• 外卖和打车服务追踪系统

协作文档编辑器

为何 JavaScript 适合这项工作

JavaScript 可在浏览器中运行，也可通过 Node.js 在服务器上运行，因此团队可以用同一种语言实现实时连接的双方功能，并在二者之间共享类型、验证规则和消息格式。

更重要的原因是运行时模型。Node.js采用事件驱动机制，并使用非阻塞I/O：一个事件循环会等待套接字处于可读或可写状态，一旦满足条件就执行相应的回调函数，而不会为每个连接单独分配一个线程。实时服务器大部分时间都在维持数千个大多处于空闲状态的连接，而这正是该模型能够高效处理的任务类型。不过需要注意的一点是：一次缓慢的同步计算会阻塞该进程中的所有连接，因此那些需要大量CPU算力的任务应该放在工作线程或独立的服务中。如需深入了解事件循环与线程池如何分配这些任务，请参阅libuv、事件循环与线程池之间的协作关系。

通过WebSockets实现聊天与消息传递

普通的 HTTP 是请求与响应的模式：浏览器发起请求，服务器回复，交流即告结束。这种模式并不适合聊天应用，因为服务器可能在不可预测的时间向客户端发送消息，而客户端无法知道何时该发起请求。基于定时器的轮询方式要么会浪费请求资源，要么会增加延迟。

WebSockets 通过将 HTTP 连接升级为持久性的全双工通道来解决这个问题。在握手完成后，任意一方都可以在任何时刻发送数据帧，从而实现：

• 双向即时传输
• 无需为每条消息重复发送请求或处理头部信息
• 由于连接已建立，延迟极低

浏览器内置了原生 WebSocket API，而 Node.js 也有完善的服务器端库。许多团队会选择 Socket.IO 而非原始套接字，因为它在基础功能之上增加了诸多实用特性：自动重连、无法建立 WebSocket 时的备用传输方式、用于分组用户的房间功能、向多个客户端广播的能力，以及基于命名事件的 API，无需手动解析消息。需要注意的是，Socket.IO 使用自己的协议，因此 Socket.IO 客户端必须与 Socket.IO 服务器通信。如果您想详细了解聊天后端的房间功能、数据持久化及扩展方案，我们的实时聊天后端指南中有相关介绍。

利用 WebRTC 实现音频、视频和屏幕共享

流媒体是互联网流量中占比最大的类别之一，涵盖游戏直播、在线课程、视频通话、体育赛事转播以及产品发布等内容。对于浏览器中的交互式媒体，关键技术是WebRTC，它支持：

• 视频和音频流
• 屏幕共享
• 浏览器之间的直接点对点连接

由于媒体可以直接在终端之间传输而无需经过服务器，WebRTC能够实现低延迟、节省服务器带宽，同时保持较高的通话质量，这也是它成为众多会议工具基础的原因。实际上，仍需要一个信号通道（通常是WebSocket）来帮助终端彼此找到对方，而在无法建立直接连接的网络环境中则需使用中继服务器。对于面向海量受众的一对多广播，纯点对点模式已无法扩展，此时就需要由媒体服务器来承担传输任务。

多人浏览器游戏

游戏是对延迟最为敏感的领域：玩家的每一个动作几乎都必须立即传递给其他玩家，否则游戏体验就会出问题。基于浏览器的多人游戏通常会使用WebSockets建立网络连接，服务器端采用Node.js，渲染则依靠Canvas或WebGPU，而动作与碰撞处理则由物理引擎负责。

网络流量包含各种事件，如玩家移动、射击、分数变化、碰撞结果以及匹配过程。服务器通常作为数据源头，以固定频率向所有连接的玩家广播最新的游戏状态。通过仅传输发生变化的部分来高效同步状态，决定了游戏的体验是流畅还是卡顿。

以事件为导向的设计

每个实时系统都会持续产生大量事件：新消息、用户加入、支付确认、游戏操作、通知以及流媒体更新。JavaScript天生适合处理事件驱动型代码，因此无需反复检查是否有事件发生，处理函数只会在事件实际发生时才会执行。

这种设计在性能、可扩展性和资源使用方面都有优势。Node.js可以通过事件循环同时处理大量并发操作，而无需为每个连接单独分配线程，从而降低每个客户端所占用的内存。

利用消息中间件实现多服务器扩展

迟早，单个进程将无法承载所有连接。想象一个拥有数百万用户的消息平台：同一对话中的两个人可能连接到不同的服务器，而且一条消息在到达接收者之前可能需要经过多个后端服务处理。

Apache Kafka和RabbitMQ等消息中间件通过将事件可靠地分发到各个应用服务器之间，来协调这些流量。它们具备以下功能：

• 水平扩展能力，因为只需添加服务器而非升级现有服务器
• 在某个实例出现故障时仍能保持正常运行
• 确保事件的可靠传递
• 在高负载情况下仍能保持高吞吐量

Redis也常被用作轻量的发布/订阅层，例如用于将Socket.IO的广播消息分发到各个节点。大型实时系统几乎总是依赖某种形式的消息传递基础设施。

通过边缘部署和多区域部署降低延迟

距离意味着延迟。如果每个用户都要与远端的数据中心通信，那么无论代码运行得多快，每次往返都会产生相应的成本。边缘计算将处理任务移至更靠近用户的位置，从而实现更快的响应速度、更低的网络延迟、更好的流媒体质量以及更出色的游戏响应性。

正因如此，JavaScript 服务越来越多地部署在多个地理区域。对于全球用户而言，这能显著提升感知速度，但同时也带来了新问题：分布在多个区域的系统状态必须保持一致，因此需要尽早确定哪些数据应存储在单一位置。

实时系统的可观测性

在实时产品中，几百毫秒的延迟就已经会被用户察觉，因此需要持续监控而非偶尔检查。有用的指标包括：

• 开放连接数和活跃用户数

事件处理吞吐量

消息延迟与传输时间

错误率

内存和CPU使用情况

每秒数据包数与网络带宽

重连成功率

Prometheus用于收集指标，Grafana用于制作仪表板，这是常见的组合。仅查看平均值是不够的；还需跟踪延迟的分位数，因为正是那少部分传输缓慢的情况才会引发用户投诉。良好的监控机制能在问题演变成故障之前就发现瓶颈。

这些模式出现的场景

相同的底层组件被用于截然不同的产品中：

• 聊天：消息可在设备间即时传输。
• 视频会议：参与者可共享实时音频和视频。
• 网络游戏：玩家在同一个同步的世界中竞争。

金融平台：价格会随着交易的发生而实时更新。

拼车服务：司机和乘客可以持续查看对方的定位。

外卖配送：顾客可以实时追踪订单的处理进度。

协作编辑：多人可同时修改同一份文档。

难点所在

保持连接畅通及数据最新状态会带来请求-响应型应用很少遇到的问题：

• 因用户和地区不同而产生的网络延迟
• 连接中断，尤其是在移动网络上
• 当事件顺序混乱时的消息排序问题
• 长期连接的扩展问题
• 在客户端和服务器之间保持状态同步
• 大量开放套接字导致的内存增长
• 未经认证或验证的通道存在的安全漏洞

应假设网络可能不可靠。客户端应通过延迟重试自动重新连接，尽可能从已知状态继续处理，并妥善处理重复数据；而服务器则应优雅地处理故障，而非一次性断开所有连接。

生产环境检查清单

• 为实现频繁更新，优先使用 WebSockets 而非重复轮询。
• 保持消息载荷大小适中，并在适当情况下对数据进行压缩。
• 要对每次连接进行身份验证，而不仅仅是初始页面加载时。
• 为每个连接或用户设置速率限制。
• 采用水平扩展方式，并通过消息代理或发布/订阅层来传递事件。
• 缓存许多客户端都会请求的数据。
• 持续监控系统运行状况。

遵循此方案的常见技术栈将 Node.js、Socket.IO 和 WebRTC 与 Redis 及 Apache Kafka 相结合，通过容器编排技术在云负载均衡器后部署，并借助监控面板进行实时监测。经过精心设计，这类架构能够在保持低延迟的同时服务大量并发用户。

实时 JavaScript 的发展前景

多项技术趋势正在拓展实时应用的功能：由人工智能驱动的协作功能、使用 WebGPU 的多人游戏、为边缘设备原生开发的应用程序、浏览器中的云游戏、沉浸式虚拟现实、实时人工智能助手以及延迟越来越低的视频传输。随着基础设施的不断改进，即时响应已逐渐成为默认期望，而非竞争优势。

这也使得相关的核心技能变得十分重要：事件驱动编程、分布式系统与网络通信，以及可扩展的后端设计、低延迟架构和云原生开发，在金融科技、医疗保健、游戏及社交平台领域都备受需求。

关键要点

• 根据数据流量特点选择传输方式：双向通信选用 WebSockets 或 Socket.IO，媒体传输则用 WebRTC。
• 只要避免在事件循环上执行阻塞操作，它就能让 Node.js 高效地处理大量连接。
• 应尽早规划多台服务器；通过消息代理或发布/订阅机制来决定事件如何在不同实例间传递。
• 延迟还与地理位置有关，因此当用户遍布全球时，应将服务部署在靠近用户的地点。
• 设计时要考虑故障情况：重连、消息排序和身份认证是必需的功能，而非锦上添花的内容。

应衡量延迟百分位数和重新连接率，而不仅仅是正常运行时间。