我想开发一个带有1个发布者的订阅者模型，在nodejs中开发了许多订户。
目前，我的想法是使用普通的Websocket。问题在于，每个订户都需要静态IP 和端口转发，如果它通过Internet运行。这不适合要求。
解决方案似乎是MQTT，因为它应该适合该用例，但是我看到它也可以通过Websockets运行，该Websockets应该导致相同的问题，或者MQTT是否以不同的方式处理它？
本质上，我需要一个解决方案，在该解决方案中，发布者具有静态IP，并且订户可以在世界任何地方。MQTT是否可以使用，还是我需要其他解决方案？
否，只有MQTT经纪人需要固定的IP地址（最好是DNS条目），以便客户知道在哪里找到它。
所有MQTT客户端（订户和发布者），无论是本机MQTT还是Websockets上的MQTT，都将连接到经纪人。这意味着它们甚至在使用动态IP地址运行的NAT路由器后面工作（每当IP地址更改时都会断开连接，但几乎所有MQTT客户端都会自动重新连接）。
这些功能使MQTT成为消费者IoT设备的好选择，因为上述情况几乎是每个家庭宽带设置。
听起来您的订阅设备在本地网络上，是的，您将需要一个静态IP来进行网络和内部转发（更不用说许多系统中的防火墙异常）本地设备，用于提供传入请求。无论协议如何，您的订户都不需要是服务器。让他们查询中央服务器/系统更安全，最终更容易。只有该系统需要IP。
Websockets不需要需要端口转发 - 它们通常用于避免它。客户端打开与服务器的连接，然后继续使用它发送和接收。从网站接收页面时，它不需要端口转发。如果您的发布者是服务器或其他曝光系统，则可以通过配置订户为其打开Websocket来完成工作。
但是，您可能仍然需要mqtt：
- 听起来您的发布者可能是Web服务器以外的其他东西，并且由于您提出了这个问题，因此可能不适合您的客户服务。使用MQTT客户端，它可以发布到服务器上的MQTT代理，然后将消息传递给订户的客户端。
- 开发强大的发布订阅功能是额外的工作，现有的MQTT软件通常会比新开发更好。
有了一些额外的配置，甚至可以通过WebSockets进行MQTT订阅，但即使是常规订阅，也可以避免使用静态IP，PortForwarding和Inbound Firewall规则
探索一种方法RPC方法。它将不需要公共IP地址或端口转发。