何时使用JMS，何时使用REST？

Question

除了考虑特定问题的异步/同步性质之外，并且考虑到 MOM（在本例中选择 JMS）免费提供诸如负载均衡和其他功能，还有什么可以考虑选择 JMS 而不是 REST，反之亦然？

谢谢。

- jmdev

---

这是两种不同的技术和模式... 因此，你的问题毫无意义。 - Nix

@Nix，请不要显得那么卖弄学识。从应用集成的角度来看，考虑基于REST的方法或基于MOM的方法都是完全有效的。如果有什么不同的话，我会惊讶地发现SOAP服务也没有被考虑进来。 - Tom Howard

@Nix 我可以使用任何一种技术来实现相同的集成，因此这个问题是完全有效的。事实上，这是一个非常好的问题。 - Junchen Liu

我认为这是个有建设性的问题，适合在 Stack Overflow 上发布，应该重新开放。它有两个答案，其中一个获得了30个赞，问题本身也获得了20个赞，这对我来说看起来是有建设性的。 - Software Engineer

Answer 1

始终使用REST。它是当今最现代化、先进和可扩展的集成方法。基于REST的服务负载均衡可以通过硬件或软件HTTP负载均衡器轻松实现，并且可以被认为与JMS中的负载均衡一样自由。

MOM （面向消息的中间件） 不易扩展（但可能足够满足您的需求）。REST在Web规模下运作。

MOM没有经济规模。对于数据检索请求，每次请求特定数据时，都必须发送另一个消息到服务器，并由服务器做出响应。在基于REST的系统中，同一数据的请求可以由HTTP缓存提供服务。这意味着随着时间的推移，随着请求数量的增加，基于MOM的系统将看到服务器负载与请求同步增加。基于REST的系统将看到服务器负载增加速度比请求慢。

MOM会通过一次性发送消息并保证投递来诱惑您，但随之而来的是责任链问题的困扰。

对于同步请求-响应，MOM非常糟糕，因为当服务器宕机时，它会缓慢失败（即等待超时）。当请求即将失败时，您希望它能够快速失败。如果服务器宕机，基于REST的服务的HTTP请求将立即失败（在TCP连接上）。

MOM适用于异步请求-响应消息，但是您将面临请求和响应之间存储状态的问题（提示：您的选项是文件或常规数据库，消息或NoSQL数据库）。通常，额外的实现工作并不值得异步性所带来的看似优势。此外，如果您确实需要，基于REST的服务也支持异步请求。在这种情况下，202接受是您的朋友。

最后，使用缓存允许基于REST的系统实现拉式集成，这样更容易支持。例如，假设我们想将数据从系统A移动到系统B。 MOM方法是从A向B发送消息。基于REST的方法是在A中创建一个数据源服务（类似于RSS源），B轮询获取新数据（就像您的RSS阅读器轮询获取新文章）。当B失败时，在MOM示例中，支持团队需要监视消息队列以确保它们不会溢出，同时其他人使B恢复正常。在REST示例中，支持团队只需担心将B恢复正常。当A失败时，差别不大。在MOM示例中，B不知道也不关心。在REST示例中，B知道A已经停机，但仍然不关心，因为显然当A停机时没有新数据可用。最初，拉式集成需要轮询，似乎非常低效，但HTTP缓存使这成为无关紧要的问题。

换句话说，与其投资于JMS服务器，不如投资于良好的缓存HTTP负载均衡器。

- Tom Howard

---

“始终使用REST”是一个糟糕的答案。当然，在许多情况下使用REST可能更为合适，但也有很多其他情况下使用MOM可能更好。 - Paul Legato

当您的消息基础设施不可用时会发生什么？ 对于可以缓存的响应，当接收方不可用时，位于发件人和接收方之间的HTTP缓存可以作出响应。 否则，“断路器模式”是一个可行（并且更可取）的替代方案，特别是考虑到异步消息呈现的“责任链”问题（就在上周，我不得不帮助管理另一起生产事故，因为接收方无法处理异步消息）。 - Tom Howard

@TomHoward 的强烈观点非常有道理，我给他点赞。 - Firdous Amir

“始终使用REST”有些过于笼统了，这要看情况而定。我在股票交易领域工作，经典的MOM应用案例是需要尽快将一个价格（例如MSFT）发送到500个终端和交易楼层上的系统。该如何实现？UDP组播可以实现，而且更好的MOM支持它。使用REST API意味着500个终端每10毫秒请求一次当前价格吗？我认为，在所有需要实时“推送计算”的情况下，MOM话题是一个很好的架构。你永远不需要队列。 - Axel Podehl

@TomHoward，没错，我只是随机选了一个2011年的低延迟基准测试来展示我们现在的水平：每秒2.5百万条消息，平均延迟为13微秒（http://ateam.purrdigital.com/dell-touts-performance-of-its-tibco-ftl-stack/）- 我没有做过这个测试，所以无法保证其有效性... - Axel Podehl

Answer 2

这两种技术不可相提并论。

REST是一种服务/模式，为您提供了一个有组织的方式来访问无状态资源。

MOM系统/JMS是一种设计用于在系统之间共享消息的模式。它关注的是以可靠的方式输入数据和输出数据。

---

你不能真正比较JMS和REST，因为它们解决的问题不同。

---

但是如果你的问题更多地是关于是否需要为我的JMS队列提供REST接口？这完全是情况而定，我见过人们使用REST来保护客户端免受将消息排队到JMS所需的逻辑的影响。例如，如果您有一个想要与JMS通信的Android客户端，原生实现就要困难得多，相对地通过将消息推送到“rest”接口，该接口会转换并将消息推送到JMS上就容易得多了。

- Nix

---

您可以使用REST在系统之间可靠地共享数据。Atom订阅是一个完美的例子。 - Tom Howard

我并不是说你不能这样做。这正是REST的全部目的。 - Nix

MOM系统/JMS是一种模式，旨在实现系统之间的消息共享。我认为REST非常擅长这方面。在我看来，JMS和REST都致力于解决应用程序集成问题，两者可以很容易地进行比较。你有没有任何例子表明使用JMS比使用RESTful方法更好？ - Tom Howard

@Tom Howard，您拥有一组传感器，它们将消息推送到JMS，并有一组消费者处理这些消息。您希望每条消息仅被处理一次。您无法分割消息流以使每个切片接收大约相同数量的消息，也无法告诉哪条消息需要多长时间才能被处理。您绝对可以仅使用REST端点来解决此问题，但使用JMS会更容易。 - user625488

@Tom Howard，但是所有的消费者都应该定期轮询您的存档源，这会产生无用的流量。使用JMS，消费者可以被唤醒以处理新消息。这还取决于您的客户端技术，是基于Web的还是具有本地对象图存储的富客户端。 - Sébastien B.