简单协议（如twisted.pb）与消息传递（AMQP/JMS）与Web服务（REST/SOAP）
我目前正在Python上使用twisted的透视代理，并且我过去曾考虑过切换到RabbitMQ之类的东西，但我不确定它是否可以取代pb - 我觉得我可能在这里将苹果与橙子进行比较。 我最近阅读了很多有关 REST 的内容以及与 SOAP 不可避免的争论，这导致我阅读了有关“企业”Web 服务内容（如 SOA）的内容。
我即将开展一个项目，其中我需要在 Web 和桌面上实现一些类似 erp 的功能，因此我正在考虑使用哪种方法/技术在服务器和客户端之间进行通信。但我也试图尽可能多地了解所有这些，所以我不想仅仅解决这个特定的问题。
您使用什么来在服务器和客户端之间进行通信？
我知道像透视代理这样的特定于 python 的协议可能会限制我的互操作性，但是我是否可以假设某些 AMQP 协议可以取代它？
如果我没记错的话，twisted.pb 和 amqp 都使用始终在线的连接和非常低的开销协议。但一方面，始终保持大量客户端连接可能是一个问题，另一方面，即使使用 http keep-alive 以及他们在序列化部分使用的任何技巧，仍然会成为 Web 服务的问题。
如果我的任何假设是错误的，如果有人能指出我正确的方向以了解更多信息，我将不胜感激。
I'm currently using twisted's perspective broker on python and I have considered in the past switching to something like RabbitMQ but I'm not sure it could just replace pb - I feel like I might be comparing apples to oranges here.
I've been reading a lot about REST lately and the inevitable debate with SOAP, which led me to read about "enterprisey" web service stuff like SOA.
I have a project coming up in which I'll need to implement some erp-like functionality over web and desktop so I'm considering which approach/technology to use to communicate between servers and clients. But I'm also trying to learn as much as I can about all of this, so I don't want just to solve this particular problem.
What do you use for communication between your servers and clients?
I understand a python-specific protocol like perspective broker can limit my interoperability, but am I right to assume some AMQP protocol could replace it?
If I'm not mistaken, both twisted.pb and amqp use an always-on connection and a very low overhead protocol. But in one hand, keeping a large number of clients connected all the time could be a problem, and on the other hand, even with http keep-alive and whatever tricks they use the serialization part would still be a problem with web services.
If I'm wrong in any of my assumptions I would appreciate if someone could point me in the right direction to learn more.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（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 系统进行交互。
我希望这对您有用。如果您仍然对某些问题感到好奇（我认为您是这样，因为这是一个很大的区域），那么我建议您将问题分成较小的问题并单独发布。这样答案就可以更加精确。
As always, "it depends". First, let's clear up the terminology.
Twisted's Perspective Broker basically is a system you can use when you have control over both ends of a distributed action (both client and server ends). It provides a way to copy objects from one end to the other and to call methods on remote objects. Copying involves serialising the object to a format suitable for network transfer, and then transferring it using Twisted's own transfer protocol. This is useful when both ends can use Twisted, and you don't need to interface with non-Twisted systems.
Generally speaking, Web Services are client-server applications that rely on HTTP for communication. The client uses HTTP to make a request to the server, which returns a result. Parameters can be encoded in eg. GET or POST requests or use a data section in a POST request to send, for example, an XML-formatted document that describes the action to be taken.
REST is the architectural idea that all resources and operations on resources that a system exposes should be directly addressable. To put it somewhat simply, it means that the URI used to access or manipulate the resource includes the resource name and the operation to carry out on it. REST can be and commonly is implemented as a Web Service using HTTP.
SOAP is a protocol for message exchange. It consists of two parts: a choice of several transport methods, and a single XML-based message format. The transport method can be, for example, HTTP, which makes SOAP a candidate for implementing Wed Services. The message format specifies all details about the requested action and the result of the action.
JMS is an API standard for Java-based messaging systems. It defines some semantics for messages (such as one-to-one or one-to-many) and includes methods for addressing, creating messages, populating them with parameters and data, sending them, and receiving and decoding them. The API makes sure that you can, in theory, change the underlying messaging system implementation without having to rewrite all of your code. However, the message system implementation doesn't need to be protocol-compatible with another JMS-enabled messaging system. So having one JMS system doesn't automatically mean that you can exchange messages with another JMS system. You probably need to build some kind of bridge service for that to work, which is going to be a major challenge especially when it comes to addressing.
AMQP attempts to improve the situation by defining a wire protocol that messaging systems must obey. This means that messaging systems from different vendors can exchange messages.
Finally, SOA is an architecture concept where applications are broken down into reusable services. These services are then combined ("orchestrated") to implement the application. Each time a new application is made, there is a chance of reusing the existing services. SOA is also something that requires non-technical support activities so that the reuse really happens and services are designed to be general enough. Also, SOA is one way of starting to package functionality in legacy systems into a meaningful whole that can then be extended and developed further using more modern techniques. SOA can be implemented using a variety of technologies, such as Web Services, messaging systems, or an Enterprise Service Bus.
You pondered the tradeoff between one connection per request and keeping the connection open for multiple requests. This depends on available resources, the messaging pattern, and the size of your data. If the incoming message stream is constantly the same, then it could be fine to let connections stay open since their amount won't change very much. On the other hand, if there are bursts of messages from several systems, then it could be useful to release resources and not let connections linger for too long. Also, if lots of data is transferred per connection, then the overhead of opening and closing the connection is small compared to the total transaction length. On the other hand, if you transfer lots of very small messages, then keeping the connection open could prove beneficial. Benchmarking with your particular parameters is the only way to be sure.
AMQP could indeed replace the Twisted-specific protocol. This would allow interacting with a non-Twisted system.
I hope this proves useful to you. If you're still wondering about something (and I think you are, since this is such a large area) then I would suggest splitting things into smaller questions and posting them individually. The answers can then be more precise.