为什么我不应该基于ZeroMQ构建Web服务?

时间:2012-03-01 08:18:59

标签: php web-services api post zeromq

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

因此,对于数据订阅端点,我们一直在考虑不同的方法,我们当前的方法基于简单的HTTP Posts,每隔几秒钟就会为订阅特定对象的特定更改的客户端发送(仅当明显发生更改时) 。

EX:用户创建一个新文档,订阅该特定用户订阅的所有应用程序(UserUploadDoc)将通过POST通知。这很容易实现。

但后来我们开始调查消息传递服务,而ZeroMQ似乎非常有能力。

我可以轻松地想象一个简单的消息服务,其工作方式与医院PA类似,我们只是播放一些东西,有人听它就可以了,

就像护士Sally在幼儿园打电话一样,护士Sally可以来到幼儿园,只有她会收到完整的信息。

请确认我在这种方法上完全错了,应该坚持使用HTTP Posts的痛苦!

3 个答案:

答案 0 :(得分:8)

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

一般来说,如果由于任何原因导致消息失败将导致严重问题(在医院,我怀疑它会),那么你应该有一个消息经纪人。如果您没有通过POST使用push,那么可能由客户端决定是否继续轮询服务器的REST接口,直到它获得更新,因此这无关紧要,因为用户会看到“无法更新”消息并可能采取措施。只要你很高兴ZeroMQ能够轻松/便宜地维护,我会说它去吧。

答案 1 :(得分:4)

我不认为在这种情况下调整ZeroMQ是对的还是错的。 我认为你需要考虑的因素是

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

只是一些想法。

答案 2 :(得分:3)

ZeroMQ是构建服务的绝佳选择,但您提到该系统在某种程度上是公开的。这可能是值得考虑的事情 - 虽然在使ZeroMQ稳定到恶意连接方面已经做了很多很好的工作,但仍然有很多工作可以让你的层顶层使它像一个典型的一样可靠网络服务器可能面对坏人。您可能还必须对加密和身份验证进行分层,这两者都是绝对可行的,但可能需要更多工作。

如果您的服务对外开放,您可能需要考虑使用Websockets(甚至是Jim建议的HTTP / S)之类的东西,例如Mongrel2提供ZeroMQ的翻译,然后构建你的内部ZMQ的服务。

当然,如果我有错误的结束并且服务本身不会是公共互联网类型的公共,那么我肯定会使用ZeroMQ - 它几乎在所有常用的设备中都很容易使用语言,您可以应用一些简单的模式来添加适当的可靠性级别(有关详细信息,请参阅http://zguide.zero.mq指南)。