RESTful v/s MQ.除保证交付之外的差异和其他关键功能

Question

好的..所以我开始研究MQ及其目的/用例等...我现有的应用程序(使用JSP等制作的Web)使用RestFUL接口与远程服务器通信并从服务器发布/接收数据.

我们经常要处理远程服务器的连接问题.同步问题总是在那里.

从我们的结束发送的消息.但是远程服务器发生故障.或相反亦然.

我遇到了MQ的事情,并发现在从远程服务器发送和接收消息时它是可靠的.

但同样,使用REST我认为对MQ的整个需求似乎有点模糊.我基本上在寻找MQ和RestFUL之间的一些差异.

我在其他博客文章中看到,随着RestFUL领域研究的不断增加,MQ的速度将逐渐放松.

我对MQ没有太多了解,所以不会发表任何评论,但肯定与RestFUL合作很有趣.

如果有人提供使用RestFUL和MQ之间的差异,将不胜感激.

Answer 1

其中一个最大的区别是REST意味着同步处理,而MQ通常是异步的.正如您已经提到的,MQ是一种将生产者和消费者分离的方式,这样他们就不必同时在线,但系统仍然可以作为一个整体运行.如果您的用例意味着低延迟响应(如具有浏览器的用户),则需要同步语义,在这种情况下,MQ只是一种不同的协议.如果延迟不是一个问题,或者只有一个方向的消息传递,MQ可能是一个非常可行的替代方案.MQ免费提供的一件事是消费者端的负载平衡(以及某种程度的HA).

REST在客户端/服务器兼容性方面更加灵活.您几乎可以在每个平台上运行REST客户端,而MQ则不是这样.我想,这就是为什么有些人声称MQ已经过时的原因.因此,MQ不适合公共API.但是,对于两个服务器系统之间的通信,MQ仍然是一个非常好的选择.REST的一个独特功能是它允许您完全模仿资源的WEB行为(超媒体),即一个资源包含对另一个的引用,依此类推.MQ不能提供类似的东西.

表现可能是另一个问题.我无法给出任何确切的数字,但MQ往往具有更高的吞吐量.

在极少数情况下,由于安全要求,客户端无法直接连接到服务器.在这种情况下,MQ几乎是将数据发送到服务器的唯一方法.

总而言之,根据经验,我会使用REST

• 对于公共API或
• 需要同步处理的地方

MQ

• 当只涉及有限数量的服务器端系统时
• 异步处理是可接受的
• REST性能还不够

Answer 2

REST和MQ都支持远程系统(和本地)之间的通信.

在REST通信中,应该运行使用者和REST服务提供者以使通信成功.这是一种点对点的沟通.

在MQ模型中,生产者和消费者不需要同时运行.生产者和消费者不直接互动.消息代理负责处理消息,持久化,等等.支持点对点和发布 - 订阅模型.在发布订阅模型中,消息可以由多个使用者使用.

这些只是区分它们的一些基本点.SO上有足够的帖子讨论REST和MQ.

Answer 3

两者都是抽象但在不同的级别上您的应用程序可以提供RESTful API,但是它将使用各种组件,其中包括消息队列.

简短和脏:RESTful声明了如何构建应用程序或组件的最佳实践,MQ用于组件之间的消息传递.

您可能会对RPC感到困惑,但在Web上下文中它与MQ不同.