本文从自承载 Socket.IO 应用如何通过最少的代码更改迁移到 Azure 来简化应用体系结构和部署，同时实现开箱即用的 100 K+ 并发连接这一问题，从一个令人思考的视角来揭开帷幕。 无需了解本文中的所有内容，就能够有效地使用 Web PubSub 进行 Socket.IO。

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

此图显示了自承载 Socket.IO 应用的典型体系结构。 为了确保应用可缩放且可靠，Socket.IO 用户通常具有涉及多个 Socket.IO 服务器的体系结构。 客户端连接分布在 Socket.IO 服务器之间，以平衡系统上的负载。 当开发人员需要向连接到不同服务器的客户端发送相同的消息时，设置多个 Socket.IO 服务器会带来挑战。 开发人员通常将此用例称为“广播消息”。

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

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

获取实时信道的工程工作量和时间分散了开发人员的注意力，让他们无法开发使应用或系统对最终用户具有独特性和价值的功能。

适用于 Socket.IO 的 Web PubSub 旨在为开发人员解决哪些问题

尽管开发人员经常将设置使用 Socket.IO 库构建的可靠且可缩放的应用报告为具有挑战性，但开发人员 喜欢 提供的直观 API 和库支持的各种客户端。 Web PubSub for Socket.IO 基于库带来的值，同时减轻了开发人员可靠且大规模地管理持久连接的复杂性。

实际上，开发人员可以继续使用 Socket.IO 库提供的 API，但不需要预配服务器资源来维护基于 WebSocket 或基于长轮询的连接，这可能会占用大量资源。 此外，开发人员无需管理和部署“适配器”组件。 应用服务器只需发送 单个 操作，web PubSub for Socket.IO 会将消息广播到相关客户端。

它如何在幕后工作？

适用于 Socket.IO 的 Web PubSub 通过实现适配器和 Engine.IO 基于 Socket.IO 协议。 此图描述了将 Web PubSub 用于 Socket.IO 与 Socket.IO 服务器时的典型体系结构。

与自承载 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 。

当客户端连接到服务时，该服务