Buon caso d'uso per Akka [chiuso]

605

Ho sentito un sacco di entusiasmo sul framework Akka (piattaforma di servizio Java / Scala), ma finora non ho visto molti esempi reali di casi d'uso per cui sarebbe utile. Quindi sarei interessato a conoscere le cose che gli sviluppatori hanno usato con successo.

Una sola limitazione: non includere il caso di scrittura di un server di chat. (perché? dato che questo è stato abusato come esempio per molte cose simili)

— StaxMan
fonte

10

Non è più facile iniziare con il problema e trovare una soluzione, piuttosto che avere una soluzione e cercare un problema su cui applicarlo? La mia ipotesi è che invece usando RMI, Akka e i suoi attori sembrano molto più facili / semplici per cui scrivere codice.

— Kennet,

67

Sì, se avessi un problema specifico da risolvere. Non sto cercando una "scusa per usare Akka" in alcun modo, ma sono interessato a saperne di più. Questo può aiutare a risolvere anche i problemi futuri, ma soprattutto è per il processo di apprendimento continuo.

— StaxMan,

C'è una domanda correlata ma sull'applicazione di AKKA per l'applicazione esistente + alcuni casi d'uso: stackoverflow.com/questions/16595685/…

— ses

2

Akka è una soluzione migliore rispetto a JMS o un sistema di code di messaggistica distribuita in stile MQ. Questo è il modo migliore per capirlo da solo, che di recente ha posto la stessa identica domanda: "Capisco come usarlo e vedere dove potrei usarlo, ma non riesco a vedere dove questo fornirebbe un vero vantaggio". I presupposti di progettazione alla base di Akka sono molto migliori di quelli alla base di JMS / MQ, in particolare per quanto riguarda l'isolamento del processo, la progettazione senza blocco e la gestione dei tentativi / guasti. In secondo luogo, l'API è molto più elegante degli strumenti JMS / MQ.

— user2684301

2

@ user2684301 hmmh. Trovo quella risposta un po 'ingiusta, nel modo dalle mele alle arance. Gli MQ sono (logicamente) semplici elementi costitutivi che fanno molto meno di Akka e non li confronterei fianco a fianco. Ma immagino che se lo leggessi come "rispetto ai sistemi distribuiti creati usando JMS, scritti in modo dichiarativo", avrebbe più senso.

— StaxMan

321

L'ho usato finora in due progetti reali con grande successo. entrambi sono nel campo delle informazioni sul traffico quasi in tempo reale (traffico come nelle automobili sulle autostrade), distribuiti su più nodi, integrando messaggi tra più parti, sistemi di backend affidabili. Non sono ancora libero di dare dettagli sui clienti, quando ottengo l'OK forse può essere aggiunto come riferimento.

Akka ha davvero realizzato questi progetti, anche se abbiamo iniziato quando era nella versione 0.7. (stiamo usando scala a proposito)

Uno dei grandi vantaggi è la facilità con cui è possibile comporre un sistema di attori e messaggi con quasi nessuna placcatura, si ridimensiona molto bene senza tutte le complessità del threading a mano e si ottiene un messaggio asincrono che passa tra gli oggetti quasi gratuitamente.

È molto buono nel modellare qualsiasi tipo di gestione asincrona dei messaggi. Preferirei scrivere qualsiasi tipo di sistema di servizi (web) in questo stile rispetto a qualsiasi altro stile. (Hai mai provato a scrivere un servizio web asincrono (lato server) con JAX-WS? È un sacco di idraulica). Quindi direi qualsiasi sistema che non vuole aggrapparsi a uno dei suoi componenti perché tutto è implicitamente chiamato usando metodi sincroni e quel componente si sta bloccando su qualcosa. È molto stabile e la soluzione del supervisore let-it-crash + ai guasti funziona davvero bene. Tutto è facile da impostare a livello di codice e non è difficile da testare l'unità.

Poi ci sono gli eccellenti moduli aggiuntivi. Il modulo Camel si collega davvero bene ad Akka e consente un così semplice sviluppo di servizi asincroni con endpoint configurabili.

Sono molto contento del framework e sta diventando uno standard defacto per i sistemi connessi che costruiamo.

— Raymond Roestenburg
fonte

14

Qual è il vantaggio di questo approccio rispetto all'utilizzo di un backend di messaggistica (ad esempio ActiveMQ) per il passaggio di messaggi secondo te?

— magiconair,

27

I prodotti MQ sono davvero per un caso d'uso diverso. diverse garanzie e prestazioni molto diverse. I prodotti MQ richiedono molta configurazione, non si utilizzerebbero le code in un prodotto nello stesso modo in cui si utilizzerebbero gli oggetti. Gli attori sono cittadini di prima classe in akka, li usi come preferisci, in modo simile a come utilizzeresti gli oggetti, quindi c'è molto meno di un sovraccarico sia nel tuo modello di programmazione che nell'impostazione. Prodotti MQ che useresti di più per integrarti con altri sistemi esterni, non per costruire gli "interni" di un sistema, che è qualcosa per cui useresti gli attori.

— Raymond Roestenburg,

26

Il nuovo URL per il case study di DBP è downloads.typesafe.com/website/casestudies/…

— Bas

2

Sviluppando @RaymondRoestenburg in merito a: sistemi MQ e alternative. RabbitMQ, ad esempio, è basato su un linguaggio di programmazione basato sull'attore , Erlang. Questo è un modo di pensare alla relazione (e alla distinzione) tra attore e MQ. Nel frattempo Apache Spark non è né lavoratore-coda né basato sull'attore, MA può essere usato con Akka: Typesafe dimostra come usare Spark Streaming con Akka .

— driftcatcher

6

@RaymondRoestenburg Hai dimenticato di menzionare che il modello Actor così com'è promuove la struttura a forma di spaghetti. Il libro "Akka in azione" che hai scritto è la migliore dimostrazione per questa "caratteristica". Gli esempi di codice trattano storie abbastanza semplici. Tuttavia, il flusso di lavoro è molto difficile da comprendere e seguire dal codice. Un problema correlato è che il codice Akka sarà IRREVERSIBILE su tutta la logica aziendale nel modo più invadente che si possa immaginare. Molto più di qualsiasi altro framework non attore. È semplicemente impossibile scrivere un flusso di lavoro di base senza sezionarlo in diverse sezioni separate.

— rapt

222

Disclaimer: sono l'OP di Akka

Oltre a offrire uno smorgasbord di concorrenza molto più semplice da ragionare e da correggere (attori, agenti, concorrenza sul flusso di dati) e con controllo della concorrenza sotto forma di STM.

Ecco alcuni casi d'uso che potresti prendere in considerazione:

Elaborazione delle transazioni (giochi online, finanza, statistiche, scommesse, social media, telecomunicazioni, ...)
- scale up, scale out, tolleranza ai guasti / HA
Servizio back-end (qualsiasi settore, qualsiasi app)
- servizio REST, SOAP, cometd ecc
- agire come hub messaggi / livello di integrazione
- scale up, scale out, tolleranza ai guasti / HA
Concorrenza / parallelismo snap-in (qualsiasi app)
- Corretta
- Semplice da lavorare e da capire
- Aggiungi semplicemente i vasetti al tuo progetto JVM esistente (usa Scala, Java, Groovy o JRuby)
Elaborazione batch (qualsiasi settore)
- Integrazione di cammelli da collegare con origini dati batch
- Gli attori dividono e conquistano i carichi di lavoro batch
Hub di comunicazione (telecom, web media, mobile media)
- scale up, scale out, tolleranza ai guasti / HA
Server di gioco (giochi online, scommesse)
- scale up, scale out, tolleranza ai guasti / HA
BI / datamining / scricchiolio generale
- scale up, scale out, tolleranza ai guasti / HA
inserisci altri casi d'uso qui

— Viktor Klang
fonte

10

Comprendo i vantaggi di Futures e STM ma non trovo buoni casi d'uso per gli attori. Per un server di gioco o di scommesse, qual è il vantaggio di utilizzare Actors rispetto a più server di app dietro un bilanciamento del carico?

— Martin Konicek,

8

@ViktorKlang POs! = Capo tecnico. Lavorano insieme, ma hanno ruoli diversi.

— taylorcressy,

79

Un esempio di come lo utilizziamo potrebbe essere una coda prioritaria delle transazioni con carta di debito / credito. Ne abbiamo milioni e lo sforzo del lavoro dipende dal tipo di stringa di input. Se la transazione è di tipo CHECK, abbiamo pochissima elaborazione ma se si tratta di un punto vendita, ci sono molte cose da fare come unire i metadati (categoria, etichetta, tag, ecc.) E fornire servizi (avvisi email / sms, rilevazione di frodi, basso saldo di fondi, ecc.) In base al tipo di input componiamo le classi di vari tratti (chiamati mixin) necessari per gestire il lavoro e quindi eseguire il lavoro. Tutti questi lavori rientrano nella stessa coda in tempo reale da diversi istituti finanziari. Una volta ripuliti, i dati vengono inviati a diversi archivi dati per persistenza, analisi o trasferiti a una connessione socket o a Lift attore cometa. Gli attori che lavorano costantemente bilanciano autonomamente il lavoro in modo da poter elaborare i dati il più rapidamente possibile. Possiamo anche inserire servizi aggiuntivi, modelli di persistenza estm per i punti decisionali critici.

Il messaggio in stile OTP Erlang che trasmette la JVM è un ottimo sistema per lo sviluppo di sistemi in tempo reale sulle spalle di librerie e server applicazioni esistenti.

Akka ti consente di trasmettere messaggi come faresti in un modo tradizionale esbma con velocità! Fornisce inoltre strumenti nel framework per gestire l'enorme quantità di pool di attori, nodi remoti e tolleranza agli errori necessari per la soluzione.

— Wade Arnold
fonte

1

Quindi è giusto dire che si tratta di (alcune) richieste a lunga latenza, in cui il thread singolo per richiesta non si ridimensionerebbe bene?

— StaxMan,

7

Penso che la parte importante della programmazione degli attori in generale sia il flusso di messaggi. Una volta che inizi a concettualizzare in flussi di dati che non hanno effetti collaterali, vuoi solo che avvengano il maggior numero possibile di flussi per nodo. Questo è molto diverso dall'High Performance Computing se hai lavori semi-omogenei che non inviano messaggi e impiegano molto tempo per l'elaborazione. Penso che un'implementazione di Fibonacci basata sull'attore sia un esempio molto limitante in quanto non mostra perché usare gli attori ma solo che gli attori paralizzano i taks. Pensa all'architettura basata sugli eventi per i casi d'uso.

— Wade Arnold,

4

L'architettura guidata dagli eventi è un modo diverso di pensare ai problemi. Vale la pena leggere Erlang OTP in Action da manning se stai pensando di scrivere un codice in Akka. Molti costrutti di Akka sono influenzati da Erlang OTP e il libro fornisce i principi per cui Jonas Boner ha costruito Akka Api nel modo in cui lo ha fatto. Akka è una grande montagna su cui ti trovi! Se i tuoi attori sono persistenti attraverso i cambiamenti di stato, hai davvero bisogno che 10k scriva un secondo sostenuto

— Wade Arnold,

8

Wade, come gestite i messaggi? hai citato: (avvisi via e-mail / sms, rilevazione di frodi, saldo di fondi basso, ecc.), presumo che questi siano potenzialmente inviati ad attori remoti? Come assicurate che tali operazioni siano effettivamente avvenute? cosa succede se il nodo non riesce durante l'elaborazione di un avviso di frode? È andato per sempre? Hai un sistema eventualmente coerente che lo pulisce? Grazie!

— James,

2

Bella domanda James. È ovvio che si inserisce in un sistema in cui la risposta non è necessaria con urgenza. Ad esempio è possibile elaborare fatture con carta di credito; calcolare; inviare e-mail ecc. Mi chiedo davvero come vengono gestite queste cose (transazione) quando è necessaria una risposta. Alla fine; se una richiesta viene effettuata da un utente esterno (un utente di Internet; un rappresentante del call center ecc.); lui o lei aspetta una risposta. Come posso essere sicuro che i compiti secondari (che vengono eseguiti in modo asincrono) vengano eseguiti; in una transazione xa in modo da poter restituire la risposta?

— Kaan Yy,

44

Usiamo Akka per elaborare le chiamate REST in modo asincrono - insieme al server web asincrono (basato su Netty) possiamo ottenere un miglioramento di 10 volte sul numero di utenti serviti per nodo / server, rispetto al thread tradizionale per modello di richiesta utente.

Di 'al tuo capo che la tua fattura di hosting AWS diminuirà del fattore 10 ed è un gioco da ragazzi! Shh ... non dirlo ad Amazon però ... :)

— piotrga
fonte

3

E ho dimenticato di menzionare che la natura monadica dei futuri akka, che porta a un codice parallelo molto più pulito, ci ha salvato migliaia nella manutenzione del codice ...

— Piotrga,

8

Presumo che le chiamate siano ad alta latenza, a bassa velocità? Come effettuare chiamate verso altri server, in attesa di risposta (proxy)?

— StaxMan,

38

Stiamo utilizzando Akka in un progetto Telco su larga scala (purtroppo non posso rivelare molti dettagli). Gli attori Akka sono distribuiti e accessibili in remoto da un'applicazione web. In questo modo, abbiamo un modello RPC semplificato basato sul protobuffer di Google e otteniamo il parallelismo utilizzando Akka Futures. Finora questo modello ha funzionato alla grande. Una nota: stiamo usando l'API Java.

— Luciano Fiandesio
fonte

Potresti dirci qualcosa di più, per favore? I Futures Afaik non possono essere inviati via cavo (serializzati). Usi un sacco di futuri e pochi attori o un mix tra i due o ...? Usi protobuf per tutta la serializzazione e invii come messaggio agli attori?

— Aktau,

Sembra che avrebbe potuto essere gestito altrettanto facilmente senza Akka.

— Erik Kaplun,

1

TDC è la società Telco nel caso di Fiaddesio.

— Roman Kagan,

37

Se si estrae il server di chat di livello superiore, si ottiene la risposta.

Akka fornisce un sistema di messaggistica simile alla mentalità "lascia che si blocchi" di Erlang.

Quindi esempi sono cose che richiedono diversi livelli di durabilità e affidabilità della messaggistica:

Server di chat
Livello di rete per un MMO
Pompa di dati finanziari
Sistema di notifica per un iPhone / cellulare / qualunque app
Server REST
Forse qualcosa di simile a WebMachine (indovina)

Le cose belle di Akka sono le scelte che offre per la persistenza, l'implementazione STM, il server REST e la tolleranza agli errori.

Non essere infastidito dall'esempio di un server di chat, pensalo come un esempio di una certa classe di soluzione.

Con tutta la loro eccellente documentazione, mi sento come un vuoto è questa domanda esatta, casi d'uso ed esempi. Tenendo presente che gli esempi non sono banali.

(Scritto con la sola esperienza di guardare video e giocare con la fonte, non ho implementato nulla usando Akka.)

— tylerweir
fonte

2

Grazie - non intendevo che il server di chat fosse necessariamente negativo, solo che avrei voluto esempi complementari; più facile avere una migliore idea del potenziale.

— StaxMan,

Curioso di sapere come si inserisce il server REST qui? Lo stai citando nel contesto del server asincrono in stile Node.js? Grazie per aver condiviso i casi d'uso di esempio. Li ho trovati utili.

— software.wikipedia

24

Usiamo Akka in diversi progetti sul lavoro, il più interessante dei quali è legato alla riparazione di incidenti stradali. Principalmente nel Regno Unito, ma ora si sta espandendo negli Stati Uniti, in Asia, in Australia e in Europa. Utilizziamo gli attori per garantire che le informazioni sulla riparazione degli incidenti vengano fornite in tempo reale per consentire la riparazione sicura ed economica dei veicoli.

La domanda con Akka è davvero più "cosa non puoi fare con Akka". La sua capacità di integrarsi con potenti framework, la sua potente astrazione e tutti gli aspetti di tolleranza agli errori lo rendono un toolkit molto completo.

— rossputin
fonte

Quindi quale aspetto ti piace di più se dovessi scegliere? Integrazione esistente per altri framework, tolleranza di errore automatica o qualcos'altro?

— StaxMan,

6

Da una prospettiva personale è il livello di astrazione elevato che Akka porta sul tavolo che mi piace di più. Dal punto di vista aziendale sono le capacità di integrazione. Devo guadagnarmi da vivere e Akka copre affari e piacere entrambi molto bene :-)

— rossputin,

Potresti elaborare come è il flusso dei messaggi? È l'utente la persona in un'officina di riparazione e inserisce i dettagli dell'incidente in un modulo http e quindi invia i dati al server. Questo crea un messaggio che è gestito da Akka? Per fare cosa con questo messaggio? Estrarre le informazioni inserite per interrogare il database e quindi mettere in coda la risposta per rispedirla al frontend Web?

— surfmuggle,

24

Puoi usare Akka per diversi tipi di cose.

Stavo lavorando su un sito Web, dove ho migrato lo stack tecnologico su Scala e Akka. Lo abbiamo usato praticamente per tutto quello che è successo sul sito web. Anche se potresti pensare che un esempio di chat sia negativo, tutti sostanzialmente sono uguali:

Aggiornamenti live sul sito Web (ad es. Visualizzazioni, Mi piace, ...)
Mostra commenti degli utenti dal vivo
Servizi di notifica
Cerca e tutti gli altri tipi di servizi

Soprattutto gli aggiornamenti live sono facili poiché si riducono a ciò che è un esempio di chat. La parte dei servizi è un altro argomento interessante perché puoi semplicemente scegliere di usare attori remoti e anche se la tua app non è raggruppata, puoi distribuirla facilmente su macchine diverse.

Sto anche usando Akka per un'applicazione di autorouter per PCB con l'idea di essere in grado di scalare da un laptop a un data center. Più potenza gli dai, migliore sarà il risultato. Questo è estremamente difficile da implementare se si tenta di utilizzare la normale concorrenza poiché Akka offre anche trasparenza sulla posizione.

Attualmente come progetto per il tempo libero, sto costruendo un framework web usando solo attori. Ancora una volta i vantaggi sono la scalabilità da una singola macchina a un intero cluster di macchine. Inoltre, l'utilizzo di un approccio basato sui messaggi rende il servizio software orientato sin dall'inizio. Hai tutti quei componenti carini, che parlano tra loro ma non si conoscono necessariamente, vivono sulla stessa macchina, nemmeno nello stesso data center.

E da quando Google Reader ha chiuso ho iniziato con un lettore RSS, usando ovviamente Akka. Si tratta di servizi incapsulati per me. In conclusione: lo stesso modello di attore è quello che dovresti adottare per primo e Akka è un framework molto affidabile che ti aiuta a implementarlo con molti benefici che riceverai lungo la strada.

— Joa Ebert
fonte

Ciao Joe, potresti spiegare come vengono utilizzati i messaggi per aggiornare il sito? Hai un sistema per l'autore del contenuto; crea un nuovo articolo e colpisce il salvataggio. Questo crea un messaggio che viene inviato a diversi server che gestiscono il traffico in entrata. Ogni server elabora il messaggio di aggiornamento non appena possibile. Ogni nuova richiesta del browser ottiene quindi una versione aggiornata della pagina? Grazie

— surfmuggle il

18

Stiamo usando Akka con il suo plug-in cammello per distribuire la nostra analisi e l'elaborazione delle tendenze per twimpact.com . Dobbiamo elaborare tra 50 e 1000 messaggi al secondo. Oltre all'elaborazione multi-nodo con cammello, viene anche utilizzato per distribuire il lavoro su un singolo processore a più lavoratori per le massime prestazioni. Funziona abbastanza bene, ma richiede una certa comprensione di come gestire le congestioni.

— Matthias L. Jugel
fonte

stai usando anche la tolleranza agli errori di Akka?

— Erik Kaplun,

Che ne dite di Spark Streaming se abbiamo accesso al cluster Spark?

— skjagini,

18

Stavo provando le mie mani su Akka (api Java). Quello che ho provato è stato quello di confrontare il modello di concorrenza basato sull'attore di Akka con quello del semplice modello di concorrenza Java (classi java.util.concurrent).

Il caso d'uso era una semplice mappa canonica per ridurre l'implementazione del conteggio dei caratteri. Il set di dati era una raccolta di stringhe generate casualmente (400 caratteri di lunghezza) e calcolava il numero di vocali in esse contenute.

Per Akka ho usato un BalancedDispatcher (per il bilanciamento del carico tra i thread) e RoundRobinRouter (per mantenere un limite sui miei attori). Per Java, ho usato una tecnica di fork fork semplice (implementata senza alcun algoritmo di furto di lavoro) che avrebbe biforcato / ridotto le esecuzioni e unito i risultati. I risultati intermedi sono stati mantenuti nelle code di blocco per rendere anche l'unione il più parallela possibile. Probabilmente, se non sbaglio, ciò imiterebbe in qualche modo il concetto di "cassetta postale" degli attori Akka, in cui ricevono messaggi.

Osservazione: fino a carichi medi (input di ~ 50000 string) i risultati sono stati comparabili, variando leggermente in diverse iterazioni. Tuttavia, aumentando il mio carico a ~ 100000, si bloccherebbe la soluzione Java. Ho configurato la soluzione Java con 20-30 thread in questa condizione e non è riuscita in tutte le iterazioni.

L'aumento del carico a 1000000 è stato fatale anche per Akka. Posso condividere il codice con chiunque sia interessato a un controllo incrociato.

Quindi per me, sembra che Akka si riduca meglio della tradizionale soluzione multithread Java. E probabilmente il motivo è la magia sotto il cofano della Scala.

Se riesco a modellare un dominio problematico come un messaggio guidato da un evento che passa uno, penso che Akka sia una buona scelta per la JVM.

Test eseguito su: Versione Java: 1.6 IDE: Eclipse 3.7 Windows Vista 32 bit. Ram da 3 GB. Processore Intel Core i5, velocità di clock 2,5 GHz

Si noti che il dominio del problema utilizzato per il test può essere discusso e ho cercato di essere onesto quanto le mie conoscenze Java consentivano :-)

— Sutanu Dalui
fonte

3

"Posso condividere il codice con chiunque sia interessato a un controllo incrociato." Mi piacerebbe se non ti dispiace.

— n1r3,

3

Vorrei anche il codice, puoi pubblicare un link github?

— Gautam,

Grazie per il vostro interesse. Sfortunatamente ho qualche problema nell'impostare un repository github. Se puoi darmi le tue e-mail, posso spedire tramite il codice sorgente. E rimpianti per una risposta tardiva!

— Sutanu Dalui,

@sutanudalui Hai ancora il codice per favore, se così posso condividere la mia email?

— Jay,

16

Usiamo Akka nei sistemi di dialogo parlato ( primetalk ). Sia internamente che esternamente. Per eseguire contemporaneamente molti canali di telefonia su un singolo nodo del cluster, è ovviamente necessario disporre di un framework multithreading. Akka funziona perfettamente. Abbiamo un incubo precedente con la concorrenza java. E con Akka è proprio come un'altalena - funziona semplicemente. Robusto e affidabile. 24 * 7, non-stop.

All'interno di un canale abbiamo un flusso in tempo reale di eventi che vengono elaborati in parallelo. In particolare: - un lungo riconoscimento automatico del parlato - viene eseguito con un attore; - produttore di uscite audio che mescola alcune fonti audio (incluso il parlato sintetizzato); - la conversione da sintesi vocale è un insieme separato di attori condivisi tra i canali; - elaborazione semantica e della conoscenza.

Per effettuare interconnessioni di elaborazioni complesse del segnale utilizziamo SynapseGrid . Ha il vantaggio del controllo in fase di compilazione di DataFlow nei sistemi di attori complessi.

— Arseniy Zhizhelev
fonte

14

Di recente ho implementato l'esempio canonico di riduzione delle mappe in Akka: Conteggio parole. Quindi è un caso d'uso di Akka: prestazioni migliori. È stato più un esperimento degli attori di JRuby e Akka che di ogni altra cosa, ma mostra anche che Akka non è solo Scala o Java: funziona su tutte le lingue oltre a JVM.

— Daniel Ribeiro
fonte

Sai qual è il responsabile di migliori prestazioni (e anche rispetto a quale alternativa)? Ciò è dovuto all'utilizzo di JRuby su JVM (rispetto a Ruby nativo), scalalibilità a causa di I / O non bloccanti o qualcos'altro?

— StaxMan,

2

Il confronto che ho scritto è stato: Jruby sequenziale VS Jruby con attori. Pertanto, l'unica cosa che può essere responsabile di un'esecuzione più rapida è la partecipazione degli attori. Nessun esperimento di I / O ha partecipato agli esperimenti (un file viene caricato dal disco, ma viene eseguito prima di impostare il timer di benchmark).

— Daniel Ribeiro,

Di recente ho implementato anche un esempio di riduzione della mappa, ma è semplicemente vaniglia java github.com/chaostheory/jibenakka

— chaostheory