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

Question

一点背景.

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

我们使用RabbitMQ作为Celery的经纪人.

现在我们有两个选择:

1. 使用REST接口的HTTP服务.
2. JSONRPC over AMQP到事件循环服务

我的团队倾向于HTTP,因为这是他们熟悉的,但我认为使用RPC而不是AMQP的优势远大于它.

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

而使用HTTP我们必须创建客户端HTTP包装器以使用REST接口,我们必须放入负载平衡器并设置该基础结构以便具有HA等.

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

我对AMQP的看法是否遗漏了什么？

Answer 1

首先,

• REST,RPC - 架构模式,AMQP - 线路级和HTTP - 应用程序协议,运行在TCP/IP之上
• 当HTTP - 通用协议时,AMQP是一种特定的协议,因此,与AMQP相比,HTTP具有非常高的开销
• 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之上,这是一个高可靠,稳定的平台......(bla-bla-bla),它不仅适用于市场营销,也适用于工程师.当nginx日志占用RabbitMQ运行的同一分区上的所有磁盘空间时,我只遇到一次RabbitMQ问题.

UPD(2018年5月): Saurabh Bhoomkar在2012年6月7日发布了由Arnold Shoon撰写的MQ与HTTP文章的链接,这里有一份副本:

我正在查看我的旧文件并看到我关于MQ的笔记,并认为我有一些理由使用MQ与HTTP:

• 如果您的消费者以固定的速率处理(即无法处理到HTTP服务器的洪水[bursts]),那么使用MQ可以为服务提供灵活性,以缓冲其他请求,而不是将其堵塞.
• 与时间无关的处理和消息交换模式 - 如果线程正在执行即发即弃,那么MQ更适合该模式与HTTP.
• 长期存在的进程更适合MQ,因为您可以发送请求并使用单独的线程侦听响应(注意WS-Addressing允许HTTP以这种方式处理,但要求两个端点都支持该功能).
• 松散耦合,即使其他进程不可用,一个进程仍可继续工作,而HTTP必须重试.
• 请求优先级,其中更重要的消息可以跳转到队列的前面.
• XA事务 - MQ完全符合XA标准 - HTTP不是.
• 容错 - MQ消息在服务器或网络故障中存在 - HTTP不会.
• MQ只提供一次"有保证"的消息传递,而http则不提供.
• MQ提供了对大型消息进行消息分段和消息分组的能力 - HTTP没有这种能力,因为它单独处理每个事务.
• MQ提供了一个pub/sub接口,其中HTTP是点对点的.

UPD(2018年12月):正如@Kevin在下面的评论中所注意到的那样,RabbitMQ比RESTful服务更好地扩展是值得怀疑的.我最初的答案是基于简单地添加更多的工作人员,这只是扩展的一部分,只要单个AMQP代理容量没有超过,这是事实,尽管之后它需要更高级的技术,如高度可用(镜像)队列,这使得基于HTTP和AMQP的服务在基础架构级别上具有一些非平凡的复杂性.

经过深思熟虑后,我还删除了维护AMQP代理(RabbitMQ)比任何HTTP服务器都简单:原始答案是在2013年6月编写的,自那时起发生了很多变化,但主要的变化是我对这两种方法都有了更多的了解,所以我现在可以说"你的里程可能会有所不同".

另请注意,比较HTTP和AMQP在某种程度上都是苹果到橙子,所以请不要将此答案解释为您做出决定的最终指导,而是将其作为其中一个来源或作为您进一步研究的参考找出符合您特定情况的确切解决方案.

Answer 2

OP必须接受的解决方案具有讽刺意味的是,AMQP或其他MQ解决方案通常用于将呼叫者与仅HTTP服务的固有不可靠性隔离 - 提供某种程度的超时和重试逻辑以及消息持久性,因此呼叫者不会必须实现自己的HTTP绝缘代码.通过可靠的AMQP核心上的非常薄的HTTP网关或适配器层,可选择使用更可靠的客户端协议(如JSONRPC)直接访问AMQP,这通常是此方案的最佳解决方案.