我在多个论坛中问过同样的问题。这个问题的常见答案仍然很奇怪:
但这些主要是向客户端传输或流式传输事件的方式。需要在它之上构建一些东西。还有很多其他的事情需要考虑,例如:
实时 API 的注意事项
向客户端发送哪些事件
如何仅向每个客户端发送他们需要的事件
如何处理事件授权
在哪里保存事件订阅的状态(对于无状态服务)
如何从因连接丢失和服务崩溃而错过的事件中恢复为搜索或分页查询生成事件
如何扩展
发布/订阅解决方案
有多种发布/订阅解决方案,例如:
但是由于基于主题的发布/订阅架构的限制,上述一些问题仍然没有得到解答,必须自己处理。例如连接丢失,Pusher has no fallback、SocketCluster 和 PubNub has a limited queue 也没有。
Resgate - 实时 API 网关
基于主题的传统发布/订阅模式的替代方案是使用资源感知实时 API 网关,例如 Resgate。
网关不是客户端订阅主题,而是跟踪客户端获取的资源(对象或数组),在取消订阅之前保持客户端数据最新。
作为 Resgate 的开发人员,我真的建议您检查一下,因为它解决了上述所有问题,与语言无关,简单轻量,而且速度极快。
在NATS blog了解更多信息。
缩放
假设您希望同时扩展并发客户端的数量和产生的事件数量。您最终需要确保每个客户端仅通过基于传统主题的发布/订阅或资源订阅获取他们感兴趣的数据。以上所有解决方案都可以解决这个问题。
我还假设所有上述解决方案通过允许您添加更多处理持久 WebSocket 连接的节点/服务器来扩展并发客户端。
使用 Resgate,第一级扩展只需运行多个实例(它是一个简单的可执行文件),并添加一个负载均衡器,在它们之间平均分配连接:
处理 1 亿个并发客户端
假设单个 Resgate 实例处理 10000 个持久 WebSocket 连接,您可以将 10000 个 Resgate(分布到多个数据中心)添加到单个 NATS Server。这将允许总共 100M 的连接。当然,根据您的数据,您可能还会遇到其他扩展问题,例如网络流量;)。
第二层扩展(并添加冗余)是将整个设置复制到不同的数据中心,并让服务使用 Kafka、CockroachDB 等其他工具在数据中心之间同步数据。
扩展数据检索
使用仅处理事件的传统发布/订阅解决方案,您还必须处理 HTTP (REST) 请求的扩展。
对于 Resgate,这不是必需的,因为资源数据也是通过 WebSocket 连接获取的。这使得 Resgate 不仅可以确保资源数据和事件同步(单独的 pub/sub 解决方案的另一个问题),而且可以缓存数据。如果多个客户端请求相同的数据,Resgate 只需从服务中获取一次,有效提高可扩展性。