是否有基于 WebSocket 的标准 PubSub 协议？

Question

我正在寻找一种在用不同语言编写的应用程序之间实现基本发布/订阅的方法，以使用 JSON 有效负载交换事件。

WebSocket 似乎是传输的明显选择，但您需要在顶部有一个（可以说很小）层来实现一些管道：

• 同意代表 pubsub 域的消息“订阅主题”、“发布消息”
• 同意基础设施的消息（“心跳”、“身份验证”）

我期待为此找到一个明显的标准，但似乎没有。

• WAMP 经常被提及，但根据我的（短暂的）经验，服务器/客户端库的实现并不是很好
• STOMP 经常被提及，但根据我（甚至更短）的经验，它甚至更糟
• Phoenix 频道不错，但仅限于 Phoenix/Elixir 世界，而不是标准频道（因此可以在任何 phoenix 版本中更改消息，恕不另行通知。）

那么，每个人都在使用 MQTT/WS（需要另一个代理组件，而不是简单的服务器？）还是 gRPC？

每个人都只是从头开始重新实现它吗？ （这是一件看起来很容易自己做的事情，但我猜你最终会得到我正在寻找的东西的半生不熟、规格不全、损坏的版本......）

或者，通过 WS 从服务器提供数据流的想法是否存在根本性的问题？

Answer 1

WebSocket 库有两个主要类；那些实现协议并将其余部分留给开发人员的那些，以及那些构建在协议之上并具有实时消息传递应用程序通常需要的各种附加功能的那些，例如恢复丢失的连接、发布/订阅和通道、身份验证、授权、等等。

后一种类型通常需要在客户端使用它们自己的库，而不仅仅是使用浏览器提供的原始 WebSocket API。因此，确保您对他们的工作方式和所提供的内容感到满意变得至关重要。一旦它被集成到您的架构中，您可能会发现自己被锁定在您选择的解决方案的做事方式中，并且可靠性、性能和可扩展性方面的任何问题都可能再次困扰您。

ws、faye-websockets、socket.io、μWebSockets 和 SocketCluster 是一些不错的开源选项。

服务器可以处理的并发连接数很少成为服务器负载的瓶颈。大多数像样的WebSocket 服务器可以支持数千个并发连接，但是一旦 WebSocket 服务器进程处理了实际数据的接收，处理和响应消息所需的工作量是多少？

---

通常会有各种潜在的问题，例如从数据库读取和写入、与游戏服务器集成、为每个客户端分配和管理资源等等。

一旦一台机器无法处理工作负载，您就需要开始添加额外的服务器，这意味着现在您需要开始考虑负载平衡、连接到不同服务器的客户端之间的消息同步，无论连接寿命或客户端连接到的特定服务器如何，对客户端状态的通用访问 - 列表不胜枚举。

实现对 WebSocket 协议的支持涉及很多方面，不仅在客户端和服务器实现细节方面，还涉及对其他传输的支持，以确保对不同客户端环境的稳健支持，以及更广泛的关注点，例如authentication and authorization、guaranteed message delivery、reliable message ordering、historical message retention 等等。如果您不想重新发明轮子，那么在这种情况下使用 Ably Realtime 等数据流网络将是一个不错的选择。

WebSockets, Pub/Sub, and all issues related to scaling 上有一篇不错的文章，我建议您阅读。

全面披露：我是 Ably 的开发者倡导者，但我希望这能真正回答您的问题。