Ik werk al een tijdje met Node.jsen beschouw mezelf redelijk goed met Java. Maar ik ontdekte net Akkaen was meteen geïnteresseerd in het acteurspatroon (voor zover ik het begrijp).
Nu, ervan uitgaande dat mijn JavaScript-vaardigheden vergelijkbaar waren met mijn Scala/Java-vaardigheden, wil ik me concentreren op de bruikbaarheid van beide systemen. Vooral in termen van webservices.
Ik heb begrepen dat Node uitstekend is in het afhandelen van veel gelijktijdige bewerkingen. Ik stel me voor dat een goede Node-webservice voor een activabeheersysteem uitblinkt in het verwerken van veel gebruikers die tegelijkertijd wijzigingen indienen (in een grote applicatie met veel verkeer).
Maar na het lezen over de acteurs in Akka, lijkt het erop dat het in hetzelfde zou uitblinken. En ik hou van het idee om het werk terug te brengen tot hapklare stukjes. Bovendien heb ik jaren geleden in Erlang gedobbeld en werd ik verliefd op het berichtensysteem dat het gebruikt.
Ik werk aan veel applicaties die te maken hebben met complexe bedrijfslogica en ik denk dat het tijd is om zwaarder in de een of de ander te springen. Vooral het upgraden van oudere Struts- en C#-applicaties.
Hoe dan ook, het vermijden van heilige oorlogen, hoe zijn de twee systemen fundamenteel verschillend? Het lijkt erop dat beide op hetzelfde doel gericht zijn. Misschien heeft Akka’s “zelfherstellende” architectuur een voordeel.
BEWERKEN
Het lijkt erop dat ik bijna stemmen krijg. Beschouw deze vraag alsjeblieft niet als een “wat is beter, node of akka?”. Waar ik naar op zoek ben, zijn de fundamentele verschillen tussen gebeurtenisgestuurde bibliotheken zoals Node en op acteurs gebaseerde bibliotheken zoals Akka.
Antwoord 1, autoriteit 100%
Zonder in details te treden (waarover ik in het geval van Node.js te weinig weet), is het belangrijkste verschil dat Node.js alleen gelijktijdigheid ondersteunt zonder parallellisme, terwijl Akka beide ondersteunt. Beide systemen zijn volledig gebeurtenisgestuurd en kunnen worden geschaald naar grote werklasten, maar het gebrek aan parallellisme maakt het moeilijk in Node.js (dwz parallellisme wordt expliciet gecodeerd door meerdere knooppunten te starten en dienovereenkomstig verzoeken te verzenden; het is daarom inflexibel tijdens runtime) , terwijl het in Akka vrij eenvoudig is vanwege de instelbare multi-threaded uitvoerders. Gezien kleine geïsoleerde werkeenheden (aanroepingen van acteurs) zal Akka de uitvoering automatisch voor u parallelliseren.
Een ander belangrijk verschil is dat Akka een systeem bevat voor het op een gestructureerde manier afhandelen van fouten (door elke actor onder toezicht te laten staan van zijn ouder, wat verplicht is), terwijl Node.js vertrouwt op conventies voor auteurs om foutcondities door te geven van callback naar terugbellen. Het onderliggende probleem is dat asynchrone systemen de standaardbenadering van uitzonderingen die worden gebruikt door synchrone stack-gebaseerde systemen niet kunnen gebruiken, omdat de “aanroepende” code naar verschillende taken zal zijn gegaan tegen de tijd dat de callback-fout optreedt. Als foutafhandeling in het systeem is ingebouwd, is de kans groter dat toepassingen die op dat systeem zijn gebouwd robuust zijn.
Het bovenstaande is niet bedoeld om volledig te zijn, ik weet zeker dat er nog veel meer verschillen zijn.
Antwoord 2, autoriteit 11%
Ik heb Akka nog niet gebruikt, maar het lijkt erop dat het erlang-achtig is, maar dan in Java. In erlang zijn alle processen als acteurs in Akka, ze hebben mailboxen, je kunt er berichten tussen sturen, je hebt supervisors enz.
Node.js gebruikt coöperatieve gelijktijdigheid. Dat betekent dat u gelijktijdigheid hebt wanneer u dit toestaat (bijvoorbeeld wanneer u io-bewerking of een asynchrone gebeurtenis aanroept). Als je een lange operatie hebt (iets in een lange lus berekenen), blokkeert het hele systeem.
Erlang gebruikt preventieve taakwisseling. Als u een lange lus heeft, kan het systeem deze pauzeren om een andere bewerking uit te voeren en na enige tijd doorgaan. Voor massale gelijktijdigheid is Node.js goed als u alleen korte bewerkingen uitvoert. Beide ondersteunen miljoenen klanten:
http://blog.causstik.com/2012/08/19/node -js-w1m-concurrent-connections/
http://blog.whatsapp.com/index.php/2012 /01/1-miljoen-is-zo-2011/
In Java heb je threads nodig om gelijktijdigheid uit te voeren, anders kun je de uitvoering binnen de functie niet pauzeren, wat erlang wel doet (eigenlijk pauzeert erlang tussen functieaanroepen, maar dit gebeurt met alle functies). Je kunt de uitvoering pauzeren tussen berichten.
Antwoord 3, autoriteit 9%
Ik weet niet zeker of dit een eerlijke vergelijking is om te maken. Ik lees dit meer als “hoe verhoudt een op gebeurtenissen gebaseerd systeem zich tot een actormodel?”. Nodejs kan een acteursmodel ondersteunen, net zoals Scala dat doet in Akka, of C# in Orleans, bekijk in feite nactor, iemand lijkt het al te proberen.
Wat betreft de vergelijking tussen een gebeurtenissysteem en een acteursmodel, laat ik het door wijzere mensen beschrijven. Een paar korte punten over het Actor-model:
- Actormodel is gebaseerd op berichten
- Actormodellen doen het over het algemeen goed met gedistribueerde systemen (clusters). Natuurlijk kunnen op gebeurtenissen gebaseerde systemen worden gedistribueerd, maar ik denk dat het actormodel distributie heeft ingebouwd met betrekking tot het distribueren van berekeningen. Een nieuw verzoek kan worden doorgestuurd naar een nieuwe actor in een andere silo, niet zeker hoe dit zou werken op basis van gebeurtenissen.
- Het Actor-model ondersteunt mislukking in die zin dat, als hey cluster 1 niet lijkt te werken, de waarnemer over het algemeen een andere silo kan vinden om het werk te doen
Bekijk ook drama. Het is een andere implementatie van een nodejs-acteurmodel.