¿Akka hace obsoletos los corredores de mensajes JMS / AMQP? [cerrado]

19

Pasé la última semana profundizando en los documentos de Akka y finalmente entiendo qué son los sistemas de actores y los problemas que resuelven.

Mi comprensión (y experiencia con) los corredores de mensajes JMS / AMQP tradicionales es que existen para proporcionar lo siguiente:

  • Procesamiento asincrónico entre productor y consumidor; y
  • Garantía de entrega de mensajes, incluida persistencia, reintentos y fallos

¿Pero Akka no proporciona esto, sin toda la infraestructura requerida y la sobrecarga operativa?

  • En Akka, toda la comunicación del Actor es asíncrona y sin bloqueo; y
  • En Akka, SupervisorStrategiesexiste para lograr el reintento, el retroceso y la escalada. Los actores pueden configurarse para persistir en prácticamente cualquier tipo de tienda, si este es un requisito también.

Esto me hace preguntarme: si mi aplicación usa Akka, ¿alguna vez tengo la necesidad de incorporar a los corredores JMS / AMQP (por ejemplo, ActiveMQ, RabbitMQ, Kafka) a la imagen? En otras palabras, ¿hay algún caso de uso en el que una nueva aplicación basada en Akka también garantice la introducción de un nuevo clúster de corredores JMS / AMQP? ¿Por qué o por qué no?

El único argumento sería que quizás mi aplicación Akka tiene que integrarse con otro sistema. Pero en ese caso, el módulo Akka-Camel le permite a Akka aprovechar la lista exhaustiva y casi infinita de capacidades de integración de Camel (TCP, FTP, ZeroMQ, la lista sigue y sigue ...).

Pensamientos?

asynchronous-programming message-queue messaging akka smeeb
fuente
3
¿No es su último párrafo una razón por la cual Akka no deja obsoletos a los corredores de mensajes? Por ejemplo, estoy trabajando en una aplicación Java que interactúa con aplicaciones C ++ remotas a través de un agente de mensajes compatible con JMS. Podría escribir mi aplicación Java usando Akka-Camel, pero aún necesitaría el corredor debido a la aplicación C ++.
Thomas Owens
Ahhh, gracias @ThomasOwens (+1) pero has entendido mal (con razón) mi pregunta. Cambiaré la redacción en unos minutos para que sea más obvio. Lo que realmente estoy preguntando es: si estoy construyendo una aplicación de Akka, ¿alguna vez necesitaría también presentar un nuevo agente JMS / AMQP? Creo que la respuesta es "no", porque Akka + Camel ( creo que de nuevo ) resuelve todos los problemas típicamente resueltos por un corredor. En su ejemplo, el agente JMS ya existe como la forma de comunicarse con la aplicación C ++; No lo agregaré junto con mi nueva aplicación Akka. Y así, el módulo Akka-Camel se encargará de enviarme mensajes.
smeeb
2
Tal vez estoy malentendido, pero Camel no reemplaza JMS (por ejemplo), pero proporciona una interfaz que se puede usar para enviar mensajes a través de JMS. Puede reemplazar JMS con AMQP, RabbitMQ o XMPP. En mi ejemplo, incluso si mis aplicaciones Java + Akka y C ++ fueran completamente nuevas, para que se comuniquen a través de JMS, todavía necesitaría introducir algún tipo de cola de mensajes compatible con JMS y luego podría usar Akka-Camel para comunicarse con ella Camel no proporciona un corredor, solo medios para comunicarse dentro de una serie de protocolos. Akka-Camel proporciona una interfaz más familiar sobre la interfaz de Camel.
Thomas Owens
Gracias de nuevo @ThomasOwens (+1) - Creo que solo estás pensando demasiado en esto :-). En su ejemplo, hay una aplicación C ++ existente , tal vez algún sistema heredado, y hay un agente compatible con JMS existente que la aplicación C ++ ya usa para integrarse con el mundo exterior. En este caso, mi nueva aplicación Akka usaría, como usted dijo, el módulo Akka-Camel para producir / consumir mensajes hacia / desde este intermediario. ¡Pero esto no es lo que estoy preguntando aquí! Me pregunto si alguna vez habría una razón por la que necesitaría construir 2 cosas : (1) mi nueva aplicación Akka, y (2) un corredor JMS / AMQP, al mismo tiempo ...
smeeb
3
Menciona las capacidades de integración infinita de Camel, pero no puede integrarse con Nothing. Tiene que haber algo para que se integre, de lo contrario, solo está disfrutando del soporte para un conjunto de servicios que no está ejecutando. Arranque JMS, o un servidor HTTP o FTP o algo si quiere usar Camel para integrarse con algo. De lo contrario, proporciona una capacidad de integración infinita mientras se integra con nada.
Jimmy Hoffa

Respuestas:

12

Modelo de actor

El modelo de actor es una estrategia informática para construir aplicaciones que manejan gran cantidad de cómputo concurrente y procesamiento con estado. No es la única estrategia, pero es un enfoque muy bien probado, simple y confiable que mueve la computación a los actores , que se comunican a través de mensajes que procesan uno a la vez y en orden.

Akka es un marco que implementa el modelo de actor y le permite construir sistemas de actor con toda la infraestructura y las características ya construidas (como usar JQuery en lugar de javascript).

Mensajería

Los sistemas de mensajes son aplicaciones que pueden enviar y recuperar mensajes. Hay muchas variedades, desde colas básicas hasta software para grandes empresas con temas, pub / sub, persistencia y otras características, pero el objetivo final es el mismo. Guarde algunos bytes en algún lugar y vuelva a recuperarlos más tarde, con algún tipo de orden. El caso de uso principal hoy en día es desacoplar sistemas y permitir el procesamiento asincrónico a diferentes horarios o velocidades. RabbitMQ, NATS, Kafka, etc. son todos ejemplos de sistemas de mensajes.

Comparación

El modelo de actor y el marco de Akka son herramientas de bajo nivel que son una excelente manera de crear aplicaciones , como las colas de mensajes.

¿Puedes usar Akka en lugar de una cola de mensajes? Seguro. Si está creando software que ya utiliza el modelo de actor, entonces probablemente no necesite una cola de mensajes externa, especialmente para enviar mensajes dentro del mismo hilo o aplicación. Puede usar las capacidades de Akka Remoting para incluso enviar mensajes a otros sistemas de actores que se ejecutan en otras máquinas.

Sin embargo, ¿esto hace que los sistemas de mensajería sean obsoletos? Absolutamente no. El hecho de que pueda codificar todo esto usted mismo no significa que lo necesite, especialmente cuando un modelo de actor no es bueno para su problema o si necesita diferentes idiomas, aplicaciones, API externas, sistemas operativos, bases de datos, etc. para comunicarse entre sí (sean o no sistemas de actores).

Si solo necesita pasar algunos mensajes entre dos sistemas, use una cola de mensajes. Si necesita un procesamiento con estado escalable y mensajes de baja latencia dentro de la misma aplicación, utilice el modelo de actor. Ambos existen en niveles completamente diferentes y la forma en que los use depende de la solución que esté creando.

Hay una gran respuesta en SO sobre este mismo modelo de actor frente a mensajería: /programming/5693346/when-to-use-actors-instead-of-messaging-solutions-such-as-websphere-mq- o-tibco

Mani Gandham
fuente