面向服务的架构 - AMQP 或 HTTP答案

【问题标题】：Service Oriented Architecture - AMQP or HTTP面向服务的架构 - AMQP 或 HTTP
【发布时间】：2013-05-26 03:52:09
【问题描述】：

一点背景。

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

我们使用 RabbitMQ 作为 Celery 的代理。

现在我们有两个选择：

使用 REST 接口的 HTTP 服务。
通过 AMQP 的 JSONRPC 到事件循环服务

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

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

而对于 HTTP，我们必须创建客户端 HTTP 包装器以使用 REST 接口，我们必须放入负载平衡器并设置该基础架构以实现 HA 等。

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

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

【问题讨论】：

标签： http rabbitmq soa scaling amqp

【解决方案1】：

一开始，

REST、RPC - 架构模式、AMQP - 线路级和 HTTP - 在 TCP/IP 之上运行的应用程序协议
AMQP 是 HTTP 时的特定协议 - 通用协议，因此，与 AMQP 相比，HTTP 的开销非常高
AMQP 本质是异步的，而 HTTP 本质是同步的
REST 和 RPC 都使用数据序列化，哪种格式取决于您并且取决于基础设施。如果您在任何地方都使用 python，我认为您可以使用 python 原生序列化 - pickle，它应该比 JSON 或任何其他格式更快。
HTTP+REST 和 AMQP+RPC 都可以在异构和/或分布式环境中运行

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

您告诉您的团队熟悉 HTTP 但不熟悉 AMQP。如果开发时间很重要，您就会得到答案。

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

我对它们都有过体验，RESTful 服务的优点是：

它们在网络界面上得到了很好的映射
人们对它们很熟悉
易于调试（由于 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 发布了 Arnold Shoon 于 2012 年 6 月 7 日撰写的 MQ vs. HTTP 文章的链接，这是它的副本：

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

如果您的消费者以固定速率处理（即无法处理对 HTTP 服务器 [突发] 的洪水），那么使用 MQ 可以让服务灵活地缓冲其他请求，而不是让它陷入困境。

与时间无关的处理和消息交换模式 - 如果线程正在执行即发即弃，则 MQ 比 HTTP 更适合该模式。

长寿命进程更适合 MQ，因为您可以发送请求并让单独的线程监听响应（注意 WS-Addressing 允许 HTTP 以这种方式处理，但需要两个端点都支持该功能）。李>

松散耦合，一个进程可以继续工作，即使另一个进程不可用，而 HTTP 必须重试。

请求优先级，更重要的消息可以跳到队列的前面。

XA 事务 – MQ 完全符合 XA – HTTP 不符合。

容错 - MQ 消息在服务器或网络故障时仍然存在 - HTTP 不能。

MQ 只提供一次“可靠”的消息传递，而 http 没有。

MQ 提供了对大型消息进行消息分段和消息分组的能力 - HTTP 没有这种能力，因为它单独处理每个事务。

MQ 提供了一个发布/订阅接口，其中 HTTP 是点对点的。

UPD（2018 年 12 月）：正如下面 cmets 中的 @Kevin 所注意到的，RabbitMQ 的扩展性优于 RESTful 服务是值得怀疑的。我最初的答案是基于简单地添加更多工作人员，这只是扩展的一部分，只要不超过单个 AMQP 代理容量，这是真的，尽管之后它需要更高级的技术，如 Highly Available (Mirrored) Queues，这使得 HTTP 和基于 AMQP 的服务在基础架构级别进行扩展时具有一定的复杂性。

经过仔细考虑，我还删除了维护 AMQP 代理 (RabbitMQ) 比任何 HTTP 服务器都简单：原始答案写于 2013 年 6 月，自那时以来发生了很多变化，但主要变化是我对两种方法，所以我现在能说的最好的就是“你的里程可能会有所不同”。

另请注意，在某种程度上比较 HTTP 和 AMQP 是苹果与橙子的区别，因此请不要将此答案解释为您做出决定的最终指导，而应将其作为来源之一或作为参考您的进一步研究，以找出与您的特定情况相匹配的确切解决方案。

【讨论】：

我们最终选择了 HTTP/REST。我真的很想走 AMQP 路线，因为它非常适合我们的架构，但我的团队不想尝试新的东西，所以这很糟糕。使用 HTTP 而不是 AMQP 和 RPC 开发一个冗余且高度可用的 SOA 系统需要做更多的工作。
@pinepain 我认为需要提及的一件事（如果我错了，请纠正我）是，使用 AMQP，您实际上可以将消息推送到您无法使用 HTTP 的目的地（使用请求-响应方法）
@rayman HTTP 和 AMQP 是不同的概念，所以我不想使用这样的标准进行比较。
@rayman 确切地说，AMQP 在许多因素上与 HTTP 有很大不同，比如已经提到的高级路由、连接多路复用（在 http2 中添加）等等。 HTTP、缓存、代理、方法等也是如此。我的观点是 HTTP 和 AMQP 处于不同的级别，比较它们可能就像比较汽车和火车：虽然两者都是车辆，但它们在很多方面是不同的。
从比较的角度来看这是一个很好的阅读：blogs.perficient.com/ibm/2012/06/07/mq-vs-http

【解决方案2】：

OP 不得不接受的解决方案具有讽刺意味的是，AMQP 或其他 MQ 解决方案通常用于将调用者与纯 HTTP 服务固有的不可靠性隔离开来——以提供某种程度的超时和重试逻辑以及消息持久性，因此调用者不必实现自己的 HTTP 隔离代码。在可靠的 AMQP 核心之上的非常薄的 HTTP 网关或适配器层，可以选择使用更可靠的客户端协议（如 JSONRPC）直接进入 AMQP，这通常是这种场景的最佳解决方案。

【讨论】：