我已经通过Azure应用网关公开了启用了websocket的服务终结点，并且该服务托管在Azure服务结构上。客户端启动与我的端点的websocket连接，并能够交换数据。在某些消息流期间，启用Web套接字的服务使用azure服务总线调用服务结构上托管的其他服务。这些以完全异步的方式处理。其他服务完成处理后，它们会将一条消息发布到服务总线，我的WebSocket服务将读取该消息。我遇到的问题是将消息路由回正确的服务结构节点，以便可以将其推回到WebSocket连接另一端的客户端
在下图中，您可以想象每个节点包含多个服务，包括启用Web套接字的服务。一旦Websocket服务将消息发布到服务总线，下游服务便开始处理，最后它们将消息发布回服务总线，websocket服务会回读该消息。在这里，一个随机节点将接收该消息，并且它可能没有相关的Websocket连接来将处理后的数据推回Sample Design
我看过redis pubsub模型，看起来我必须维护在节点上处理的最后一条消息。这也意味着，如果群集中的每个节点都没有与客户端建立websocket连接，则它们将需要阅读该消息并将其丢弃。我正在寻找针对此类问题的任何建议的设计模型
我遇到了类似的情况，不喜欢使用新的外部服务作为背板的想法，因为该背板只会在所有节点上复制每个消息/事件。
我确定的解决方案是依靠actor代理的属性，使用actor事件来回调特定的无状态服务实例。创建一个actor服务以充当发布/订阅背板。
解决方案总结在this blog post中。值得指出的是documentation状态的参与者事件是尽力而为]。当应用程序正常运行时，这并不是真正的问题，我认为在部署或故障转移期间，某些事件可能会丢失，但是可以缓解这种情况。
还值得注意的是，您的负载平衡规则应在客户端和后端实例之间保持粘性连接。如果只希望将此规则应用于websocket（而不是常规HTTP流量），则可以为websocket创建单独的规则。