为什么我不应该基于 ZeroMQ 构建 Web 服务？答案

【问题标题】：Why should i not build a webservice based on ZeroMQ?为什么我不应该基于 ZeroMQ 构建 Web 服务？
【发布时间】：2012-03-19 17:50:43
【问题描述】：

我们目前正在为注册的客户端应用程序开发公共数据订阅网络服务，目前该客户端通过访问令牌使用我们的 api 数据。

因此，对于数据订阅端点，我们一直在考虑不同的方法，我们当前的方法是基于简单的 HTTP 帖子，每隔几秒发送一次给订阅给定对象中特定更改的客户端（仅当明显发生更改时） .

EX：用户创建一个新文档，订阅该特定用户订阅 (UserUploadDoc) 的所有应用都将通过 POST 收到通知。这实现起来非常简单。

但后来我们开始研究消息服务，ZeroMQ 似乎很有能力。

我可以很容易地想象一个简单的消息服务，其工作方式与医院 PA 类似，我们只是广播一些内容，然后有人收听它，

就像莎莉护士在托儿所打电话一样，莎莉护士可以来托儿所，只有她会收到完整的信息。

请确认我在这种方法上完全错误，并且应该坚持使用痛苦的 HTTP 帖子！

【问题讨论】：

这是一种奇怪的提问方式，请确认我现在评论你的问题是完全错误的

标签： php web-services api post zeromq

【解决方案1】：

ZeroMQ 是构建服务的绝佳选择，但您提到该系统有点公开。这可能是值得考虑的事情——虽然在使 ZeroMQ 对敌对连接保持稳定方面已经做了很多出色的工作，但仍然有很多工作需要在它之上添加一层以使其像典型的一样可靠网络服务器可能面对坏人。您可能还必须对加密和身份验证进行分层，这两者都是绝对可行的，但可能需要更多的工作。

如果您的服务将向外部世界开放，您可能需要考虑使用 Websockets（甚至是 Jim 建议的 HTTP/S）之类的东西，使用 Mongrel2 之类的东西提供到 ZeroMQ 的转换，然后构建您的内部使用 ZMQ 提供服务。

当然，如果我搞错了，而且服务本身不会在公共互联网上公开，那么我肯定会选择 ZeroMQ——它在几乎所有常用的应用中都非常容易使用语言，并且您可以应用一些简单的模式来增加适当的可靠性级别（有关详细信息，请参阅http://zguide.zero.mq 的指南）。

【讨论】：

【解决方案2】：

消息队列对于这种情况来说是一个好主意，因为它增加了有保证的交付以及在出现问题时的审计跟踪。例如，您有可能查明特定客户端是否在特定时间无法获取消息，或者回退消息队列并重放它以测试客户端。正如其他帖子所指出的那样，它确实增加了额外的开销，因此这实际上取决于在您的特定情况下这种权衡是否值得进行成本效益分析。

一般来说，我会说，如果由于任何原因导致消息无法通过会导致严重问题（在医院，我怀疑它会），那么您应该有一个消息代理。如果您不通过 POST 使用推送，则可能由客户端来继续轮询服务器的 REST 接口，直到它得到更新，所以这无关紧要，因为用户会看到“无法更新”消息并可以采取行动.只要您对 ZeroMQ 易于维护/便宜到足以维护感到高兴，我会说去吧。

【讨论】：

【解决方案3】：

我不认为在这种情况下采用 ZeroMQ 是对还是错。我认为您需要考虑的因素是

客户端（所有应用程序）需要将 ZeroMQ 接口集成为订阅者而不是更标准的 HTTP 方法时的成本是多少。
MQ 代理为消息提供临时存储和管理，以确保消息可以在生产者（发送者）和消费者（接收者）之间成功传递，例如持久模式。因此，空间、时间、管理成本会更高，但可靠性更高。
您仍然可以将 HTTP 接口与 ZeroMQ 与额外的代理层集成，以在 ZeroMQ 消费者和实际客户端之间进行交互。例如，客户端向 ZeroMQ 消费者代理发送订阅 HTTP 消息，然后将 ZeroMQ 消费者代理“下标”给 ZeroMQ 生产者，一次 ZeroMQ 消费者代理收到广播消息，它仍然会向实际客户端发送 HTTP POST。最后，它具有某种消息管理，例如发布者-订阅者模型，并且仍然是广播器和客户端上的简单 HTTP 接口。

只是一些想法。

【讨论】：