Akka o Reactor [cerrado]

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:

• Akka ( http://akka.io )
• Reactor ( https://github.com/reactor/reactor )

¿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 ?

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 .

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 :)

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.