我正在尝试构建一个包含即时消息模块的应用程序，主要挑战之一是无论用户数量或交换的消息有多少，都要保持应用程序的可扩展性。
在an article 中，我读到可以使用带有“订阅”的 GraphQL 构建实时应用程序，除此之外，它使用起来很简单，并且具有最小化往返对象检索的优点，因此更少的资源使用。
但是如果我们需要向系统添加一个新的服务器/节点以便水平扩展呢？这可以使用 GraphQL 吗？
以允许水平缩放的 websockets 实现为例，有SocketCluster。我想知道单独由 GraphQL 开发的应用程序是否可以跨多个节点/机器进行扩展，或者它必须与其他框架（如 SocketCluster）一起使用才能实现这一目标。
【问题讨论】：
标签： node.js graphql socketcluster
很快 - 是的。我们已经做到了，而且效果很好。
诀窍在于，在涉及水平扩展时，您必须比 API 工作者应用程序更深入地思考。如果你想要推送架构，它需要从一开始就异步。
为了实现它，我们使用了排队系统，即RabbitMQ。
想象一下这种报告生成场景，这可能需要 10 分钟：
ReportGenerationDoneEvent 上接收信息，并检查是否有人在监听它的令牌。ReportGenerationDoneEvent。它相当广泛，但通过简单的抽象，您不必考虑所有这些复杂性，并为使用此路由的新进程编写跨多个服务的大约 30 行代码。
它的精彩之处在于，您最终获得了不错的水平扩展、事件可重放性（重试）、关注点分离（客户端、api、worker），尽可能快地将数据推送到客户端，并且随着您提到您不会在 are we done yet? 请求上浪费带宽。
另一个很酷的事情是，每当用户在我们的面板中打开报告列表时，他会看到当前正在生成的报告，并且可以订阅他们的更改，因此他们不必手动刷新列表。
关于 SocketCluster 的好想法。它将优化上述场景中的第 10 步，但目前，我们没有看到将 ReportGenerationDoneEvent 广播到整个 API 集群的任何性能问题。对于更多实例或多区域架构，这将是必须的，因为它可以实现更好的扩展和分片。
理解 SocketCluster 运行在通信层（WebSockets）很重要，但逻辑 API 层（GraphQL）在此之上。要进行 GraphQL 订阅，您只需使用允许您向用户推送信息的通信协议，而 WebSockets 允许这样做。
我认为使用 SocketCluster 是一个不错的设计选择，但请记住迭代实现。仅当您计划在任何单个时间点打开多个套接字时才使用 SocketCluster。此外，您应该只在必要时订阅，因为 WebSocket 是有状态的，需要管理和心跳。
如果您对我上面使用的异步后端架构进一步感兴趣，请阅读 CQRS 和事件溯源模式。
【讨论】：