消息队列与Web服务?[关闭]

使用Web服务时,您有一个客户端和一个服务器:

1. 如果服务器出现故障,客户端必须负责处理该错误。
2. 当服务器再次工作时,客户端负责重新发送它。
3. 如果服务器对调用作出响应,而客户端失败,则操作将丢失。
4. 您没有争用,也就是说:如果一百万个客户机在一秒钟内调用一个服务器上的web服务,那么您的服务器很可能会宕机。
5. 您可以期望服务器立即响应,但也可以处理异步调用。

当您使用诸如rabbitmq、beanstalkd、activemq、ibm mq series、tuxe之类的消息队列时,您是否希望得到不同且更具容错性的结果:

1. 如果服务器失败,队列将保留消息(即使机器关闭也是可选的)。
2. 当服务器再次工作时,它将接收挂起的消息。
3. 如果服务器对调用作出响应,而客户端失败,则如果客户端未确认响应,则消息将被持久化。
4. 如果存在争用,可以决定服务器处理了多少请求(改为调用worker)。
5. 您不希望立即得到同步响应,但可以实现/模拟同步调用。

消息队列有很多特性,但这是一个经验法则,可以用来决定是要自己处理错误条件,还是让它们留在消息队列中。

最近有大量的研究在考虑rest http调用如何取代消息队列概念。

如果将流程和任务的概念作为资源引入,则对中间消息传递层的需求开始消失。

前任:

POST /task/name
    - Returns a 202 accepted status immediately
    - Returns a resource url for the created task: /task/name/X
    - Returns a resource url for the started process: /process/Y

GET /process/Y
    - Returns status of ongoing process

一个任务可以有多个初始化步骤,一个进程可以在轮询时返回状态,或者在完成时发送到回调url。

这非常简单,当您意识到您现在可以订阅所有正在运行的进程和任务的rss/atom提要而无需任何中间层时,它就变得非常强大。不管怎样,任何排队系统都需要某种Web前端,这个概念使它不需要另一层自定义代码就可以构建起来。

您的资源一直存在,直到您删除它们,这意味着您可以在流程和任务完成后很长时间内查看历史信息。

您已经内置了服务发现功能,即使对于一个包含多个步骤的任务,也没有任何额外的复杂协议。

GET /task/name
    - returns form with required fields

POST (URL provided form's "action" attribute)

您的服务发现是一个HTML表单-一种通用的、人类可读的格式。

整个流程可以通过编程方式使用,也可以由人使用普遍接受的工具使用。它是客户端驱动的,因此是restful。为web创建的每个工具都可以驱动您的业务流程。通过异步发布到单独的日志服务器阵列,您仍然有备用的消息通道。

经过一段时间的考虑之后,您可以坐下来开始意识到rest可能会完全消除对消息队列和esb的需求。

http://www.infoq.com/presentations/BPM-with-REST

消息队列是处理可能需要很长时间的请求的理想选择。请求是排队的,可以脱机处理而不阻塞客户端。如果需要通知客户机完成,您可以提供一种方法,让客户机定期检查请求的状态。

消息队列还允许您更好地跨时间扩展。它提高了处理大量活动的能力,因为实际的处理可以跨时间分布。

注意,消息队列和web服务是正交的概念,即它们不是互斥的。例如,您可以拥有一个基于xml的web服务,它充当消息队列的接口。我认为您要寻找的区别是消息队列与请求/响应,后者是在同步处理请求时。

消息队列是异步的,如果传递失败,可以重试多次。如果请求者不需要等待响应,请使用消息队列。

“web服务”这个短语让我想到了通过http对分布式组件的同步调用。如果请求者需要返回响应,请使用web服务。

我认为,一般来说,您需要一个web服务来执行一个阻塞任务(在执行更多代码之前需要完成这些任务),以及一个消息队列来执行一个非阻塞任务(可能需要很长时间,但我们不需要等待)。