Akka o Reactor [chiuso]


94

Sono in procinto di avviare un nuovo progetto (basato su Java). Devo costruirlo come un'architettura modulare, distribuita e resiliente.

Pertanto vorrei che i processi aziendali per comunicare tra loro, essere interoperabili, ma anche indipendenti.

Sto osservando in questo momento due quadri che, oltre alla loro differenza di età, esprimono 2 diversi punti di vista:

Cosa devo considerare quando scelgo uno dei framework di cui sopra?

Per quanto ho capito fino ad ora, Akka è ancora in qualche modo accoppiato (in un modo in cui devo "scegliere" l'attore a cui voglio inviare i messaggi), ma molto resiliente. Mentre Reactor è libero (poiché si basa sulla pubblicazione di eventi).

Qualcuno può aiutarmi a capire come prendere una decisione corretta?

AGGIORNARE

Dopo aver recensito meglio l' Event Bus di Akka, credo in qualche modo le caratteristiche espresse da Reactor siano già incluse in Akka.

Ad esempio l'abbonamento e la pubblicazione di eventi, documentati su https://github.com/reactor/reactor#events-selectors-and-consumers , possono essere espressi in Akka come segue:

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

Pertanto ora mi sembra che le principali differenze tra i due siano:

  • Akka, più maturo, legato a Typesafe
  • Reactor, fase iniziale, destinato alla primavera

La mia interpretazione è corretta? Ma qual è concettualmente la differenza tra l'attore in Akka e il consumatore in Reactor ?


8
Akka non è destinato ad essere utilizzato da Scala, infatti, la maggioranza lo utilizza da Java.
Viktor Klang

1
David: Qualcosa come: Akka EventBus API in concerto con Akka Actors implementa il modello Reactor
Viktor Klang

9
Giusto per chiarire: Reactor non è affatto legato alla primavera. Teniamo intenzionalmente fuori tutte le dipendenze di Spring perché, come framework di base, non ha senso limitarne l'uso ai soli utenti di Spring. Per quanto riguarda la differenza tra un attore e un consumatore: per quanto riguarda Reactor, il tuo consumatore può essere stateful o meno. Si presume che si desideri utilizzare una classe anonima senza stato o lambda Java 8, ma non è un requisito. E come ho detto nella mia risposta, il set di strumenti Reactor è, per le prime iterazioni, intenzionalmente succinto. Non stiamo cercando di creare "il prossimo Akka".
Jon Brisbin

8
Lascio solo una menzione di vertx.io perché credo che sia nello stesso campo guidato dagli eventi con alcuni concetti interessanti in vena simile per coloro che stanno facendo ricerche ..
Opentuned

1
Passando un paio d'anni, mi trovo anche in una situazione simile, la mia applicazione è principalmente basata sulla primavera e ora ho bisogno di gestire una funzionalità guidata dagli eventi. C'è un chiaro vincitore b / n Akka e Spring-Reactor? Sto cercando un framework con comunità di utenti attive nel caso in cui raggiungo scenari più complicati.
tintin

Risposte:


47

È difficile da dire a questo punto perché Reactor è ancora uno schizzo e io (responsabile tecnico di Akka) non ho un'idea di dove andrà a finire. Sarà interessante vedere se Reactor diventerà un concorrente di Akka, non vediamo l'ora.

Per quanto posso vedere, dalla tua lista dei requisiti Reactor manca di resilienza (cioè cosa ti dà la supervisione in Akka) e trasparenza della posizione (cioè riferendosi a entità attive in un modo che ti permette di astrarre sulla messaggistica locale o remota; che è ciò che tu implica per "distribuito"). Per “modulare” non so abbastanza su Reactor, in particolare su come cercare componenti attivi e gestirli.

Se inizi un vero progetto ora e hai bisogno di qualcosa che soddisfi la tua prima frase, allora non penso che sarebbe controverso raccomandare Akka a questo punto (come ha anche notato Jon). Sentiti libero di porre domande più concrete su SO o sulla mailing list degli utenti akka .


Grazie Roland, mi piace vedere che le persone di entrambi i progetti stanno contribuendo alla risposta. Attualmente sto provando Akka. Come avevate anticipato, è abbastanza prematuro fornire una risposta definitiva alla domanda, se non fosse che Reactor è ancora in fase iniziale, quindi non ancora adatto per un confronto. Quindi, aspettiamo e vediamo come evolvono le cose :-) Grazie, David
David Riccitelli

7
Grazie per la tua risposta, Roland. Volevo solo chiarire che Reactor non è un concorrente di Akka. Ci sono somiglianze dovute a un'area di preoccupazione sovrapposta per quanto riguarda le applicazioni asincrone. Ma Reactor vuole essere un framework fondamentale su cui costruire altri sistemi. Questi altri sistemi potrebbero sovrapporsi ad Akka ancora di più di quanto non faccia lo stesso Reactor. Ma per il prossimo futuro Reactor rimarrà un framework che abilita altri sistemi e non sarà esso stesso un framework full-stack. Dovrai ritardare la gratificazione per la sparatoria Reactor / Akka. ;)
Jon Brisbin

Nessun problema, penso che andrà tutto bene e sono abbastanza certo che vedremo l'impollinazione incrociata man mano che più biblioteche entreranno in questo campo.
Roland Kuhn

37

Reactor non è vincolato a Spring, è un modulo opzionale. Vogliamo che Reactor sia portatile, una base come ha sottolineato Jon.

Non sarò fiducioso di spingere nella produzione poiché non siamo nemmeno Milestone (1.0.0.SNAPSHOT), a questo proposito, darei uno sguardo più approfondito ad Akka che è un fantastico framework asincrono IMO. Considera anche Vert.x e Finagle che potrebbero essere adattati se cerchi una piattaforma (la prima) o dei futuri componibili (la seconda). Se ti occupi di una vasta gamma di modelli asincroni, forse GPars ti fornirà una soluzione più completa.

Alla fine, potremmo sicuramente avere delle sovrapposizioni, infatti siamo propensi a un approccio misto (eventing componibile flessibile, distribuito e non vincolato a nessuna strategia di invio) in cui puoi facilmente trovare bit da RxJava , Vert.x , Akka ecc. Non siamo nemmeno supponenti per la scelta della lingua, anche se siamo fortemente impegnati per Groovy, le persone hanno già avviato i port di Clojure e Kotlin . Aggiungete a questo mix il fatto che alcuni requisiti sono guidati da Spring XD e Grails .

Molte grazie per il tuo interesse testimoniato, si spera che avrai più punti di confronto in un paio di mesi :)


Grazie Stephane, credo che la tua risposta (e il commento di Jon, stackoverflow.com/questions/16595393/akka-or-reactor/… ) fornisca una prospettiva molto più chiara. Aspetterò ancora prima di contrassegnare la domanda con risposta, come hai detto, vediamo cosa salterà fuori nel prossimo futuro. Ancora una volta apprezzo molto che le persone coinvolte in entrambi i progetti abbiano dedicato del tempo a fornire informazioni utili.
David Riccitelli

Sono d'accordo con Vert.x. Avevo utilizzato Vert.x nell'ambiente di produzione in un paio di progetti per comunicare tra i componenti e funziona perfettamente.
Vince il

33

Questa è un'ottima domanda e la risposta cambierà nelle settimane a venire. Non possiamo fare alcuna promessa su come sarà la comunicazione tra i nodi in questo momento solo perché è troppo presto. Abbiamo ancora alcuni pezzi da mettere insieme prima di poter dimostrare il clustering in Reactor.

Detto questo, solo perché Reactor non esegue comunicazioni inter-nodo OOTB non significa che non possa farlo . :) Uno avrebbe solo bisogno di uno strato di rete abbastanza sottile per coordinare i reattori usando qualcosa come Redis o AMQP per dargli un po 'di intelligenza in cluster.

Stiamo sicuramente parlando e pianificando scenari distribuiti in Reactor. È troppo presto per dire esattamente come funzionerà.

Se hai bisogno di qualcosa che faccia il clustering in questo momento, sarai più sicuro scegliendo Akka.


Grazie Jon, trovo Reactor molto promettente. Eppure ho bisogno di capire se c'è una differenza concettuale tra Reactor e Akka, oltre alle caratteristiche che Reactor manca (ovviamente, essendo nella sua fase iniziale). In sintesi qual è la differenza concettuale tra un attore in Akka e un consumatore in Reactor? Ho anche aggiornato la mia domanda con un evento di esempio in Akka che credo assomigli alla sottoscrizione / invio dell'evento sulla pagina GitHub di Reactor. Grazie.
David Riccitelli

Jon, stavo leggendo la tua risposta qui: blog.springsource.org/2013/05/13/… - quindi potremmo presumere che a lungo termine Akka e Reactor saranno framework simili, supportando entrambi il pattern Reactor e il modello Actor.
David Riccitelli


Non capisco come questo commento sia ora errato? Niente qui contraddice con la spiegazione della direzione strategica di Reactor.
Jon Brisbin

1
Gotcha. Sì, hai capito bene. Grazie per aver posto queste domande! :)
Jon Brisbin
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.