实时 SOA 应用程序的最佳消息传递媒介？
https://stackoverflow.com/questions/244494
-
05-07-2019 - |
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
Russian题
我正在开发一个使用 SOA 风格实现的实时应用程序（读取通过某种消息传递协议 - JMS、MQ 或 HTTP 连接的松散耦合组件）。
设计该系统的架构师选择使用 JMS 来连接组件。该系统是实时的，因此如果一个组件发生故障（事务将简单地超时），则无需对消息进行排队。此外，不需要保证交付或回滚。
在这种情况下，使用 JMS 相对于 HTTP Web 服务（速度、资源占用等）有什么好处吗？
我在想的一件事是，由于 JMS 方法要求我们设置线程池大小（侦听 JMS 主题/队列的组件数量），HTTP 服务不是更适合吗，因为此附加配置不是需要（为每个 HTTP 请求创建一个新线程，使应用程序可扩展到“无限”数量的请求，直到服务器耗尽资源）。
我错过了什么吗？
解决方案
我完全不同意 S.Lott 提出的观点，但以下是有关 HTTP Web 服务需要考虑的几点：
您的客户只需要知道如何通过 HTTP 进行通信 - HTTP 是几乎所有现代语言都以某种形式提供良好支持的协议。JMS 虽然很流行，但比 HTTP 更专业，因此限制了互连系统可以使用的语言。也许目前对您的系统来说不是问题，但您以后是否需要插入可能难以支持 JMS 连接的其他系统？
许多语言都很好地支持您可以在服务中使用的 WSDL 和 SOAP 等标准，并且有大量工具可以生成代码来从 WSDL 文件为您实现管道的两端（客户端和服务器），从而减少了你需要做的开发工作量。这些标准还使得定义和发布将在系统之间传递的数据规范变得相对简单，您可能必须使用 JMS 等排队技术手动完成这些操作。
缺点是，正如 S.Lott 所指出的，JMS 为您提供了使用（无状态）HTTP 协议时抛弃的功能：保证订购和可靠性；监控；可扩展性；ETC。您确定您不需要这些，并且以后也不需要这些吗？
很好的问题，顺便说一句。
其他提示
我认为这完全取决于具体情况。在我工作的地方，我们支持Remoting，JMS，MQ，HTTP和sFTP。我们正在实现一个讲中间件，JMS，MQ和HTTP的中间件设备，以及一个讲JMS，MQ和HTTP的软件中间件组件。
正如上面提到的，标准有助于我们变得灵活，但专有格式允许更多功能。
简而言之，我会说使用HTTP进行无状态调用（最终可能满足您的所有需求），以及有状态调用所需的专有格式。如果您在大型企业中工作，硬件设备通常非常适合作为中间件：Lightning快速压缩，加密，转换和翻译，总拥有成本非常低。
我对您的要求知之甚少，但您可能会忽视可管理性，灵活性和性能。
JMS允许您监视和管理队列。这些是HTTP缺乏的功能，您必须构建而不是从供应商处购买。
此外，JMS中有队列和主题，允许单个发布者拥有多个订阅者。在HTTP中不可能。
虽然您可能不需要1.0版本中的那些内容，但您将来可能会想要它们。
此外，JMS可能能够使用其他传输机制，如命名套接字，如果没有（几乎）每个请求都进行所有套接字协商，这可以减少开销。
如果您沿着HTTP路线走下去并且想要支持多台计算机或某种可靠性 - 您将需要一个能够发现可用Web服务器并在其中加载请求的负载均衡器 - 然后故障转移到另一个Web服务器，如果特定的盒子/进程死亡。发出HTTP请求的客户端也必须处理服务器失败并在某个循环中重试操作。
这是消息队列的主要功能之一 - 具有故障转移的可靠负载平衡以及生产者和消费者之间的松散耦合，而无需包含重试逻辑 - 因此您的客户端或服务器代码不必担心这一点有点儿的事。这与您是否想要消息持久性或想要使用ACID事务来生成/使用消息完全分开（这可能非常方便BTW）。
如果你只关注使用Java的服务器端 - 无论是Servlet还是MessageListener / MDB，它们都是真的有点类似。不同之处在于负载均衡器。
所以也许问题应该是 - JMS经纪人更容易设置＆amp;使用而不是设置DNS / NAT / IP / HTTP负载均衡器基础设施？
我认为这取决于你的实时意思......在我看来，JMS和HTTP都不支持“实时”。应用程序很好，这意味着它们无法提供可预测/确定性的性能，也无法在存在争用时对流进行适当的优先级排序。
部分原因是这些技术建立在TCP之上，它将所有流量序列化为单个FIFO，这意味着不能轻易地优先处理不同的流量。此外，TCP定时器不易控制，导致无法预测的阻塞和超时......因此，许多流应用程序使用UDP而不是TCP作为底层协议。
JMS的另一个问题是典型的实现使用集中消息调度的代理。这不是获得确定性性能的最佳架构。
如果您正在寻找可以为您提供JMS的可靠性保证和发布 - 订阅语义的中间件，但是我开发的中间件适合实时应用程序域，我建议您查看OMG数据 - 分发服务（DDS）。请参阅dds.omg.org和我撰写的这篇文章，争论为什么DDS是实现实时SOA的最佳中间件。 http://soa.sys-con.com/node/467488
