我们目前正在为注册的客户端应用程序开发公共数据订阅Web服务，目前这些客户端通过访问令牌使用我们的api数据。
因此，对于数据订阅端点，我们一直在考虑不同的方法，我们目前的方法是基于每隔几秒钟向订阅给定对象中特定更改的客户端发送一次简单的HTTP帖子（只有在明显发生更改时）。
例如：用户创建了一个新的文档，所有订阅了该特定用户订阅（UserUploadDoc）的应用程序都将通过POST得到通知。这真的很容易实现。
但后来我们开始研究消息服务，ZeroMQ似乎很有能力。
我可以很容易地想象一个简单的消息服务以类似于医院PA的方式工作，在那里我们只是广播一些东西，然后有人听到它，
就像莎莉护士在托儿所接到电话一样，莎莉护士可以来托儿所，只有她才会收到完整的信息。
请确认，我在这种方法上完全错了，可能应该坚持痛苦的HTTP帖子！
对于这种情况，消息队列是一个很好的主意，因为它添加了有保证的交付以及在出现问题时的审计跟踪。例如，您有可能发现特定客户端是否在特定时间无法获取消息，或者倒带消息队列并重播以测试客户端。正如其他帖子所指出的那样，这确实增加了额外的开销，所以这实际上取决于成本效益分析，即在你的特定情况下，这种权衡是否值得。
一般来说，我会说，如果消息因任何原因无法通过会导致严重问题（在医院，我怀疑会），那么你应该有一个消息代理。如果您没有通过POST使用推送，那么客户端可能会一直轮询服务器的REST接口，直到它得到更新，所以这无关紧要，因为用户会看到"无法更新"的消息，并可以采取行动。只要你对ZeroMQ的维护足够简单/便宜感到高兴，我就说去做吧。
我不认为在这种情况下调整ZeroMQ是对是错。我认为你需要考虑的因素是
- 当客户端（所有应用程序）需要将ZeroMQ接口集成为订阅者而不是更标准的HTTP方法时，成本是多少
- MQ代理为消息提供临时存储和管理，以确保消息能够在生产者（发送方）和消费者（接收方）之间成功传递，例如持久模式。因此，在空间、时间、管理方面会有更多的成本，但可靠性会更高
- 您仍然可以将HTTP接口与ZeroMQ集成，并添加一层代理，以便在ZeroMQ消费者和实际客户端之间进行交互。例如，客户端向ZeroMQ使用者代理发送一条订阅HTTP消息，然后向ZeroMQ生产者发送一次ZeroMQ使用者代理"下标"ZeroMQ消费者代理收到广播消息，它仍然会向实际客户端发送HTTPPOST。最后，它有一种消息管理，比如发布者-订阅者模型，并且在广播公司和客户端上仍然是简单的HTTP接口
只是一些想法。
ZeroMQ是构建服务的一个不错的选择，但您提到该系统在某种程度上是公共的。这可能是一件值得考虑的事情——尽管在使ZeroMQ对恶意连接保持稳定方面已经做了很多伟大的工作，但仍有很多工作要做，你可能需要在它上面加上一层，使它在面对坏人时像典型的Web服务器一样可靠。您可能还需要对加密和身份验证进行分层，这两者都是绝对可行的，但可能需要做更多的工作。
如果您的服务将对外部世界开放，您可能需要考虑使用类似Websockets的东西（甚至像Jim建议的HTTP/S），由类似Mongrel2的东西提供ZeroMQ的翻译，然后使用ZMQ构建您的内部服务。
当然，如果我说错了方向，而且服务本身不会在公共互联网类型的公共上，那么我肯定会选择ZeroMQ——它在几乎所有常用的语言中都很容易使用，并且可以应用一些简单的模式来添加适当的可靠性级别（请参阅http://zguide.zero.mq详细信息）。