通过

Azure Web PubSub 如何支持 Socket.IO 库？

  • 项目

本文从工程角度介绍了如何使用 Web PubSub for Socket.IO 将自承载 Socket.IO 应用迁移到 Azure，且只需对代码进行最少更改。 然后，你可以利用简化的应用体系结构和部署，同时实现 100,000 个并发连接。 你无需了解本文中的所有内容，也可以有效地使用 Web PubSub for Socket.IO。

自承载 Socket.IO 应用的体系结构

下图显示了自承载 Socket.IO 应用的典型体系结构。

Diagram of a typical architecture of a self-hosted Socket.IO app, including clients, servers, a load balancer, and an adapter.

为了确保应用可缩放且可靠，Socket.IO 用户通常具有涉及多个 Socket.IO 服务器的体系结构。 客户端连接分布在 Socket.IO 服务器之间，以平衡系统上的负载。

当开发人员需要将同一消息发送到连接到不同服务器的客户端时，多个 Socket.IO 服务器的设置会带来挑战。 开发人员通常将此用例称为“广播消息”。

Socket.IO 库中的官方建议是引入一个名为适配器的服务器端组件来协调 Socket.IO 服务器。 适配器会找出客户端连接到的服务器，并指示这些服务器发送消息。

添加适配器组件会同时为开发和部署带来复杂性。 例如，如果体系结构使用 Redis 适配器，则开发人员需要：

  • 实现粘滞会话。
  • 部署和维护 Redis 实例。

建立实时信道所需的工程精力和时间会分散开发人员的精力，使他们无暇开发那些能让应用或系统独一无二并对用户有价值的功能。

Web PubSub for Socket.IO 旨在为开发人员解决哪些问题

尽管开发人员经常报告称使用 Socket.IO 库构建可靠且可缩放的应用具有挑战性，但开发人员可以从直观的 API 和库所支持的各种客户端中受益。 Web PubSub for Socket.IO 建立在库带来的价值之上，同时减轻了开发人员在可靠且大规模地管理持久连接方面的复杂性。

在实践中，开发人员可以继续使用 Socket.IO 库的 API，而无需预配服务器资源来维护 WebSocket 或基于长轮询的连接，它们可能会占用大量资源。 此外，开发人员无需管理和部署适配器组件。 应用服务器只需发送单个操作，Web PubSub for Socket.IO 即会将消息广播到相关的客户端。

如何操作

Web PubSub for Socket.IO 通过实现适配器和 Engine.IO 在 Socket.IO 协议的基础上构建。 下图显示了将 Web PubSub for Socket.IO 与你的 Socket.IO 服务器配合使用时的典型体系结构。

Screenshot of a typical architecture of a fully managed Socket.IO app.

与自承载 Socket.IO 应用一样，你仍需要在自己的服务器上托管 Socket.IO 应用程序逻辑。 但是，使用 Web PubSub for Socket.IO 服务时：

  • 你的服务器不再直接管理客户端连接。
  • 你的客户端与服务建立持久连接（客户端连接）。
  • 你的服务器还会与服务建立持久连接（服务器连接）。

当你的服务器逻辑使用 send to client、broadcast、add client to rooms 时，这些操作将通过建立的服务器连接发送到服务。 来自你的服务器的消息将转换为 Socket.IO 客户端可以理解的 Socket.IO 操作。 因此，任何现有的 Socket.IO 实现都可以运行，而无需进行重大修改。 需要进行的唯一修改是更改客户端连接到的终结点。 有关详细信息，请参阅迁移自承载 Socket.IO 应用以在 Azure 上完全托管。

当客户端连接到服务时，服务会：

  • 将 Engine.IO 连接 (connect) 转发到服务器。
  • 处理客户端连接的传输升级。
  • 将所有 Socket.IO 消息转发到服务器。