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

Question

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

谢谢

Answer 1

始终使用 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 、 Message 或 NoSQL Database )。通常，额外的实现工作并不值得异步性的优势。如果您确实需要的话，基于 REST 的服务也支持异步请求。在这种情况下，202 Accepted 是你的 friend 。

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

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