Akka oder Reaktor

Question

Ich bin gerade dabei, ein neues Projekt zu starten (Java-basiert). Ich muss es als modulare, verteilte und belastbare Architektur aufbauen.

Daher möchte ich die Geschäftsprozesse untereinander kommunizieren lassen, interoperabel sein, aber auch unabhängig.

Ich suche jetzt an zwei Gerüsten, dass sie neben ihren Altersunterschied, zum Ausdruck 2 verschiedene Ansichten:

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

Was ich sollte bei der Wahl eines der oben genannten Frameworks berücksichtigen?

Soweit ich bisher verstanden habe, ist Akka immer noch irgendwie gekoppelt (auf eine Art, dass ich den Akteur wählen muss, "dem ich die Nachrichten senden möchte"), aber sehr belastbar. Während der Reaktor lose ist (basierend auf der Veröffentlichung von Ereignissen).

Kann mir jemand helfen zu verstehen, wie man eine richtige Entscheidung trifft?

UPDATE

Nachdem die Event Bus von Akka besser bewerten, ich glaube, in gewisser Weise sind die features expressed by Reactor bereits in Akka enthalten.

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"); 

Daher scheint es mir jetzt, dass die großen Unterschiede zwischen den beiden sind:

Zum Beispiel das Abonnement und Event-Publishing, auf https://github.com/reactor/reactor#events-selectors-and-consumers dokumentiert, kann wie folgt in Akka ausgedrückt werden

• Akka, reife, gebunden
• Reactor, frühzeitig zu typsicher,

zum Frühling gebunden

Ist meine Interpretation korrekt? Aber Was ist konzeptionell der Unterschied zwischen dem Schauspieler in Akka und dem Verbraucher in Reaktor?

Answer 1

Dies ist eine ausgezeichnete Frage und die Antwort wird sich in den nächsten Wochen ändern. Wir können keine Versprechen machen, wie die Inter-Node-Kommunikation im Moment aussehen wird, nur weil es zu früh ist. Wir müssen noch einige Teile zusammenstellen, bevor wir das Clustering im Reaktor demonstrieren können.

Mit diesem gesagt, nur weil Reaktor nicht Inter-Knoten comms OOTB bedeutet nicht kann nicht. :) Man benötigt nur eine ziemlich dünne Netzwerkschicht, um zwischen Reaktoren zu koordinieren, die etwas wie Redis oder AMQP verwenden, um einige Cluster-Smartes zu erhalten.

Wir sprechen und planen definitiv für verteilte Szenarien in Reactor. Es ist einfach zu früh, um genau zu sagen, wie es funktionieren wird.

Wenn Sie etwas brauchen, das Clustering jetzt macht, werden Sie sicherer Akka wählen.

Answer 2

Es ist schwer zu sagen an diesem Punkt, weil Reaktor noch eine Skizze ist und ich (Akkatecheleitung) keinen Einblick habe, wohin es gehen wird. Es wird interessant sein zu sehen, ob Reactor ein Konkurrent von Akka wird, wir freuen uns darauf.

Soweit ich sehen kann, fehlt Reactor aus Ihrer Anforderungsliste Resilienz (dh welche Überwachung gibt es in Akka) und Standorttransparenz (dh bezieht sich auf aktive Entitäten in einer Weise, die Sie über lokale oder Remote-Messaging abstrahieren können; was du mit "verteilt" meinst. Für "modular" weiß ich zu wenig über Reactor, insbesondere wie man aktive Komponenten nachschlagen und verwalten kann.

Wenn Sie jetzt ein echtes Projekt starten und etwas brauchen, das Ihren ersten Satz erfüllt, dann glaube ich nicht, dass es umstritten wäre, Akka zu diesem Zeitpunkt zu empfehlen (wie Jon auch bemerkte). Fühlen Sie sich frei, konkretere Fragen zu SO oder akka-user mailing list zu stellen.

Answer 3

Reaktor ist nicht an Spring gebunden, es ist ein optionales Modul. Wir wollen, dass Reactor tragbar ist, eine Grundlage, wie Jon beschrieben hat.

Ich werde über drängen in der Produktion nicht sicher sein, wie wir nicht einmal Milestone (1.0.0.SNAPSHOT) sind in dieser Hinsicht würde ich einen tieferen Blick auf Akka hat die IMO ein fantastischer asynchroner Rahmen ist. Beachten Sie auch Vert.x und Finagle, die angepasst werden können, wenn Sie entweder für eine Plattform (die ehemalige) oder für Composable-Futures (letztere) suchen. Wenn Sie nach einer breiten Palette von asynchronen Mustern suchen, wird Ihnen vielleicht GPars eine umfassendere Lösung bieten.

Am Ende könnten wir sicherlich Überschneidungen in der Tat sind wir (flexible zusammensetzbare Vielseitigkeits, verteilt und nicht gebunden an jede Verteilungsstrategie), wo man leicht Bits von RxJava finden, zu einem gemischten Ansatz stützte sich Vert.x, Akka etc. wir sind nicht einmal von der Sprache Wahl eigenwillig, auch wenn wir stark an Groovy begangen werden, haben die Menschen bereits begonnen Clojure und Kotlin Ports. Hinzu kommt die Tatsache, dass einige Anforderungen von Spring XD und Grails angetrieben werden.

Vielen Dank für Ihr Interesse erlebt, werden Sie hoffentlich mehr Vergleichspunkte in ein paar Monaten haben :)