In che modo il sistema con eventi di Node.js è diverso dal modello dell'attore di Akka?

Ci ho lavorato Node.jsper un po 'e mi considero abbastanza bravo con Java. Ma ho appena scoperto Akkae mi sono subito interessato al suo modello di attore (da quello che ho capito).

Ora, supponendo che le mie abilità JavaScript fossero alla pari con le mie abilità Scala / Java, voglio concentrarmi sulla praticità di entrambi i sistemi. Soprattutto in termini di servizi web.

Sapevo che Node è eccellente nel gestire molte operazioni simultanee. Immagino che un buon servizio Web Node per un sistema di gestione delle risorse eccellerebbe nel gestire molti utenti che inviano modifiche contemporaneamente (in un'applicazione di grandi dimensioni e con traffico intenso).

Ma dopo aver letto degli attori in Akka, sembra che eccellerebbe nella stessa cosa. E mi piace l'idea di ridurre il lavoro a piccoli pezzi. Inoltre, anni fa mi sono dilettato con Erlang e mi sono innamorato del sistema di trasmissione dei messaggi che utilizza.

Lavoro su molte applicazioni che si occupano di logica aziendale complessa e penso che sia ora di passare più pesantemente all'una o all'altra. Soprattutto l'aggiornamento di Struts legacy e applicazioni C #.

Ad ogni modo, evitando le guerre sante, in che modo i due sistemi sono fondamentalmente diversi? Sembra che entrambi siano orientati verso lo stesso obiettivo. Con forse l'architettura "autorigenerante" di Akka che ha un vantaggio.

MODIFICARE

Sembra che stia ottenendo voti vicini. Per favore non prendere questa domanda come un "che è meglio, nodo o akka?". Quello che sto cercando sono le differenze fondamentali tra le librerie basate sugli eventi come Node e quelle basate sugli attori come Akka.

Senza entrare nei dettagli (di cui so troppo poco nel caso di Node.js), la differenza principale è che Node.js supporta solo la concorrenza senza parallelismo mentre Akka supporta entrambi. Entrambi i sistemi sono completamente guidati dagli eventi e possono scalare a grandi carichi di lavoro, ma la mancanza di parallelismo lo rende difficile in Node.js (cioè il parallelismo è codificato esplicitamente avviando più nodi e inviando le richieste di conseguenza; è quindi poco flessibile in fase di esecuzione) , mentre è abbastanza facile in Akka grazie ai suoi esecutori multi-thread sintonizzabili. Date piccole unità di lavoro isolate (invocazioni di attori) Akka parallelizzerà automaticamente l'esecuzione per te.

Un'altra differenza di importanza è che Akka include un sistema per la gestione dei guasti in modo strutturato (avendo ogni attore supervisionato dal suo genitore, che è obbligatorio) mentre Node.js si basa sulle convenzioni per gli autori per passare condizioni di errore da callback a callback. Il problema di fondo è che i sistemi asincroni non possono utilizzare l'approccio standard delle eccezioni impiegato dai sistemi basati su stack sincroni, perché il codice "chiamante" sarà passato a compiti diversi nel momento in cui si verifica l'errore di callback. Avere la gestione dei guasti incorporata nel sistema rende più probabile che le applicazioni costruite su quel sistema siano robuste.

Quanto sopra non vuole essere esaustivo, sono sicuro che ci siano molte più differenze.

Non ho ancora usato Akka, ma sembra che sia simile a Erlang ma in Java. In erlang tutti i processi sono come attori in Akka, hanno caselle di posta, puoi inviare messaggi tra di loro, hai supervisori ecc.

Node.js utilizza la concorrenza cooperativa. Ciò significa che hai la concorrenza quando lo consenti (ad esempio quando chiami l'operazione io o qualche evento asincrono). Quando si hanno operazioni lunghe (calcolare qualcosa in un ciclo lungo), l'intero sistema si blocca.

Erlang utilizza la commutazione preventiva delle attività. Quando si dispone di un ciclo lungo, il sistema può metterlo in pausa per eseguire altre operazioni e continuare dopo un po 'di tempo. Per una concorrenza massiccia, Node.js è utile se esegui solo operazioni brevi. Entrambi supportano milioni di client: http://blog.caustik.com/2012/08/19/node-js-w1m-concurrent-connections/ http://blog.whatsapp.com/index.php/2012/01/ 1-milione-è-così-2011 /

In java hai bisogno di thread per fare qualsiasi concorrenza, altrimenti non puoi mettere in pausa l'esecuzione all'interno della funzione che erlang fa (in realtà erlang fa una pausa tra le chiamate di funzione, ma questo accade con tutte le funzioni). È possibile sospendere l'esecuzione tra i messaggi.

Non sono sicuro che questo sia un confronto equo da disegnare. Ho letto questo più come "come si confronta un sistema basato su eventi con un modello di attore?". Nodejs può supportare un modello di attore proprio come fa Scala in Akka, o C # fa a Orleans, infatti controlla nactor , sembra che qualcuno lo stia già provando.

Per quanto riguarda il confronto tra un sistema con eventi e un modello di attore, lascerei che le persone più sagge lo descrivano. Alcuni brevi punti sul modello Attore:

• Il modello dell'attore è basato sul messaggio
• I modelli degli attori tendono a funzionare bene con i sistemi distribuiti (cluster). Sicuramente i sistemi basati sugli eventi possono essere distribuiti, ma penso che il modello dell'attore abbia una distribuzione integrata per quanto riguarda la distribuzione dei calcoli. Una nuova richiesta può essere indirizzata a un nuovo attore in un silo diverso, non sono sicuro di come funzionerebbe in base agli eventi.
• Il modello Attore supporta il fallimento in quanto, se il cluster 1 sembra essere inattivo, l'osservatore può generalmente trovare un silo diverso per eseguire il lavoro

Inoltre, controlla il dramma . È un'altra implementazione del modello di attore nodejs.