简单协议(如twisted.pb)与消息传递(AMQP/JMS)与Web服务(REST/SOAP)

Question

我目前在python上使用twisted的透视代理,我在过去曾考虑过切换到类似RabbitMQ的东西,但我不确定它是否可以取代pb - 我觉得我可能会在这里将苹果与橙子进行比较.我最近一直在阅读很多关于REST的内容以及与SOAP的不可避免的争论,这使我开始阅读像SOA这样的"企业级"Web服务.

我有一个项目,我需要在Web和桌面上实现一些类似erp的功能,所以我正在考虑使用哪种方法/技术在服务器和客户端之间进行通信.但我也试图尽可能多地学习所有这些,所以我不想只是解决这个特殊的问题.

您在服务器和客户端之间进行通信时使用了什么？

我理解像透视代理这样的特定于python的协议可以限制我的互操作性,但我是否正确地假设某些AMQP协议可以取代它？

如果我没弄错的话,twisted.pb和amqp都使用永远在线的连接和非常低的开销协议.但一方面,保持大量客户端始终连接可能是一个问题,另一方面,即使使用http keep-alive和他们使用的任何技巧,序列化部分仍然是Web服务的问题.

如果我在任何假设中出错,如果有人能指出我正确的方向来了解更多,我将不胜感激.

Answer 1

一如既往,"这取决于".首先,让我们清理术语.

Twisted的Perspective Broker基本上是一个系统,当你控制分布式动作的两端(客户端和服务器端)时,你可以使用它.它提供了一种将对象从一端复制到另一端并在远程对象上调用方法的方法.复制涉及将对象序列化为适合网络传输的格式,然后使用Twisted自己的传输协议进行传输.当两端都可以使用Twisted时,这很有用,并且您不需要与非Twisted系统接口.

一般而言,Web服务是依赖HTTP进行通信的客户端 - 服务器应用程序.客户端使用HTTP向服务器发出请求,返回结果.参数可以编码在例如.GET或POST请求或使用POST请求中的数据部分来发送,例如,描述要采取的操作的XML格式的文档.

REST是一种体系结构理念,系统公开的资源上的所有资源和操作都应该可以直接寻址.简单来说,这意味着用于访问或操作资源的URI包括资源名称和要执行的操作.REST可以并且通常使用HTTP实现为Web服务.

SOAP是用于消息交换的协议.它由两部分组成:可选择多种传输方法,以及一种基于XML的消息格式.传输方法可以是,例如,HTTP,它使SOAP成为实现Wed服务的候选者.消息格式指定有关请求的操作和操作结果的所有详细信息.

JMS是基于Java的消息传递系统的API标准.它定义了消息的一些语义(例如一对一或一对多),并包括用于寻址,创建消息,用参数和数据填充它们,发送它们以及接收和解码消息的方法.从理论上讲,API确保您可以更改底层的消息传递系统实现,而无需重写所有代码.但是,消息系统实现不需要与另一个启用JMS的消息传递系统协议兼容.因此,拥有一个JMS系统并不意味着您可以与另一个JMS系统交换消息.您可能需要为此工作构建某种桥接服务,这将成为一项重大挑战,尤其是在解决问题时.

AMQP尝试通过定义消息传递系统必须遵守的有线协议来改善这种情况.这意味着来自不同供应商的消息系统可以交换消息.

最后,SOA是一种架构概念,其中应用程序被分解为可重用的服务.然后组合这些服务("协调")以实现应用程序.每次创建新应用程序时,都有可能重用现有服务.SOA也需要非技术支持活动,以便重用真正发生,并且服务设计得足够通用.此外,SOA是开始将遗留系统中的功能打包成有意义的整体的一种方式,然后可以使用更现代的技术进一步扩展和开发.SOA可以使用各种技术实现,例如Web服务,消息传递系统或企业服务总线.

您考虑了每个请求之间的一个连接与保持连接打开多个请求之间的权衡.这取决于可用资源,消息传递模式和数据大小.如果传入的消息流始终相同,那么让连接保持打开状态可能会很好,因为它们的数量不会发生太大变化.另一方面,如果有来自多个系统的消息突发,那么释放资源并不让连接延迟太久可能是有用的.此外,如果每个连接传输大量数据,则与总事务长度相比,打开和关闭连接的开销很小.另一方面,如果您传输大量非常小的消息,那么保持连接打开可能会有益.

AMQP确实可以取代特定于Twisted的协议.这将允许与非Twisted系统进行交互.

我希望这证明对你有用.如果你仍然想知道什么(我认为你是,因为这是一个如此大的区域),那么我建议将事情分成小问题并单独发布.答案可以更精确.