面向服务的体系结构-AMQP或HTTP

有点背景

非常大的单片Django应用程序。所有组件都使用相同的数据库。我们需要分离服务，以便能够独立升级系统的某些部分，而不影响其余部分

我们使用RabbitMQ作为芹菜的中间商

现在我们有两个选择：

HTTP服务使用REST接口

将AMQP上的JSONRPC连接到事件循环服务

我的团队倾向于HTTP，因为这是他们所熟悉的，但我认为使用RPC优于AMQP的优势远远超过了它

AMQP为我们提供了轻松添加负载平衡和高可用性的能力，并保证了消息的传递

而对于HTTP，我们必须创建客户端HTTP包装器来处理REST接口，我们必须安装负载平衡器并设置基础设施，以便拥有HA等

使用AMQP，我可以生成服务的另一个实例，它将连接到与其他实例相同的队列以及bam、HA和负载平衡

我对AMQP的想法有什么遗漏吗？

一开始

• REST、RPC体系结构模式、AMQP-wire级别和HTTP-application协议，它们运行在TCP/IP之上
• 当HTTP是通用协议时，AMQP是一个特定的协议，因此，HTTP与AMQP相比具有极高的开销
• AMQP性质是异步的，其中HTTP性质是同步的
• REST和RPC都使用数据序列化，数据序列化的格式由您决定，具体取决于基础结构。如果您在任何地方都使用python，我认为您可以使用python本机序列化-

  pickle

  ，它应该比JSON或任何其他格式更快
• HTTP+REST和AMQP+RPC都可以在异构和/或分布式环境中运行

因此，如果您选择使用什么：HTTP+REST或AMQP+RPC，答案实际上取决于基础设施的复杂性和资源使用情况。没有任何特定的需求，这两种解决方案都可以很好地工作，但我更愿意进行一些抽象，以便能够透明地在它们之间切换

您告知您的团队熟悉HTTP，但不熟悉AMQP。如果开发时间是一个重要的时间，你会得到一个答案

如果您想以最小的复杂性构建HA基础设施，我想AMQP协议就是您想要的

我对这两种服务都有经验，RESTful服务的优势是：

• 它们很好地映射到web界面上
• 人们对他们很熟悉
• 易于调试（由于HTTP的通用性）
• 轻松为第三方服务提供API

基于AMQP的解决方案的优势：

• 他妈的快
• 灵活的
• 成本效益（在资源使用意义上）

注意，您可以在基于AMQP的API之上向第三方服务提供RESTful API，而REST不是一个协议，而是一个范例，但是您应该考虑构建AQMP RPC API。我这样做是为了向外部第三方服务提供API，并为在旧代码库上运行或无法添加AMQP支持的基础设施部分提供API访问

如果我是对的，您的问题是如何更好地组织软件不同部分之间的通信，而不是如何向最终用户提供API

如果您有一个高负载项目，RabbitMQ是一个非常好的软件，您可以轻松地添加在不同机器上运行的任意数量的工作人员。此外，它还具有现成的镜像和群集功能。还有一件事，RabbitMQ构建在Erlang OTP之上，这是一个高可靠性、稳定的平台。。。这不仅对市场营销有好处，对工程师也有好处。当nginx日志占用运行RabbitMQ的同一分区上的所有磁盘空间时，我只遇到过一次RabbitMQ问题

UPD（2018年5月）： 发布了2012年6月7日Arnold Shoon撰写的文章的链接，以下是该文章的副本：

我在浏览我的旧文件时，偶然发现了我关于MQ的笔记，并认为我应该分享一些使用MQ与HTTP的原因：

• 如果您的使用者以固定速率处理进程（即无法处理HTTP服务器的洪水[突发]），则使用MQ为服务提供了缓冲其他请求的灵活性，而不是使其陷入困境
• 与时间无关的处理和消息传递交换模式——如果线程正在执行一个fire-and-forget，那么MQ比HTTP更适合该模式
• 长寿命进程更适合MQ，因为您可以发送请求，并有一个单独的线程侦听响应（注意WS-Addressing允许HTTP以这种方式处理，但需要两个端点来支持该功能）
• 松散耦合，其中一个进程可以继续工作，即使另一个进程不可用，而HTTP必须重试
• 请求优先级排序，其中更重要的消息可以跳到队列的前面
• XA事务–MQ完全兼容XA–HTTP不兼容
• 容错性–MQ消息在服务器或网络故障下仍然有效–HTTP不能
• MQ提供了一次且仅一次的消息“有保证”传递，http没有
• MQ提供了对大型消息进行消息分段和消息分组的能力–HTTP没有这种能力，因为它单独处理每个事务
• MQ提供了一个发布/订阅接口，其中as HTTP是点对点的

UPD（2018年12月）： 正如在下面的评论中所注意到的，RabbitMQ比RESTful服务扩展得更好是值得怀疑的。我最初的答案是简单地添加更多的工作人员，这只是扩展的一部分，并且只要不超过单个AMQP代理的容量，这是真的，尽管之后它需要更先进的技术，例如，这使得基于HTTP和AMQP的服务都有一些非平凡的复杂性来扩展