java - docs - Akka o Reactor

spring reactor

Question

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

Por lo tanto, me gustaría que los procesos comerciales se comuniquen entre sí, sean interoperables, pero también independientes.

Estoy buscando ahora dos marcos que, además de su diferencia de edad, expresen 2 puntos de vista diferentes:

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

¿Qué debería considerar al elegir uno de los marcos anteriores?

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

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

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, documentadas 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 maduro, obligado a Typesafe
• Reactor, etapa inicial, ligada a Spring

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

Answer 1

Es difícil decirlo en este punto porque Reactor sigue siendo un boceto y yo (el líder tecnológico de Akka) no tengo idea de a dónde irá. Será interesante ver si Reactor se convierte en un competidor de Akka, estamos esperando eso.

Por lo que puedo ver, de su lista de requisitos, Reactor no tiene capacidad de recuperación (es decir, qué supervisión le da en Akka) y transparencia de ubicación (es decir, refiriéndose a entidades activas de una manera que le permite abstraer a través de mensajes locales o remotos; implicar por "distribuido"). Para "modular" no sé lo suficiente sobre Reactor, en particular, cómo puede buscar componentes activos y administrarlos.

Si comienzas un proyecto real ahora y necesitas algo que satisfaga tu primera oración, entonces no creo que sería controvertido recomendar a Akka en este punto (como Jon también notó). Siéntase libre de hacer preguntas más concretas sobre SO o en la lista de correo de akka-usuario .

Answer 2

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 para armar antes de poder demostrar el agrupamiento en Reactor.

Dicho esto, solo porque Reactor no hace comunicaciones entre nodos OOTB no significa que no pueda . :) Uno solo necesitaría una capa de red bastante delgada para coordinar entre Reactors usando algo como Redis o AMQP para darle un poco de inteligencia agrupada.

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

Si necesita algo que se agrupe ahora mismo, estará más seguro eligiendo Akka.

Answer 3

Reactor no está obligado a Spring, es un módulo opcional. Queremos que Reactor sea portátil, una fundación como la describe Jon.

No tendré confianza en impulsar la producción ya que ni siquiera estamos en Milestone (1.0.0.SNAPSHOT), en ese sentido, tendría una visión más profunda de Akka, que es una fantástica estructura de trabajo asíncrona IMO. También considere Vert.x y Finagle que podrían adaptarse si busca una plataforma (la primera) o futuros compostables (la última). Si cuida una amplia gama de patrones asíncronos, 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 compuestos flexibles, distribuidos y no vinculados a ninguna estrategia de despacho) donde pueda encontrar fácilmente bits de RxJava , Vert.x , Akka , etc. . Ni siquiera somos obstinados con la elección del idioma, incluso si estamos fuertemente comprometidos con Groovy, la gente ya ha comenzado con los puertos de Clojure y Kotlin . Agregue a esta combinación el hecho de que Spring XD y Grails impulsan algunos requisitos.

Muchas gracias por su interés, espero que tenga más puntos de comparación en un par de meses :)