何时使用 JMS，何时使用 REST？ [关闭]答案

【问题标题】：When to use JMS and when to use REST? [closed]何时使用 JMS，何时使用 REST？ [关闭]
【发布时间】：2012-03-26 06:42:46
【问题描述】：

除了特定问题的异步/同步性质并考虑到 MOM（在本例中选择 JMS）免费提供负载平衡等其他功能之外，在选择 JMS 而不是 REST 或反之亦然？

谢谢

【问题讨论】：

这是两种不同的技术和模式......因此你的问题毫无意义。
@Nix 不要这么书呆子。从应用程序集成的角度来看，考虑基于 REST 的方法或基于 MOM 的方法是完全有效的。如果有的话，我很惊讶没有考虑 SOAP 服务。
@Nix 我可以通过使用任何一种技术来实现相同的集成，因此这个问题是完全有效的。实际上是一个很好的问题。
我认为这是一个建设性的问题，对 SO 来说很好——应该重新打开它。它有两个答案，一个有 30 票赞成，而问题本身有 20 票赞成——这对我来说似乎是建设性的。

标签： rest asynchronous jms integration synchronous

【解决方案1】：

您无法比较这两种技术。

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

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

您无法真正将 JMS 与 REST 进行比较，因为它们解决了不同的问题。

但是，如果您的问题更多的是我的 JMS 队列是否需要 REST 接口？在所有情况下，我都看到人们使用 REST 来屏蔽瘦客户端，使其免于在 JMS 中排队消息的逻辑必要性。例如。如果您有一个想要与 JMS 通信的 android 客户端，那么与将消息推送到“rest”接口然后可以转换并推送到 JMS 相比，要天真地做到这一点要困难得多。

【讨论】：

您可以使用 REST 在系统之间可靠地共享数据。 Atom 提要就是一个很好的例子。
我不是说你不能。这就是 REST 的全部目的。
"MOM Sysems/JMS 是一种设计用于在系统之间共享消息的模式。"我是说 REST 非常擅长这一点。 IMO 您可以很容易地将 JMS 与 REST 进行比较，因为它们都希望解决应用程序集成问题。您是否有一个使用 JMS 比 RESTful 方法更好地解决 anything 的示例？
@Tom Howard 您有一个将消息推送到 JMS 的传感器池，以及一个处理这些消息的消费者池。您希望每条消息只处理一次。您无法拆分消息流以使每个切片接收大致相同数量的消息，也无法确定处理哪个消息需要多长时间。您绝对可以单独使用 REST 端点来解决这个问题，但使用 JMS 会更容易。
@Tom Howard 但所有消费者都应定期轮询您的存档提要，从而产生无用的流量，JMS consulmers 可以被唤醒以处理新消息。它还取决于您的客户端技术、基于 Web 的客户端或具有本地对象图存储的富客户端。

【解决方案2】：

始终使用 REST。它是当今可用的最现代、最先进和可扩展的集成方法。负载平衡基于 REST 的服务只需使用硬件或软件 HTTP 负载平衡器即可实现，可以认为与 JMS 中的负载平衡一样免费。

MOM (Message Oriented Middleware) 不容易扩展（但可能会根据您的需要扩展得足够大）。 REST 适用于网络规模。

MOM 没有economies of scale。对于数据检索请求，每次请求特定的一条数据时，必须向服务器发送另一条消息并由服务器响应。在基于 REST 的系统中，对相同数据的请求可以由 HTTP cache 提供服务。这意味着随着请求量的增加，基于 MOM 的系统将看到服务器负载以与请求相同的速率增加。基于 REST 的系统会发现服务器负载增加的速度比请求慢。

MOM 会用保证送达的即发即弃的消息来诱惑你，只会用chain of custody problem 来咬你。

MOM 对于同步请求-回复来说很糟糕，因为它会在服务器关闭时缓慢失败（即等待超时）。当请求将失败时，您希望它快速失败。如果服务器关闭，对基于 REST 的服务的 HTTP 请求将立即失败（在 TCP 连接上）。

MOM 对于异步请求-回复消息传递很有用，但是您将面临在请求和回复之间存储状态的位置的问题（提示：您的选项是 File or Regular Database，@987654326 @ 或 NoSQL Database)。通常，额外的实现工作不值得异步性的感知优势。如果您确实需要，基于 REST 的服务也支持异步请求。 202 Accepted 在这种情况下是你的朋友。

最后，缓存的使用允许基于 REST 的系统实现基于拉取的集成，这更容易支持。例如，假设我们想将数据从系统 A 移动到系统 B。MOM 方法是将消息从 A 发送到 B。基于 REST 的方法是在 A 中创建数据馈送服务（如 RSS 馈送） B 轮询新数据（与您的 RSS 阅读器轮询新文章的方式相同）。当 B 发生故障时，在 MOM 示例中，支持团队将需要监视消息队列以确保它们不会溢出，而其他人则可以备份 B。在 REST 示例中，支持团队只需要担心 B 的备份。 A失败时没有太大区别。在 MOM 示例中，B 不知道也不关心。在 REST 示例中，B 确实知道 A 已关闭，但它仍然不在乎，因为当 A 关闭时，显然没有来自 A 的新数据。最初，基于拉取的集成需要接缝的轮询非常低效，但是 HTTP 缓存使这不再是问题。

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

【讨论】：

我真的很喜欢这个答案。 +1 :)
“始终使用 REST”是一个糟糕的答案。 REST 是更合适的选择当然有很多有效的情况，但也有许多其他情况下 MOM 是更好的选择。
@tonga：当您的消息传递基础设施不可用时会发生什么？对于可缓存的响应，发送方和接收方之间的 HTTP 缓存可以在接收方不可用时做出响应。否则，Circuit Breaker pattern 是一个可行（且更可取）的替代方案，特别是考虑到异步消息传递存在的监管链问题（实际上上周我不得不帮助管理另一个生产事件，因为接收器无法处理异步消息） .
@TomHoward +1 表示强烈的意见，这真的很有意义。
嗯，“始终使用 REST”有点过于笼统。这取决于，一如既往。我在股票交易领域工作，MOM 的经典用例是一个价格（例如 MSFT）需要尽快到达交易大厅的 500 个终端和系统。你是怎样做的？ UDP 多播，由更好的 MOM 支持。 REST API 意味着 500 个终端请求当前价格，每 10 毫秒一次？我认为对于所有真正的“推送计算”MOM 主题都是一个很好的架构。你永远不需要排队。