En quoi le système événementiel Node.js est-il différent du modèle d'acteur d'Akka?

Je travaille Node.jsdepuis un petit moment et je me considère plutôt bien avec Java. Mais je viens de découvrir Akkaet je me suis immédiatement intéressé à son modèle d'acteur (d'après ce que je comprends).

Maintenant, en supposant que mes compétences JavaScript soient à la hauteur de mes compétences Scala / Java, je souhaite me concentrer sur l'aspect pratique de l'un ou l'autre système. Surtout en termes de services Web.

J'ai cru comprendre que Node est excellent pour gérer de nombreuses opérations simultanées. J'imagine qu'un bon service Web Node pour un système de gestion d'actifs excellerait dans la gestion de nombreux utilisateurs soumettant des modifications en même temps (dans une application à grand trafic).

Mais après avoir lu sur les acteurs d'Akka, il semble qu'il excellerait dans la même chose. Et j'aime l'idée de réduire le travail à des morceaux de la taille d'une bouchée. De plus, il y a des années, j'ai essayé Erlang et je suis tombé amoureux du système de transmission de messages qu'il utilise.

Je travaille sur de nombreuses applications qui traitent d'une logique métier complexe et je pense qu'il est temps de se lancer davantage dans l'une ou l'autre. Surtout la mise à niveau des anciennes applications Struts et C #.

Quoi qu'il en soit, en évitant les guerres saintes, en quoi les deux systèmes sont-ils fondamentalement différents? Il semble que les deux visent le même objectif. Avec peut-être l'architecture «d'auto-guérison» d'Akka ayant un avantage.

ÉDITER

Il semble que je reçois des votes serrés. Veuillez ne pas prendre cette question comme un "quel est le meilleur, nœud ou akka?". Ce que je recherche, ce sont les différences fondamentales entre les bibliothèques événementielles comme Node et celles basées sur les acteurs comme Akka.

Sans entrer dans les détails (dont je sais trop peu dans le cas de Node.js), la principale différence est que Node.js ne prend en charge que la concurrence sans parallélisme alors qu'Akka prend en charge les deux. Les deux systèmes sont entièrement pilotés par les événements et peuvent évoluer vers de grandes charges de travail, mais le manque de parallélisme le rend difficile dans Node.js (c'est-à-dire que le parallélisme est explicitement codé en démarrant plusieurs nœuds et en distribuant les demandes en conséquence; il est donc inflexible à l'exécution) , alors que c'est assez facile dans Akka grâce à ses exécuteurs multithreads réglables. Étant donné de petites unités de travail isolées (invocations d'acteurs), Akka parallélisera automatiquement l'exécution pour vous.

Une autre différence d'importance est qu'Akka inclut un système de gestion des échecs de manière structurée (en faisant superviser chaque acteur par son parent, ce qui est obligatoire) alors que Node.js s'appuie sur des conventions permettant aux auteurs de transmettre des conditions d'erreur de rappel en rappel. Le problème sous-jacent est que les systèmes asynchrones ne peuvent pas utiliser l'approche standard des exceptions employées par les systèmes basés sur une pile synchrone, car le code «appelant» sera passé à des tâches différentes au moment où l'erreur de rappel se produira. La gestion des pannes intégrée au système augmente la probabilité que les applications basées sur ce système soient robustes.

Ce qui précède n'est pas destiné à être exhaustif, je suis sûr qu'il y a beaucoup plus de différences.

Je n'ai pas encore utilisé Akka, mais il semble que ça ressemble à Erlang mais en java. Dans erlang, tous les processus sont comme des acteurs dans Akka, ils ont des boîtes aux lettres, vous pouvez envoyer des messages entre eux, vous avez des superviseurs etc.

Node.js utilise la simultanéité coopérative. Cela signifie que vous disposez d'une concurrence d'accès lorsque vous l'autorisez (par exemple, lorsque vous appelez une opération io ou un événement asynchrone). Lorsque vous avez une longue opération (calcul de quelque chose en longue boucle), tout le système bloque.

Erlang utilise la commutation de tâches préventive. Lorsque vous avez une longue boucle, le système peut la mettre en pause pour exécuter une autre opération et continuer après un certain temps. Pour une concurrence massive, Node.js est bon si vous ne faites que des opérations courtes. Les deux prennent en charge des millions de clients: http://blog.caustik.com/2012/08/19/node-js-w1m-concurrent-connections/ http://blog.whatsapp.com/index.php/2012/01/ 1-million-is-so-2011 /

En java, vous avez besoin de threads pour faire n'importe quelle concurrence, sinon vous ne pouvez pas suspendre l'exécution à l'intérieur de la fonction, ce que fait erlang (en fait, erlang fait une pause entre les appels de fonction, mais cela arrive avec toutes les fonctions). Vous pouvez suspendre l'exécution entre les messages.

Je ne suis pas sûr que ce soit une comparaison juste à tirer. Je lis ceci davantage comme "comment un système basé sur les événements se compare-t-il à un modèle d'acteur?". Nodejs peut prendre en charge un modèle d'acteur tout comme Scala le fait dans Akka, ou C # le fait à Orléans, en fait, vérifiez nactor , quelqu'un semble déjà l'essayer.

Quant à la comparaison entre un système événementiel et un modèle d'acteur, je laisserais les gens plus sages le décrire. Quelques brefs points à propos du modèle Actor:

• Le modèle d'acteur est basé sur un message
• Les modèles d'acteurs ont tendance à bien fonctionner avec les systèmes distribués (clusters). Bien sûr, les systèmes basés sur des événements peuvent être distribués, mais je pense que le modèle d'acteur a une distribution intégrée en ce qui concerne la distribution des calculs. Une nouvelle demande peut être acheminée vers un nouvel acteur dans un silo différent, sans savoir comment cela fonctionnerait en fonction des événements.
• Le modèle Actor prend en charge l'échec dans la mesure où, si le cluster 1 est en panne, l'observateur peut généralement trouver un silo différent pour faire le travail.

Regardez aussi le drame . C'est une autre implémentation du modèle d'acteur de nodejs.