Akka o Reactor [cerrado]

94

Estoy en el proceso de iniciar un nuevo proyecto (basado en Java). Necesito construirlo como una arquitectura modular, distribuida y resistente.

Por eso me gustaría que los procesos de negocio se comunicaran entre sí, fueran interoperables, pero también independientes.

Estoy mirando ahora mismo dos marcos que, además de su diferencia de edad, expresan 2 puntos de vista diferentes:

¿Qué debo considerar al elegir uno de los marcos anteriores?

Por lo que tengo entendido hasta ahora, Akka todavía está acoplado de alguna manera (de una manera que tengo que 'elegir' al actor al que quiero enviar los mensajes), pero es muy resistente. Mientras Reactor está suelto (según se basa en la publicación de eventos).

¿Alguien puede ayudarme a entender cómo tomar una decisión adecuada?

ACTUALIZAR

Después de revisar mejor el Event Bus de Akka, creo que de alguna manera las características expresadas por Reactor ya están incluidas en Akka.

Por ejemplo, la suscripción y la publicación de eventos, documentada en https://github.com/reactor/reactor#events-selectors-and-consumers , se pueden expresar en Akka de la siguiente manera:

final ActorSystem system = ActorSystem.create("system");
final ActorRef actor = system.actorOf(new Props(
    new UntypedActorFactory() {

        @Override
        public Actor create() throws Exception {

            return new UntypedActor() {
                final LoggingAdapter log = Logging.getLogger(
                        getContext().system(), this);

                @Override
                public void onReceive(Object message)
                        throws Exception {
                    if (message instanceof String)
                        log.info("Received String message: {}",
                                message);
                    else
                        unhandled(message);
                }
            };
        }
    }), "actor");

system.eventStream().subscribe(actor, String.class);
system.eventStream().publish("testing 1 2 3");

Por lo tanto, ahora me parece que las principales diferencias entre los dos son:

  • Akka, más madura, ligada a Typesafe
  • Reactor, etapa inicial, destinado a Spring

¿Es correcta mi interpretación? Pero, ¿cuál es conceptualmente la diferencia entre el actor en Akka y el consumidor en Reactor ?

David Riccitelli
fuente
8
Akka no está destinado a ser utilizado por Scala, de hecho, la mayoría lo utiliza desde Java.
Viktor Klang
1
David: Algo como: Akka EventBus API en concierto con Akka Actors implementan el patrón Reactor
Viktor Klang
9
Solo para aclarar: Reactor no está vinculado a Spring en absoluto. Dejamos fuera intencionalmente las dependencias de Spring porque, como marco fundamental, no tiene sentido restringir su uso solo a los usuarios de Spring. En cuanto a la diferencia entre un actor y un consumidor: en lo que respecta a Reactor, su consumidor puede tener estado o no. Se supone que querrá usar una clase anónima sin estado o Java 8 lambda, pero eso no es un requisito. Y como mencioné en mi respuesta, el conjunto de herramientas Reactor es, para las primeras iteraciones, intencionalmente sucinto. No estamos tratando de crear "el próximo Akka".
Jon Brisbin
8
Solo menciono vertx.io, ya que creo que está en el mismo campo impulsado por eventos con algunos conceptos interesantes en una línea similar para aquellos que están investigando ..
Opentuned
1
Pasando un par de años, también estoy en una situación similar. Mi aplicación se basa principalmente en un resorte y ahora necesito manejar una función basada en eventos. ¿Hay un ganador claro entre Akka y Spring-reactor? Busco un framework con comunidades de usuarios activas por si llego a escenarios más complicados.
Tintín

Respuestas:

47

Es difícil decirlo en este punto porque Reactor todavía es un boceto y yo (el líder tecnológico de Akka) no tengo idea de adónde irá. Será interesante ver si Reactor se convierte en un competidor de Akka, estamos deseando que llegue.

Por lo que puedo ver, de su lista de requisitos, a Reactor le falta resiliencia (es decir, lo que le brinda la supervisión en Akka) y transparencia de ubicación (es decir, refiriéndose a entidades activas de una manera que le permite abstraerse a través de mensajes locales o remotos; que es lo que usted implicar por "distribuido"). Para "modular" no sé lo suficiente sobre Reactor, en particular, cómo se pueden buscar componentes activos y administrarlos.

Si comienza un proyecto real ahora y necesita algo que satisfaga su primera oración, entonces no creo que sea controvertido recomendar Akka en este momento (como también señaló Jon). No dude en hacer preguntas más concretas sobre SO o sobre la lista de correo de akka-user .

Roland Kuhn
fuente
Gracias Roland, me encanta ver que la gente de ambos proyectos está contribuyendo a la respuesta. Actualmente estoy probando Akka. Como anticipó, es bastante prematuro proporcionar una respuesta final a la pregunta, excepto que Reactor aún se encuentra en las primeras etapas, por lo que aún no es adecuado para una comparación. Entonces, esperemos y veamos cómo evolucionan las cosas :-) Gracias, David
David Riccitelli
7
Gracias por tu respuesta, Roland. Solo quería aclarar que Reactor no es un competidor de Akka. Existen similitudes debido a un área de preocupación que se superpone con respecto a las aplicaciones asincrónicas. Pero Reactor está destinado a ser un marco fundamental sobre el que se pueden construir otros sistemas. Esos otros sistemas podrían superponerse aún más con Akka que el propio Reactor. Pero en el futuro previsible, Reactor seguirá siendo un marco que habilita otros sistemas y no será en sí mismo un marco completo. Tendrás que retrasar la gratificación en el tiroteo de Reactor / Akka. ;)
Jon Brisbin
No se preocupe, creo que lo hará bien, y estoy bastante seguro de que veremos polinización cruzada a medida que más bibliotecas ingresen a este campo.
Roland Kuhn
37

Reactor no está vinculado a Spring, es un módulo opcional. Queremos que Reactor sea portátil, una base como señaló Jon.

No estaré seguro de impulsar la producción ya que ni siquiera somos Milestone (1.0.0.SNAPSHOT), en ese sentido, tendría una mirada más profunda a Akka, que es un marco asincrónico fantástico en mi opinión. También considere Vert.x y Finagle, que podrían adaptarse si busca una plataforma (la primera) o futuros componibles (la última). Si busca una amplia gama de patrones asincrónicos, tal vez GPars le proporcione una solución más completa.

Al final, es posible que tengamos superposiciones, de hecho, nos inclinamos hacia un enfoque mixto (eventos componibles flexibles, distribuidos y no vinculados a ninguna estrategia de envío) donde puede encontrar fácilmente bits de RxJava , Vert.x , Akka , etc. Ni siquiera tenemos opiniones sobre la elección del idioma, incluso si estamos fuertemente comprometidos con Groovy, la gente ya ha iniciado los puertos de Clojure y Kotlin . Agregue a esta combinación el hecho de que algunos requisitos son impulsados ​​por Spring XD y Grails .

Muchas gracias por su interés observado, con suerte tendrá más puntos de comparación en un par de meses :)

Stephane Maldini
fuente
Gracias Stephane, creo que tu respuesta (y el comentario de Jon, stackoverflow.com/questions/16595393/akka-or-reactor/… ) dan una perspectiva mucho más clara. Todavía aguantaré antes de marcar la pregunta respondida, como dijiste, veamos qué aparece en un futuro cercano. Una vez más, aprecio mucho que las personas involucradas en ambos proyectos dediquen tiempo a proporcionar información útil.
David Riccitelli
Estoy de acuerdo con Vert.x. Usé Vert.x en un entorno de producción en un par de proyectos para comunicarme entre los componentes y funciona sin problemas.
Gana el
33

Esta es una excelente pregunta y la respuesta cambiará en las próximas semanas. No podemos hacer ninguna promesa de cómo se verá la comunicación entre nodos en este momento solo porque es demasiado pronto. Todavía tenemos algunas piezas que armar antes de poder demostrar la agrupación en clústeres en Reactor.

Dicho esto, el hecho de que Reactor no realice comunicaciones entre nodos OOTB no significa que no pueda hacerlo . :) Uno solo necesitaría una capa de red bastante delgada para coordinarse entre Reactores usando algo como Redis o AMQP para darle algo de inteligencia agrupada.

Definitivamente estamos hablando y planeando escenarios distribuidos en Reactor. Es demasiado pronto para decir exactamente cómo va a funcionar.

Si necesita algo que haga agrupaciones en este momento, estará más seguro eligiendo Akka.

Jon Brisbin
fuente
Gracias Jon, Reactor me parece muy prometedor. Sin embargo, necesito entender si existe una diferencia conceptual entre Reactor y Akka, además de las características que le faltan a Reactor (por supuesto, está en su etapa inicial). En resumen, ¿cuál es la diferencia conceptual entre un actor en Akka y un consumidor en Reactor? También actualicé mi pregunta con un evento de muestra en Akka que creo que se parece a la suscripción / envío del evento en la página de Reactor GitHub. Gracias.
David Riccitelli
Jon, estaba leyendo tu respuesta aquí: blog.springsource.org/2013/05/13/… - así que podríamos suponer que a largo plazo Akka y Reactor serán un marco similar, ambos soportando el patrón Reactor y el modelo Actor.
David Riccitelli
El comentario anterior ya no es correcto debido a lo siguiente: stackoverflow.com/questions/16595393/akka-or-reactor/… y stackoverflow.com/a/16674388/565110
David Riccitelli
No entiendo cómo este comentario ahora es incorrecto. Nada aquí contradice la explicación de la dirección estratégica de Reactor.
Jon Brisbin
1
Te tengo. Sí, lo entiendes correctamente. ¡Gracias por hacer estas preguntas! :)
Jon Brisbin