某些中间件本身支持websockets，例如HiveMQ：http://www.hivemq.com/mqtt-over-websockets-with-hivemq/。使用websockets API作为中间件的第一类客户端，而不是通过支持特定于语言的API的中间服务器来路由请求，这给开发人员带来了哪些优势，例如。
客户 - ＆gt;中间件
VS
客户 - ＆gt;服务器 - ＆gt;中间件
例如，我们可以说跳过中间服务器会降低带宽成本，而不需要开发人员编写额外的层，本机SSL websockets支持？
通过为中间件提供websockets支持，不仅可以为开发人员提供哪些其他优势，还可以为任何一方提供哪些优势？
答案 0 :(得分：2)
您获得的主要优势是简单，如果是HiveMQ，可扩展性。
让我解释一下这些优点：
如果是HiveMQ，你只需启动服务器就可以了。通过websockets使用MQTT库的所有Web应用程序都可以连接到服务器，甚至不知道使用websockets作为传输。对于HiveMQ本身，它只是另一个MQTT客户端。因此，无论客户端是通过websockets还是通过经典的TCP连接进行连接，都无关紧要。我想你已经在你的问题中提到了其他论点。当然，最后但并非最不重要的是，操作人员会感谢你，如果他们有一个系统（在你的情况下，“服务器”）维护较少。
像HiveMQ这样的软件具有很高的可扩展性，可以处理多达数十万个并发连接的客户端。机会很高，附加层（在您的情况下为“服务器”）可能会引入瓶颈。此外，如果您可以丢弃不需要的图层，那么使用HW或SW负载平衡器进行负载平衡等操作会变得更加容易。一般而言，如果您不需要这些额外的层（不服务，可以重复用于其他应用程序，如微服务），您的系统架构将变得更加容易。
最后但并非最不重要的是值得注意的是，HiveMQ本身经常与经典中间件/ ESB集成。这意味着，人们编写自定义插件，将HiveMQ集成到现有的中间件中。 JMS或Web服务调用（REST，SOAP）通常用于执行此操作。
为了解决HiveMQ问题而采取了一些解决方案： - ）