消息队列与Web服务? [英] Message Queue vs. Web Services?
问题描述
在什么情况下，人们希望应用程序通过消息队列而不是通过Web服务(我只是指XML或JSON或YAML或此处通过HTTP进行的通讯，而不是任何特定类型)进行通话?
Under what conditions would one favor apps talking via a message queue instead of via web services (I just mean XML or JSON or YAML or whatever over HTTP here, not any particular type)?
我必须在本地网络上的两个应用程序之间进行交谈.一个将是Web应用程序，并且必须在另一个应用程序(在不同的硬件上运行)上请求命令.这些请求包括创建用户，四处移动文件以及创建目录之类的事情.在什么条件下，我更喜欢XML Web Services(或直接TCP或其他)而不是使用消息队列?
I have to talk between two apps on a local network. One will be a web app and have to request commands on another app (running on different hardware). The requests are things like creating users, moving files around, and creating directories. Under what conditions would I prefer XML Web Services (or straight TCP or something) to using a Message queue?
Web应用程序是Ruby on Rails，但我认为问题比这更广泛.
The web app is Ruby on Rails, but I think the question is broader than that.
推荐答案
使用Web服务时，您有一个客户端和一个服务器:
When you use a web service you have a client and a server:
- 如果服务器发生故障，客户端必须负责处理错误.
- 服务器再次工作时，客户端负责重新发送它.
- 如果服务器对呼叫做出响应，而客户端失败，则操作将丢失.
- 您没有争执，那就是:如果数百万的客户在一秒钟内在一台服务器上调用了Web服务，那么您的服务器很可能会宕机.
- 您可以期望服务器立即做出响应，但是您也可以处理异步调用.
当您使用RabbitMQ，Beanstalkd，ActiveMQ，IBM MQ系列，Tuxedo之类的消息队列时，您会期望得到不同且容错性更高的结果:
When you use a message queue like RabbitMQ, Beanstalkd, ActiveMQ, IBM MQ Series, Tuxedo you expect different and more fault tolerant results:
- 如果服务器发生故障，队列将保留该消息(可选，即使计算机关闭).
- 服务器再次工作时，它会接收待处理的消息.
- 如果服务器对呼叫做出响应并且客户端失败，则如果客户端不确认该响应，则消息将持续存在.
- 您有争执，可以确定服务器处理了多少个请求(取而代之的是工作程序).
- 您不希望立即得到同步响应，但是您可以实现/模拟同步调用.
Message Queues具有更多功能，但这是决定是否要自己处理错误条件或将其留在消息队列中的一些经验法则.
Message Queues has a lot more features but this is some rule of thumb to decide if you want to handle error conditions yourself or leave them to the message queue.
这篇关于消息队列与Web服务?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
