3

我正在开发一个使用 SOA 风格实现的实时应用程序（读取通过一些消息传递协议 - JMS、MQ 或 HTTP 连接的松散耦合组件）。

设计此系统的架构师选择使用 JMS 来连接组件。该系统是实时的，因此如果一个组件发生故障（事务将简单地超时），则无需将消息排队。此外，不需要保证交付或回滚。

在这种情况下，与 HTTP Web 服务（速度、资源占用等）相比，使用 JMS 有什么好处吗？

我在想的一件事是，由于 JMS 方法要求我们设置线程池大小（侦听 JMS 主题/队列的组件数量），因此 HTTP 服务不是更合适，因为这种额外的配置不是需要（为每个 HTTP 请求创建一个新线程，使应用程序可扩展到“无限”数量的请求，直到服务器耗尽资源）。

我错过了什么吗？

4

5 回答 5

2

我完全不同意 S.Lott 提出的观点，但这里有几点需要考虑关于 HTTP Web 服务：

  • 您的客户只需要知道如何通过 HTTP 进行通信——几乎所有现代语言都以一种或另一种形式很好地支持这种协议。JMS 虽然很受欢迎，但比 HTTP 更专业，因此限制了您的互连系统可以使用的语言。也许目前对您的系统来说不是问题，但您是否需要稍后插入其他可能难以支持 JMS 连接的系统？

  • 许多语言都很好地支持您可以为您的服务使用的 WSDL 和 SOAP 等标准，并且有很多工具可以生成代码来从 WSDL 文件为您实现管道的两端（客户端和服务器），从而减少你必须做的开发量。这些标准还使得定义和发布您将在系统之间传递的数据规范变得相对简单，您可能必须使用 JMS 等排队技术手动完成这些操作。

  • 不利的一面是，正如 S.Lott 所指出的，JMS 为您提供了使用（无状态）HTTP 协议丢弃的功能：保证排序和可靠性；监测；可扩展性；等等。你确定你不需要这些，也不需要这些吗？

好问题，顺便说一句。

于 2008-10-28T22:46:45.510 回答
2

我认为这真的取决于情况。在我工作的地方，我们支持 Remoting、JMS、MQ、HTTP 和 sFTP。我们正在实现一个使用 Remoting、JMS、MQ 和 HTTP 的中间件设备，以及一个使用 JMS、MQ 和 HTTP 的软件中间件组件。

正如上面提到的 sgreeve，标准帮助我们变得灵活，但专有格式允许更多功能。

简而言之，我会说将 HTTP 用于无状态调用（最终可以满足您几乎所有的需求）以及有状态调用所需的任何专有格式。如果您在大型企业工作，硬件设备通常非常适合作为中间件：闪电般的快速压缩、加密、转换和翻译，总拥有成本非常低。

于 2008-10-29T17:21:31.203 回答
1

我不太了解您的要求，但您可能忽略了可管理性、灵活性和性能。

JMS 允许您监视和管理队列。这些是 HTTP 缺乏的功能，您必须构建而不是从供应商处购买。

此外，JMS 中有队列和主题，允许多个订阅者到一个发布者。在 HTTP 中不可能。

虽然在 1.0 版中您可能不需要这些东西，但您将来可能需要它们。

此外，JMS 可能能够使用其他传输机制，如命名套接字，如果没有（几乎）每个请求都进行所有套接字协商，则可以减少开销。

于 2008-10-28T19:53:29.010 回答
1

如果您使用 HTTP 路由并且想要支持多台机器或某种可靠性 - 您将需要一个能够发现可用 Web 服务器并在它们之间加载请求的负载均衡器 - 然后故障转移到另一台 Web 服务器如果一个特定的盒子/进程死亡。发出 HTTP 请求的客户端也将不得不处理服务器失败并在某些循环中重试操作。

这是消息队列的主要特性之一 - 可靠的负载平衡与故障转移和生产者和消费者之间的松散耦合，而不必包含重试逻辑 - 因此您的客户端或服务器代码不必担心这种事情。这与您是否想要消息持久性或想要使用 ACID 事务来生成/使用消息完全不同（顺便说一句，这可能非常方便）。

如果您只关注使用 Java 的服务器端 - 无论是 Servlet 还是 MessageListener/MDB，它们实际上都有点相似。不同之处在于负载均衡器。

所以也许问题真的应该是 - JMS 代理是否比设置 DNS/NAT/IP/HTTP 负载平衡器基础设施更容易设置和使用？

于 2008-10-29T08:26:06.823 回答
1

我想这取决于你所说的实时是什么意思……在我看来，JMS 和 HTTP 都不能很好地支持“实时”应用程序，这意味着它们不能提供可预测/确定性的性能，也不能在存在争用的情况下正确地优先处理流。

部分原因是这些技术是建立在 TCP 之上的，它将所有流量序列化到一个 FIFO 中，这意味着不同的流量不能轻易区分优先级。此外，TCP 计时器不容易控制，从而导致不可预测的阻塞和超时……因此，许多流应用程序使用 UDP 而不是 TCP 作为底层协议。

JMS 的另一个问题是典型的实现使用集中消息分发的代理。这不是获得确定性性能的最佳架构。

如果您正在寻找可以为您提供 JMS 获得的可靠性保证和发布-订阅语义的中间件，但它是为适应实时应用程序域而开发的，我建议您查看 OMG 数据分发服务(DDS)。请参阅 dds.omg.org 和我写的这篇文章，讨论为什么 DDS 是实现实时 SOA 的最佳中间件。http://soa.sys-con.com/node/467488

于 2010-11-17T07:10:39.900 回答