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

Question

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

但是假设应用程序 A 需要立即响应应用程序 B 上的服务，例如需要订单的配置详细信息或需要立即确认某些更新。从性能的角度来看，消息传递是正确的解决方案吗？通常客户端会连接到 Queue 上的 MoM - 然后必须空闲的监听器将接收消息并转发到服务器端处理器 - 它将处理响应并将其发送回 Queue 或 Topic 和请求客户将遵循相同的流程并将其取走。如果消息大小很大，MoM 也必须将其考虑在内。

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

Answer 1

这实际上取决于您的要求。通常，消息服务将支持以下一项或全部:

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

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

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

但反之亦然。如果您已经是一个 HTTP 可访问资源，并且您没有任何可能会建议更强大的消息传递解决方案的 super 严格要求，我不会在没有必要的地方强加一个。

如果您完全同意 tabula-rasa 并且您必须从头开始实现双方......那么......请在此处发布另一个问题并提供一些细节! :)