使用消息队列扩展WebSockets

Question

我已经构建了一个WebSockets充当聊天消息路由器的服务器(即从客户端接收消息并根据客户端将其推送到其他客户端ID).

要求服务能够扩展以处理数百万个并发的开放套接字连接,并且我希望能够水平扩展服务器.

我所考虑的体系结构是将websocket服务器节点放在负载均衡器后面,这会产生问题,因为连接到不同节点的客户端不会彼此了解.当客户端A和客户端连接到节点时,客户端和客户端都可以B通过LoadBalancer客户端连接到节点- 每个节点都拥有自己的开放套接字连接字典.A1B2

为了解决这个问题,我正在考虑使用像ZeroMQ或或类似的MQ系统RabbitMQ.所有websocket服务器节点都将是MQ服务器的订户,并且当节点获得将消息路由到不在本地连接字典中的客户端的请求时,它将pub向MQ服务器发送消息,这将是MQ服务器的消息.告诉所有sub-scriber节点查找此客户端,并在它连接到该节点时发出消息.

Q1: 这种架构有意义吗？

Q2:pub-sub这里描述的模式真的是我想要的吗？

Answer 1

ZeroMQ将是我的选择 - 无论是架构方面还是性能方面

- 快速和低延迟(可以衡量您的实施性能和间接费用,低至子[usec]规模)

- 无代理(不引入另一个故障点,而自身可以有{N + 1 | N + M}自我修复架构)

- 准备使用的智能形式通信模式原语(PUB/ SUB是最不重要的原语)

- 内置公平队列和负载平衡架构(外部观察者不可见)

- 用于服务器端内部多进程/多线程分布式/并行处理的许多传输类

- 准备几乎线性可扩展性

自适应节点重新发现

这是一个更复杂的主题.您打算创建可行的架构将需要深入了解更多细节以解决.

• 节点身份验证与点对点消息传递
• 节点(重新) - 发现与法律和隐私问题
• 基于节点的自主自组织代理与中央策略实施的需求

Answer 2

为了在 2021 年进行更新，我们刚刚解决了这个问题，我们需要设计一个可以处理来自 IoT 设备的数百万个并发 WS 连接的系统。WS 服务器只是将消息中继到处理实际逻辑的无服务器 API 后端。我们选择使用 docker 和节点ws包，该节点包使用自动扩展的 AWS ECS Fargate 集群，前面有一个 ALB。

这解决了路由消息的主要问题，但是我们遇到了同样的问题，即如何从服务器路由响应消息。我们最初只想保留一个中央连接数据库，但将消息路由到 ALB 后面的特定 Fargate 实例似乎并不可行。

相反，我们使用 AWS SNS ( https://aws.amazon.com/pub-sub-messaging/ )设置了一个简单的 sub/pub 模式。每个 WS 服务器接收响应，然后搜索自己的 WS 连接。由于每个 Fargate 实例仅处理路由（无逻辑），因此当我们垂直扩展它们时，它们可以处理大量连接。

更新：为了提高性能，您可以使用 Redis Pub/Sub 之类的持久连接来允许响应消息仅发送到一台服务器而不是每台服务器。