¿Es adecuado AMQP como bus de software intra e inter-máquina?

Question

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

¿Valdría la pena sacar un marco actual de paso de mensajes de alto rendimiento para reemplazarlo con AMQP, o esto está cayendo en el ¿la misma trampa que RPC al difuminar la distinción entre comunicación local y no local?

También desconfío de los impactos en el rendimiento de usar una tecnología WAN para las comunicaciones internas de la máquina, aunque esto puede ser más una preocupación de implementación que la arquitectura.

Las historias de guerra serían apreciadas.

Answer 1

AMQP no es un marco RPC. Proporciona los bloques de construcción para modelar cosas como colas compartidas, RPC, pubsub, etc., pero no exige ninguna forma específica de usarlo.

Si desea particionar su aplicación (para poder distribuirla 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 en realidad estarías comparando manzanas con naranjas. No hay muchos proveedores de AMQP listos para la producción realmente por ahí; ninguno de los principales proveedores o proveedores de mensajería es compatible con AMQP en el momento de la redacción (p. ej., IBM, Tibco, Sonic, BEA, Oracle, SwiftMQ, MS, Apache ActiveMQ, openmq de Sun), por lo que todos los proveedores de AMQP disponibles son bastante nuevos. / p>

Por lo tanto, recomiendo comparar cualquier proveedor de AMQP en el que esté interesado con su marco de paso de mensajes. No tiene sentido extraer algo que esté funcionando bien solo por la forma en que se lee & amp; escribe bytes en un socket :)

Answer 3

El estándar AMQP está madurando y resuelve algunos de los problemas capilares que han plagado a otros estándares de mensajería como JMS. A tu pregunta de 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 tiene un alto rendimiento.

Si tienes problemas como:

• La interoperabilidad no funciona
• No se puede escalar fácilmente
• El rendimiento no es lo suficientemente bueno
• La solución de mensajería actual es costosa (mantener)

Debe investigar el trabajo requerido y analizar los beneficios con mayor precisión. Si ya está satisfecho, reemplazar un marco de mensajería no va a generar un retorno de la inversión.

Answer 4

Como base para un confiable, extremadamente flexible (en términos de patrones de mensajería), 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 a enormes sistemas de múltiples redes y gran ancho de banda.

Actualmente lo estoy evaluando para un sistema pequeño, pero relativamente complejo, casi en tiempo real, en el que 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. Le daría una oportunidad y vería lo que haces de ella. Si desea juntar un sistema prototipo, use python y la biblioteca Pika .

Answer 5

AMQP se parece más a una oferta confiable de middleware de transporte para SOA que a un uso interno.

Answer 6

Si está interesado principalmente en las actuaciones en un escenario dentro de una máquina, la pregunta es menos acerca de AMQP (que es solo un protocolo de nivel de conexión) que sobre qué implementación debe probar.

Al eliminar la latencia introducida por la red, probablemente será mucho más sensible a los rendimientos brutos de las distintas implementaciones. Por lo tanto, me gustaría ver productos implementados en C ++ como Qpid o Zeromq.

Qpid puede alcanzar fácilmente 400 000 mensajes / segundo (con mensajes de 1024 bytes) en algún hardware decente (quad core). Zeromq probablemente se desempeñará mucho mejor porque puede tener canales de igual a igual, mientras que Qpid está utilizando una arquitectura de intermediario (que tuvo un paso).