¿AMQP es adecuado como bus de software intra e intermáquina?

Question

Estoy tratando de entender AMQP. Se ve muy bien para la comunicación entre máquinas (clúster, LAN, WAN) entre aplicaciones, pero no estoy seguro si es adecuado (en términos arquitectónicos y de implementación actual) para usar como un bus de software dentro de una máquina.

¿Valdría la pena extraer un marco actual de paso de mensajes de alto rendimiento para reemplazarlo por AMQP, o está cayendo en el same trap as RPC al difuminar la distinción entre comunicación local y no local?

También soy cauteloso sobre los impactos en el rendimiento del uso de una tecnología WAN para las comunicaciones dentro de la máquina, aunque esto puede ser más un problema de implementación que la arquitectura.

Historias de guerra serían apreciadas.

Answer 1

AMQP no es un marco RPC. Proporciona los elementos básicos para modelar cosas como colas compartidas, RPC, pubsub, etc., pero no obliga a ninguna forma específica de usarlo.

Si desea particionar su aplicación (haciéndola distribuible en el camino) y conectarla con AMQP, creo que es la tecnología correcta. Sin embargo, podría haber alternativas más rápidas, pero probablemente ninguna tan genérica como AMQP.

Answer 2

AMQP es una especificación por lo que estaría comparando manzanas con naranjas realmente. No hay muchos proveedores de AMQP preparados para producción realmente; ninguno de los principales proveedores de mensajería o proveedores admiten AMQP en el momento de la escritura (por ejemplo, IBM, Tibco, Sonic, BEA, Oracle, SwiftMQ, MS, Apache ActiveMQ, openmq de Sun), por lo que todos los proveedores de AMQP disponibles son bastante nuevos.

Así que recomendaría comparar cualquier proveedor de AMQP que le interese con su marco de paso de mensajes. No tiene sentido arrancar algo que funciona bien solo por la forma en que lee & escribe bytes en un socket :)

Answer 3

AMQP parece más una oferta confiable de middleware de transporte para SOA que algo que se debe usar internamente.

Answer 4

Como base para una aplicación confiable, extremadamente flexible (en términos de patrones de mensajes) se puede utilizar para muchos escenarios de mensajería, tanto dentro de la máquina (es decir, entre procesos) como entre redes. Puede escalar desde cero hasta sistemas enormes, de gran ancho de banda y redes múltiples.

Actualmente estoy evaluando un sistema pequeño, pero relativamente complejo, casi en tiempo real, donde no nos importa qué tan lejos viajan los mensajes o quién/qué (dentro de lo razonable;) los está consumiendo. Si un consumidor está sentado en la misma máquina, que así sea. Lo probaría y vería qué es lo que hace. Si desea unir un prototipo de sistema, use python y la biblioteca Pika.

Answer 5

Si le interesan principalmente los desempeños en un escenario intramáquina, la pregunta es menos sobre AMQP (que es solo un protocolo de nivel de cable) que sobre qué implementación debe intentar.

Al eliminar la latencia introducida por la red, es probable que sea mucho más sensible a los resultados brutos de las diversas implementaciones. Por lo tanto, miraría productos implementados en C++ como Qpid o Zeromq.

Qpid puede alcanzar fácilmente 400 000 mensajes/segundo (con mensajes de 1024 bytes) en hardware decente (cuatro núcleos). Zeromq probablemente funcionará mucho mejor porque puede tener canales peer-to-peer, mientras que Qpid está utilizando una arquitectura intermedia (que tenía un paso).

Answer 6

El estándar AMQP está madurando y resuelve algunos de los problemas peludos que han plagado a otros estándares de mensajería como JMS. A su pregunta si vale la pena reemplazar una solución existente, diría que depende. Sería muy escéptico, ya que presumiblemente el sistema ya está funcionando, en producción y altamente eficiente.

Si tiene problemas como:

• interoperabilidad no está funcionando
• No se puede escalar fácilmente
• El rendimiento no es suficiente
• La solución de mensajería actual es caro bueno (para mantener)

Debe investigar el trabajo requerido y analizar los beneficios de forma más precisa. Si ya está contento, reemplazar un marco de mensajería no va a devolver la inversión.