消息传递是请求/回复的良好实现吗

Question

JMS 或消息传递非常适合捆绑不同的应用程序并形成许多 ESB 和 SOA 架构的基础架构。

但是说应用程序 A 需要应用程序 B 上的服务立即响应，例如需要订单的供应详细信息或需要立即确认某些更新。从性能的角度来看，消息传递是否是正确的解决方案？通常，客户端将连接到队列上的 MoM - 然后必须空闲的侦听器将拾取消息并转发到服务器端处理器 - 它将处理响应并将其发送回队列或主题和请求客户将遵循相同的过程并拿起它。如果消息很大，MoM 也必须将其考虑在内。

让我想知道 Http 是否是访问此类解决方案而不是通过消息传递路由的更好解决方案？我已经看到很多应用程序使用 MoM（如 AMQ 或 TIBCO Rvd）来实际用于即时请求/响应 - 但这是糟糕的设计还是一些微调或设置使其与 Http 相同。

Answer 1

这真的取决于您的要求。通常消息传递服务将支持以下一项或全部：

• 保证交货
• 事务性
• 持久性（即消息在传递之前一直保持，即使系统在此期间出现故障）

HTTP 连接无法 [轻松] 实现这些属性，但话又说回来，如果您不需要它们，那么我想您可以提出“simple”HTTP 会提供更简单的情况和更轻量级的解决方案。 （强调“简单”，因为一些消息传递实现将通过 HTTP 运行）。

我认为通过消息传递实现的请求/响应本身并不是糟糕的设计。我的意思是，事情是这样的......你是否在实施这个过程的两个方面？如果没有，并且您已经建立了可以响应请求的消息传递服务，除了所有其他考虑因素之外，这似乎是要走的路......并且由于某些设计概念而绕过它以使用 HTTP 重新实现将需要一些公平在我看来，这背后有很强的推理能力。

但反之亦然。如果您已经是 HTTP 可访问资源，并且您没有任何超级严格的要求可能会建议更强大的消息传递解决方案，那么我不会在没有保证的情况下强制使用它。

如果您完全使用 tabula-rasa 并且必须从头开始实施双方.....那么......在这里发布另一个问题并提供一些细节！ :)