2

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

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

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

4

1 回答 1

2

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

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

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

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

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

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

于 2013-02-26T22:22:52.053 回答