Arquitectura Orientada a Servicios - AMQP o HTTP

Question

Arquitectura Orientada a Servicios - AMQP o HTTP

Un poco de fondo.

Aplicación monolítica muy grande de Django. Todos los componentes utilizan la misma base de datos. Necesitamos separar los servicios para poder actualizar de forma independiente algunas partes del sistema sin afectar al resto.

Usamos RabbitMQ como corredor de Apio.

Ahora mismo tenemos dos opciones:

Servicios HTTP usando una interfaz REST.
JSONRPC sobre AMQP a un servicio de bucle de eventos

Mi equipo se está inclinando hacia HTTP porque eso es lo que están familiarizados con, pero creo que las ventajas de usar RPC sobre AMQP superan con creces.

AMQP nos proporciona las capacidades para agregar fácilmente equilibrio de carga y alta disponibilidad, con entregas de mensajes garantizadas.

Mientras que con HTTP tenemos que crear envoltorios HTTP de cliente para trabajar con las interfaces REST, tenemos que poner un balanceador de carga y configurar esa infraestructura para tener HA, etc.

Con AMQP solo puedo generar otra instancia de la servicio, se conectará a la misma cola que las otras instancias y bam, HA y equilibrio de carga.

¿Me estoy perdiendo algo con mis pensamientos sobre AMQP?

41

scaling http rabbitmq soa amqp

Author: jreid42, 2013-05-30

Source

2 answers

La ironía de la solución que OP tuvo que aceptar es que AMQP u otras soluciones MQ se usan a menudo para aislar a las personas que llaman de la falta de fiabilidad inherente de los servicios solo HTTP to para proporcionar algún nivel de lógica de tiempo de espera y reintento y persistencia de mensajes para que la persona que llama no tenga que implementar su propio código de aislamiento HTTP. Una puerta de enlace HTTP o capa de adaptador muy delgada sobre un núcleo AMQP confiable, con la opción de ir directamente a AMQP utilizando un protocolo de cliente más confiable como JSONRPC a menudo sería lo mejor solución para este escenario.

16

Author: Chris Johnson,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/ajaxhispano.com/template/agent.layouts/content.php on line 61
2013-08-27 11:03:35

score 76 · Accepted Answer

Al principio,

REST, RPC-architecture patterns, AMQP-wire-level and HTTP - application protocol which run on top of TCP/IP
AMQP es un protocolo específico cuando HTTP-protocolo de propósito general, por lo tanto, HTTP tiene una sobrecarga malditamente alta en comparación con AMQP
La naturaleza AMQP es asíncrona donde la naturaleza HTTP es sincrónica
tanto REST como RPC usan serialización de datos, el formato depende de usted y depende de la infraestructura. Si está utilizando python en todas partes I cree que puede usar la serialización nativa de python - pickle que debería ser más rápida que JSON o cualquier otro formato.
tanto HTTP + REST como AMQP+RPC pueden ejecutarse en entornos heterogéneos y/o distribuidos

Así que si está eligiendo qué usar: HTTP+REST o AMQP+RPC, la respuesta está realmente sujeta a la complejidad de la infraestructura y el uso de recursos. Sin ningún requisito específico, ambas soluciones funcionarán bien, pero preferiría hacer algo de abstracción para poder cambiar entre ellas transparente.

Le dijiste que tu equipo estaba familiarizado con HTTP pero no con AMQP. Si el tiempo de desarrollo es un momento importante, tienes una respuesta.

Si desea construir infraestructura de HA con una complejidad mínima, supongo que el protocolo AMQP es lo que desea.

Tuve una experiencia con ambos y las ventajas de los servicios RESTful son:

están bien mapeados en la interfaz web
la gente está familiarizada con ellos
fácil de depurar (debido al propósito general de HTTP)
fácil proporcionar API a servicios de terceros.

Ventajas de la solución basada en AMQP:

maldito rápido
flexible
fácil de mantener
fácil de escalar
rentable (en el significado de uso de recursos)

Tenga en cuenta que puede proporcionar API RESTful a servicios de terceros sobre su API basada en AMQP, mientras que REST no es un protocolo sino un paradigma, pero debe pensar en crear su api RPC AQMP. Lo he hecho en esta forma de proporcionar API a servicios externos de terceros y proporcionar acceso a la API en aquellas partes de la infraestructura que se ejecutan en código base antiguo o donde no es posible agregar soporte AMQP.

Si tengo razón, su pregunta es sobre cómo organizar mejor la comunicación entre las diferentes partes de su software, no cómo proporcionar una API a los usuarios finales.

Si usted tiene un proyecto de alta carga RabbitMQ es muy buena pieza de software y se puede añadir fácilmente cualquier número de trabajadores que se ejecutan en diferentes máquinas. También tiene reflejo y agrupación fuera de la caja. Y una cosa más, RabbitMQ está construido sobre Erlang OTP, que es una plataforma estable y de alta fiabilidad ... ( bla-bla-bla), es bueno no solo para el marketing, sino también para los ingenieros. Tuve un problema con RabbitMQ solo una vez cuando nginx logs tomó todo el espacio del disco en la misma partición donde se ejecuta RabbitMQ.