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

Question

J'ai travaillé avec des Node.js pour un peu de temps et me considère assez bien avec Java. Mais je viens de découvrir Akka et a été tout de suite intéressé à son modèle acteur (ce que je comprends).

Maintenant, en supposant que mon JavaScript compétences ont été à la hauteur avec mon Scala/Java compétences, je veux me concentrer sur l'aspect pratique de l'un ou l'autre système. Surtout dans les conditions de services web.

C'était ma compréhension de ce Nœud est excellent dans le maniement de nombreuses opérations simultanées. J'imagine un bon Nœud de service web pour un système de gestion d'actifs serait excelle dans le traitement de nombreux utilisateurs de soumettre des modifications en même temps (dans un plus gros trafic de l'application).

Mais après avoir lu sur les acteurs Akka, il semble qu'il serait excel à la même chose. Et j'aime l'idée de réduire le travail de morceaux bouchées. De Plus, il y a des années j'ai barboté dans l'Erlang et est tombé en amour avec le passage de messages système qu'il utilise.

Je travaille sur de nombreuses applications qui traitent de la logique métier complexe et je pense qu'il est temps de sauter plus lourd dans l'une ou l'autre. En particulier la mise à niveau de l'héritage des Entretoises et des applications C#.

De toute façon, en évitant les guerres saintes, comment les deux systèmes fondamentalement différents? Il semble que les deux sont orientés vers le même objectif. Avec peut-être Akka "auto-guérison" de l'architecture d'un avantage.

MODIFIER

On dirait que je suis la proximité des votes. Merci de ne pas prendre cette question comme "quel est le meilleur, nœud ou akka?". Ce que je cherche, c'est une différence fondamentale dans événementielle des bibliothèques comme Nœud et l'acteur base comme Akka.

Answer 1

Sans entrer dans les détails (dont je connais trop peu dans le cas de Node.js), la principale différence est que Node.js prend en charge uniquement la simultanéité sans parallélisme tout Akka supporte à la fois. Les deux systèmes sont entièrement pilotés par les événements et peuvent s'adapter à la grand-charge, mais le manque de parallélisme rend difficile à Node.js (c'est à dire le parallélisme est explicitement codé par le démarrage de plusieurs nœuds et la distribution des demandes en conséquence; il est donc inflexible à l'exécution), alors qu'il est assez facile à Akka en raison de sa réglable multi-thread exécuteurs testamentaires. De petites unités isolées de travail (acteur invocations) Akka automatiquement paralléliser l'exécution pour vous.

Une autre différence importante est qu'Akka comprend un système de gestion de la défaillance d'une manière structurée (en ayant chaque acteur supervisé par ses parents, ce qui est obligatoire), alors que Node.js s'appuie sur des conventions pour les auteurs de transmettre les conditions d'erreur de rappel de rappel. Le problème sous-jacent est que les systèmes asynchrones ne peut pas utiliser l'approche standard des exceptions employé par synchrone basée sur la pile des systèmes, parce que la "vocation" code sera déplacé sur plusieurs tâches à la fois la fonction de rappel de l'erreur se produit. Ayant la gestion des pannes intégré dans le système, il est plus probable que les applications construites sur ce système sont robustes.

Le ci-dessus n'est pas destinée à être exhaustive, je suis sûr qu'il ya beaucoup plus de différences.

Answer 2

Je n'ai pas encore utiliser Akka, mais il semble qu'il est erlang, mais en java. En 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 coopérative de simultanéité. Cela signifie que vous avez la simultanéité, si vous le permettez (par exemple lorsque vous appelez opération e / s ou de certains événements asynchrones). Lorsque vous avez une longue opération (calcul de quelque chose en boucle longue) l'ensemble des blocs du système.

Erlang utilise de préemption des tâches de commutation. Lorsque vous avez longtemps boucle, le système peut mettre en pause pour exécuter une autre opération et de continuer après un certain temps. Pour massives de simultanéité Node.js est bon si vous faites seulement les opérations de courte durée. À la fois 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 toute la simultanéité, sinon vous ne pouvez pas suspendre l'exécution à l'intérieur d'une fonction qui erlang n' (en fait erlang des pauses entre les appels de fonction, mais ce hapens avec toutes les fonctions). Vous pouvez suspendre l'exécution entre les messages.

Answer 3

Je ne suis pas sûr que c'est une comparaison équitable à dessiner. J'ai lu ce plus que "comment un evented système basé sur le comparer avec un acteur modèle?". Nodejs peut prendre en charge un acteur modèle Scala n'en Akka, ou C# à Orléans, en fait, découvrez nactor, quelqu'un semble être déjà essayer.

Quant à la façon d'un evented système vs acteur modèle de comparer, je serait plus sage de laisser les gens décrivent. Quelques points à propos de l'Acteur modèle:

• Acteur de modèle de message en fonction
• Acteur modèles ont tendance à bien faire avec des systèmes distribués (clusters). Assurez-vous d'événements basés sur les systèmes peuvent être distribués, mais je pense que l'acteur modèle de distribution construit en ce qui concerne la distribution des calculs. Une nouvelle demande peut être acheminé vers un nouvel acteur dans un autre silo, vous ne savez pas comment cela peut fonctionner dans des cas fondés.
• L'Acteur prend en charge l'échec dans la mesure où, si hey cluster 1 apperas à la baisse, l'observateur peut généralement trouver un autre silo pour faire le travail

Aussi, découvrez drame. Il est un autre nodejs acteur de la mise en œuvre du modèle.