¿En qué se diferencia el sistema de eventos de Node.js del patrón de actor de Akka?

He trabajado con él Node.jsdurante un tiempo y me considero bastante bueno con Java. Pero acabo de descubrir Akkay me interesé de inmediato en su patrón de actor (por lo que tengo entendido).

Ahora, asumiendo que mis habilidades de JavaScript estaban a la par con mis habilidades de Scala / Java, quiero centrarme en la practicidad de cualquiera de los sistemas. Especialmente en términos de servicios web.

Tenía entendido que Node es excelente en el manejo de muchas operaciones simultáneas. Me imagino que un buen servicio web de Node para un sistema de gestión de activos se destacaría en el manejo de muchos usuarios que envían cambios al mismo tiempo (en una aplicación de gran tamaño y tráfico).

Pero después de leer sobre los actores en Akka, parece que sobresaliría en lo mismo. Y me gusta la idea de reducir el trabajo a piezas pequeñas. Además, hace años incursioné en Erlang y me enamoré del sistema de transmisión de mensajes que utiliza.

Trabajo en muchas aplicaciones que se ocupan de la lógica empresarial compleja y creo que es hora de pasar más a una u otra. Especialmente la actualización de aplicaciones Struts y C # heredadas.

De todos modos, evitando las guerras santas, ¿en qué se diferencian fundamentalmente los dos sistemas? Parece que ambos están orientados hacia el mismo objetivo. Con tal vez la arquitectura de "autocuración" de Akka teniendo una ventaja.

EDITAR

Parece que estoy obteniendo votos ajustados. Por favor, no tome esta pregunta como "¿cuál es mejor, nodo o akka?". Lo que estoy buscando son las diferencias fundamentales en las bibliotecas impulsadas por eventos como Node y las basadas en actores como Akka.

Sin entrar en detalles (sobre los que sé muy poco en el caso de Node.js), la principal diferencia es que Node.js solo admite concurrencia sin paralelismo, mientras que Akka admite ambos. Ambos sistemas están completamente impulsados ​​por eventos y pueden escalar a grandes cargas de trabajo, pero la falta de paralelismo lo dificulta en Node.js (es decir, el paralelismo se codifica explícitamente iniciando múltiples nodos y enviando solicitudes en consecuencia; por lo tanto, es inflexible en tiempo de ejecución) , aunque es bastante fácil en Akka debido a sus ejecutores de subprocesos múltiples ajustables. Dadas pequeñas unidades de trabajo aisladas (invocaciones de actores), Akka paralelizará automáticamente la ejecución para usted.

Otra diferencia de importancia es que Akka incluye un sistema para manejar fallas de una manera estructurada (haciendo que cada actor sea supervisado por su padre, lo cual es obligatorio) mientras que Node.js se basa en las convenciones para que los autores pasen condiciones de error de devolución de llamada a devolución de llamada. El problema subyacente es que los sistemas asincrónicos no pueden utilizar el enfoque estándar de excepciones empleado por los sistemas síncronos basados ​​en pilas, porque el código de "llamada" habrá pasado a diferentes tareas para cuando se produzca el error de devolución de llamada. Tener el manejo de fallas integrado en el sistema hace que sea más probable que las aplicaciones integradas en ese sistema sean sólidas.

Lo anterior no pretende ser exhaustivo, estoy seguro de que hay muchas más diferencias.

Todavía no usé Akka, pero parece que es similar a erlang pero en java. En erlang todos los procesos son como actores en Akka, tienen buzones de correo, puedes enviar mensajes entre ellos, tienes supervisores, etc.

Node.js usa simultaneidad cooperativa. Eso significa que tiene simultaneidad cuando la permite (por ejemplo, cuando llama a la operación io o algún evento asincrónico). Cuando tiene una operación larga (calculando algo en un ciclo largo), bloquea todo el sistema.

Erlang utiliza el cambio de tareas preventivo. Cuando tiene un ciclo largo, el sistema puede pausarlo para ejecutar otra operación y continuar después de un tiempo. Para la concurrencia masiva, Node.js es bueno si solo realiza operaciones cortas. Ambos admiten millones de clientes: http://blog.caustik.com/2012/08/19/node-js-w1m-concurrent-connections/ http://blog.whatsapp.com/index.php/2012/01/ 1 millón es tan 2011 /

En java, necesita subprocesos para realizar cualquier concurrencia, de lo contrario, no puede pausar la ejecución dentro de la función que hace erlang (en realidad, erlang hace una pausa entre las llamadas a funciones, pero esto sucede con todas las funciones). Puede pausar la ejecución entre mensajes.

No estoy seguro de que esta sea una comparación justa para hacer. Leo esto más como "¿cómo se compara un sistema basado en eventos con un modelo de actor?". Nodejs puede admitir un modelo de actor tal como lo hace Scala en Akka, o C # en Orleans, de hecho, echa un vistazo a nactor , parece que alguien ya lo está probando.

En cuanto a cómo se compara un sistema de eventos versus un modelo de actor, dejaría que personas más sabias lo describan. Algunos breves puntos sobre el modelo Actor:

• El modelo de actor se basa en mensajes
• Los modelos de actor tienden a funcionar bien con sistemas distribuidos (clústeres). Seguro que los sistemas basados ​​en eventos se pueden distribuir, pero creo que el modelo de actor tiene una distribución incorporada con respecto a la distribución de cálculos. Una nueva solicitud se puede enrutar a un nuevo actor en un silo diferente, no estoy seguro de cómo funcionaría esto en base a eventos.
• El modelo Actor admite el fracaso en el sentido de que, si el grupo 1 parece estar inactivo, el observador generalmente puede encontrar un silo diferente para hacer el trabajo.

Además, echa un vistazo al drama . Es otra implementación del modelo de actor de nodejs.