我正在寻找一种方法，以不同语言编写的应用程序之间实现基本的发布/订阅，以与JSON负载交换事件。
WebSocket似乎是传输的显而易见的选择，但是您需要在顶部放置一个（可能很小的）层来实现一些管道：
我期望为此找到一个明显的标准，但似乎没有任何标准。
因此，每个人都在使用MQTT / WS（这需要另一个代理组件，而不是简单的服务器吗？）还是gRPC？
每个人都是从头开始重新实现它吗？ （这是一件似乎很容易做的事情之一，但是我想您最终还是得到了我所寻找的东西的半熟，指定不清，破损的版本...）
或者在通过WS从服务器提供数据流的想法上根本没有突破？
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的开发倡导者，但希望它能真正回答您的问题。