面向服务的体系结构 - AMQP或HTTP [英] Service Oriented Architecture - AMQP or HTTP

问题描述

一点背景。

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

Very big monolithic Django application. All components use the same database. We need to separate services so we can independently upgrade some parts of the system without affecting the rest.

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

We use RabbitMQ as a broker to Celery.

现在我们有两个选择：

1. 使用REST接口的HTTP服务。


2. 通过AMQP的JSONRPC到事件循环服务

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

My team is leaning towards HTTP because that's what they are familiar with but I think the advantages of using RPC over AMQP far outweigh it.

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

AMQP provides us with the capabilities to easily add in load balancing, and high availability, with guaranteed message deliveries.

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

Whereas with HTTP we have to create client HTTP wrappers to work with the REST interfaces, we have to put in a load balancer and set up that infrastructure in order to have HA etc.

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

With AMQP I can just spawn another instance of the service, it will connect to the same queue as the other instances and bam, HA and load balancing.

我错过了对AMQP的看法吗？

Am I missing something with my thoughts on AMQP?

推荐答案

，

• REST，RPC - 架构模式，AMQP - 线路级和HTTP - 应用程序协议，运行在TCP / IP之上


• AMQP是HTTP时的特定协议 - 通用协议，因此，HTTP与AMQP相比具有高昂的开销


• AMQP性质是异步的，其中HTTP性质是同步的


• REST和RPC都使用数据序列化，这种格式取决于您，它取决于基础架构。如果你到处使用python，我认为你可以使用python本机序列化 - pickle ，它应该比JSON或任何其他格式更快。<​​/ li>
  
• HTTP + REST和AMQP + RPC都可以在异构和/或分布式环境中运行

• REST, RPC - architecture patterns, AMQP - wire-level and HTTP - application protocol which run on top of TCP/IP
• AMQP is a specific protocol when HTTP - general-purpose protocol, thus, HTTP has damn high overhead comparing to AMQP
• AMQP nature is asynchronous where HTTP nature is synchronous
• both REST and RPC use data serialization, which format is up to you and it depends of infrastructure. If you are using python everywhere I think you can use python native serialization - pickle which should be faster than JSON or any other formats.
• both HTTP+REST and AMQP+RPC can run in heterogeneous and/or distributed environment

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

So if you are choosing what to use: HTTP+REST or AMQP+RPC, the answer is really subject of infrastructure complexity and resource usage. Without any specific requirements both solution will work fine, but i would rather make some abstraction to be able switch between them transparently.

你告诉你的团队熟悉HTTP但不是与AMQP。如果开发时间是一个重要的时间你得到了答案。

You told that your team familiar with HTTP but not with AMQP. If development time is an important time you got an answer.

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

If you want to build HA infrastructure with minimal complexity I guess AMQP protocol is what you want.

我有两种体验，RESTful服务的优点是：

I had an experience with both of them and advantages of RESTful services are:

• 他们很好 - 在网络界面上映射


• 人们熟悉它们


• 易于调试（由于HTTP的一般用途）


• 轻松为第三方服务提供API。

• they well-mapped on web interface
• people are familiar with them
• easy to debug (due to general purpose of HTTP)
• easy provide API to third-party services.

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

Advantages of AMQP-based solution:

• 该死的快


• 灵活


• 易于维护


• 易于扩展


• 成本效益（资源使用含义）

• damn fast
• flexible
• easy to maintain
• easy to scale
• cost-effective (in resources usage meaning)

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

Note, that you can provide RESTful API to third-party services on top of your AMQP-based API while REST is not a protocol but rather paradigm, but you should think about it building your AQMP RPC api. I have done it in this way to provide API to external third-party services and provide access to API on those part of infrastructure which run on old codebase or where it is not possible to add AMQP support.

如果我说得对，你的问题是如何更好地组织软件不同部分之间的沟通，而不是如何为最终用户提供API。

If I am right your question is about how to better organize communication between different parts of your software, not how to provide an API to end-users.

如果你有一个高负荷的项目，RabbitMQ是一个非常好的软件，你可以轻松添加任何在不同机器上运行的工人。它还具有镜像和聚类功能。还有一件事，RabbitMQ建立在Erlang OTP之上，这是一个高可靠，稳定的平台......（bla-bla-bla），它不仅适用于市场营销，也适用于工程师。当nginx日志占用RabbitMQ运行的同一分区上的所有磁盘空间时，我只遇到RabbitMQ一次的问题。

If you have a high-load project RabbitMQ is damn good piece of software and you can easily add any number of workers which run on different machines. Also it has mirroring and clustering out of the box. And one more thing, RabbitMQ is build on top of Erlang OTP, which is high-reliable,stable platform ... (bla-bla-bla), it is good not only for marketing but for engineers too. I had an issue with RabbitMQ only once when nginx logs took all disc space on the same partition where RabbitMQ run.

这篇关于面向服务的体系结构 - AMQP或HTTP的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！