http rabbitmq soa scaling amqp

Arquitectura Orientada a Servicios-AMQP o HTTP



rabbitmq soa (2)

La ironía de la solución que OP tuvo que aceptar es que AMQP u otras soluciones MQ a menudo se usan para aislar a las personas que llaman de la falta de fiabilidad inherente de los servicios solo de HTTP, para proporcionar cierto nivel de tiempo de espera y reintento de la lógica y la persistencia del mensaje, por lo que la persona que llama no puede t tiene que implementar su propio código de aislamiento HTTP. Una pasarela HTTP muy delgada o una capa de adaptador 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 la mejor solución para este escenario.

Un poco de historia.

Muy grande aplicación monolítica de Django. Todos los componentes utilizan la misma base de datos. Necesitamos servicios separados para poder actualizar de manera independiente algunas partes del sistema sin afectar el resto.

Usamos RabbitMQ como agente de bolsa para el apio.

Ahora mismo tenemos dos opciones:

  1. Servicios HTTP utilizando una interfaz REST.
  2. JSONRPC sobre AMQP a un servicio de bucle de eventos

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

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

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

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

¿Me estoy perdiendo algo con mis pensamientos sobre AMQP?

Primero,

  • REST, RPC - patrones de arquitectura, AMQP - nivel de cable y HTTP - protocolo de aplicación que se ejecuta sobre TCP / IP
  • AMQP es un protocolo específico cuando HTTP - protocolo de propósito general, por lo tanto, HTTP tiene una sobrecarga muy alta en comparación con AMQP
  • La naturaleza AMQP es asíncrona cuando la naturaleza HTTP es síncrona
  • Tanto REST como RPC utilizan la serialización de datos, cuyo formato depende de usted y depende de la infraestructura. Si está usando python en todas partes, creo que puede usar la serialización nativa de python: pickle que debería ser más rápido que JSON o cualquier otro formato.
  • Tanto HTTP + REST como AMQP + RPC pueden ejecutarse en un entorno heterogéneo y / o distribuido

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

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 crear una infraestructura de alta disponibilidad 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 REST 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 de proporcionar API a servicios de terceros.

Ventajas de la solución basada en AMQP:

  • malditamente rápido
  • flexible
  • facil de mantener
  • fácil de escalar
  • rentable (en el sentido de uso de recursos)

Tenga en cuenta que puede proporcionar RESTful API 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 AQMP RPC. Lo he hecho de esta manera para proporcionar API a servicios externos de terceros y proporcionar acceso a API en aquellas partes de la infraestructura que se ejecutan en una base de código antigua o donde no es posible agregar soporte de AMQP.

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

Si tiene un proyecto de alta carga, RabbitMQ es una pieza de software muy buena y puede agregar 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 marketing sino también para ingenieros. Tuve un problema con RabbitMQ solo una vez cuando los registros de nginx tomaron todo el espacio de disco en la misma partición donde se ejecuta RabbitMQ.