Akka oder Reaktor [geschlossen]


94

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

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

Ich betrachte gerade zwei Frameworks, die neben ihrem Altersunterschied zwei unterschiedliche Ansichten zum Ausdruck bringen:

Was sollte ich bei der Auswahl eines der oben genannten Frameworks beachten?

Soweit ich bis jetzt verstehe, ist Akka immer noch irgendwie gekoppelt (auf eine Weise, dass ich den Schauspieler 'auswählen' muss, an den ich die Nachrichten senden möchte), aber sehr belastbar. Während Reactor lose ist (wie basierend auf Event-Posting).

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

AKTUALISIEREN

Nachdem ich den Event Bus von Akka besser durchgesehen habe, glaube ich, dass die von Reactor ausgedrückten Funktionen bereits in Akka enthalten sind.

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

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 Hauptunterschiede zwischen den beiden sind:

  • Akka, reifer, an Typesafe gebunden
  • Reaktor, frühes Stadium, an den Frühling gebunden

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


8
Akka muss nicht unbedingt von Scala verwendet werden, die meisten verwenden es sogar von Java aus.
Viktor Klang

1
David: So etwas wie: Akka EventBus API implementiert in Zusammenarbeit mit Akka Actors das Reactor Pattern
Viktor Klang

9
Nur zur Klarstellung: Der Reaktor ist überhaupt nicht an den Frühling gebunden. Wir halten Spring-Abhängigkeiten absichtlich fern, da es als grundlegendes Framework nicht sinnvoll ist, die Verwendung nur auf Spring-Benutzer zu beschränken. Was den Unterschied zwischen einem Schauspieler und einem Verbraucher betrifft: In Bezug auf den Reaktor kann Ihr Verbraucher zustandsbehaftet sein oder nicht. Es wird davon ausgegangen, dass Sie eine zustandslose anonyme Klasse oder Java 8 Lambda verwenden möchten, dies ist jedoch keine Voraussetzung. Und wie ich in meiner Antwort erwähnt habe, ist das Reactor-Toolset für frühe Iterationen absichtlich prägnant. Wir versuchen nicht, "den nächsten Akka" zu erschaffen.
Jon Brisbin

8
Lassen Sie einfach eine Erwähnung von vertx.io fallen, da ich glaube, dass es sich um dasselbe ereignisgesteuerte Gebiet handelt, mit einigen interessanten Konzepten in ähnlicher Weise für diejenigen, die forschen.
Offenbar

1
Nach ein paar Jahren bin ich auch in einer ähnlichen Situation. Meine Anwendung basiert hauptsächlich auf Federn und ich muss jetzt eine ereignisgesteuerte Funktion ausführen. Gibt es einen klaren Gewinner s / w Akka und Spring-Reaktor? Ich suche ein Framework mit aktiven Benutzergemeinschaften für den Fall, dass ich kompliziertere Szenarien erreiche.
Tim und Struppi

Antworten:


47

Es ist an dieser Stelle schwer zu sagen, da Reactor immer noch eine Skizze ist und ich (technischer Leiter von Akka) 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 in Ihrer Anforderungsliste die Ausfallsicherheit (dh die Überwachung in Akka) und die Standorttransparenz (dh die Bezugnahme auf aktive Entitäten auf eine Weise, mit der Sie über lokale oder Remote-Nachrichten abstrahieren können implizieren durch "verteilt"). Für "modular" weiß ich nicht genug über Reactor, insbesondere darüber, wie Sie aktive Komponenten nachschlagen und verwalten können.

Wenn Sie jetzt ein echtes Projekt starten und etwas brauchen, das Ihren ersten Satz erfüllt, dann wäre es meiner Meinung nach nicht umstritten, Akka an dieser Stelle zu empfehlen (wie Jon ebenfalls bemerkte). Fühlen Sie sich frei, konkretere Fragen zu SO oder zur Akka-User-Mailingliste zu stellen .


Danke Roland, ich freue mich zu sehen, dass Leute aus beiden Projekten zur Antwort beitragen. Ich probiere gerade Akka aus. Wie Sie erwartet haben, ist es ziemlich verfrüht, eine endgültige Antwort auf die Frage zu geben, außer dass sich der Reaktor noch in einem frühen Stadium befindet und daher noch nicht für einen Vergleich geeignet ist. Also, lasst uns abwarten, wie sich die Dinge entwickeln :-) Danke, David
David Riccitelli

7
Danke für deine Antwort, Roland. Ich wollte nur klarstellen, dass Reactor kein Akka-Konkurrent ist. Es gibt Ähnlichkeiten aufgrund eines überlappenden Problembereichs bei asynchronen Anwendungen. Reactor soll jedoch ein grundlegendes Gerüst sein, auf dem andere Systeme aufgebaut werden können. Diese anderen Systeme überschneiden sich möglicherweise noch stärker mit Akka als Reactor selbst. Auf absehbare Zeit wird Reactor jedoch ein Framework bleiben, das andere Systeme ermöglicht, und wird selbst kein Full-Stack-Framework sein. Sie müssen die Befriedigung beim Reactor / Akka-Shootout verzögern. ;)
Jon Brisbin

Keine Sorge, ich denke, Sie werden es gut machen, und ich bin mir ziemlich sicher, dass wir eine Fremdbestäubung sehen werden, wenn mehr Bibliotheken in dieses Feld eintreten.
Roland Kuhn

37

Der Reaktor ist nicht an Spring gebunden, sondern ein optionales Modul. Wir möchten, dass Reactor tragbar ist, eine Grundlage, wie Jon dargelegt hat.

Ich werde nicht sicher sein, die Produktion voranzutreiben, da wir nicht einmal Milestone (1.0.0.SNAPSHOT) sind. In dieser Hinsicht würde ich mir Akka genauer ansehen, das ein fantastisches asynchrones Framework IMO ist. Berücksichtigen Sie auch Vert.x und Finagle, die möglicherweise angepasst werden, wenn Sie entweder nach einer Plattform (erstere) oder nach zusammensetzbaren Futures (letztere) suchen. Wenn Sie sich um eine Vielzahl von asynchronen Mustern kümmern , bieten Ihnen GPars möglicherweise eine umfassendere Lösung.

Am Ende könnten sich sicherlich Überschneidungen ergeben. Tatsächlich tendieren wir zu einem gemischten Ansatz (flexibles zusammensetzbares Eventing, verteilt und nicht an eine Versandstrategie gebunden), bei dem Sie leicht Bits von RxJava , Vert.x , Akka usw. Finden können Wir sind nicht einmal von der Wahl der Sprache überzeugt, auch wenn wir uns stark für Groovy engagieren, haben die Leute bereits Clojure- und Kotlin- Häfen eröffnet. Fügen Sie dieser Mischung die Tatsache hinzu, dass einige Anforderungen von Spring XD und Grails bestimmt werden .

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


Vielen Dank, Stephane. Ich glaube, Ihre Antwort (und Jons Kommentar, stackoverflow.com/questions/16595393/akka-or-reactor/… ) geben eine viel klarere Perspektive. Ich werde noch warten, bevor ich die beantwortete Frage markiere. Wie Sie sagten, wollen wir sehen, was in naher Zukunft herauskommt. Ich weiß es wieder sehr zu schätzen, dass die an beiden Projekten beteiligten Personen Zeit damit verbracht haben, nützliche Erkenntnisse zu liefern.
David Riccitelli

Ich würde Vert.x zustimmen. Ich hatte Vert.x in der Produktionsumgebung in einigen Projekten verwendet, um zwischen Komponenten zu kommunizieren, und es funktioniert nahtlos.
Gewinnt am

33

Dies ist eine ausgezeichnete Frage, und die Antwort wird sich in den kommenden Wochen ändern. Wir können nicht versprechen, wie die Kommunikation zwischen Knoten im Moment aussehen wird, nur weil es zu früh ist. Wir müssen noch einige Teile zusammenstellen, bevor wir das Clustering in Reactor demonstrieren können.

Nur weil Reactor keine Kommunikation zwischen Knoten ausführt, heißt das nicht, dass OOTB dies nicht kann . :) Man würde nur eine ziemlich dünne Netzwerkschicht benötigen, um zwischen Reaktoren mit etwas wie Redis oder AMQP zu koordinieren, um ihm einige Cluster-Smarts zu geben.

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

Wenn Sie etwas benötigen, das gerade Clustering ausführt, ist die Wahl von Akka sicherer.


Danke Jon, ich finde Reactor sehr vielversprechend. Ich muss jedoch verstehen, ob es einen konzeptionellen Unterschied zwischen Reactor und Akka gibt, abgesehen von Merkmalen, die Reactor fehlen (natürlich in einem frühen Stadium). Zusammenfassend, was ist der konzeptionelle Unterschied zwischen einem Schauspieler in Akka und einem Verbraucher in Reaktor? Ich habe meine Frage auch mit einem Beispielereignis in Akka aktualisiert, das meiner Meinung nach dem Ereignisabonnement / -versand auf der Reactor GitHub-Seite ähnelt. Vielen Dank.
David Riccitelli

Jon, ich habe Ihre Antwort hier gelesen : blog.springsource.org/2013/05/13/… - daher können wir davon ausgehen, dass Akka und Reactor auf lange Sicht ein ähnliches Framework sein werden, das sowohl das Reaktormuster als auch das Akteurmodell unterstützt.
David Riccitelli


Ich verstehe nicht, wie dieser Kommentar jetzt falsch ist? Nichts widerspricht hier der Erklärung der strategischen Ausrichtung von Reactor.
Jon Brisbin

1
Erwischt. Ja, du verstehst richtig. Vielen Dank für diese Fragen! :)
Jon Brisbin
Durch die Nutzung unserer Website bestätigen Sie, dass Sie unsere Cookie-Richtlinie und Datenschutzrichtlinie gelesen und verstanden haben.
Licensed under cc by-sa 3.0 with attribution required.