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

93

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.

cbmeeks
fuente
12
Te voté a favor para decir "vete" a todos esos votantes cercanos :)
Nerrve
@cbmeeks, ¿puedo preguntar qué eligió y cómo le va con su elección?
Jas

Respuestas:

64

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.

Roland Kuhn
fuente
2
¿Crees que es la mejor manera de usar PLAY-FRAMEWORK o SPRAY si decido usar AKKA para crear una aplicación web relajante?
ses
4
Sí, ambas son buenas opciones. Play es adecuado como marco que le brinda una experiencia de desarrollo completamente integrada, pero significa que Play ejecutará su aplicación. El spray es mejor si solo desea tener una fina capa REST incrustada en su aplicación Akka. Tenga en cuenta que Spray se convertirá en akka-http en los próximos meses.
Roland Kuhn
3
Y también para señalar, obtienes todas las bondades de un lenguaje de tipado estático con Scala / Java y no hay un infierno de devolución de llamada en javascript. Java / Scala sería más fácil de depurar que javascript.
Chirdeep Tomar
2
En términos de paralelismo con el nodo, debe mencionarse que puede bifurcar procesos en tiempo de ejecución con su API central de clúster . Hará lo que quieres decir con actores paralelos.
kernel
2
Me parece que esta respuesta de 2012 ahora está muy anticuada, ya que muchas cosas han cambiado, especialmente con Node desde entonces. Mire npmjs.com/package/webworker-threads web Workers en Node, puede mover el trabajo intesivo de bloqueo a un proceso paralelo (todo mientras se encuentra en el mismo proceso de Node).
Mark Pieszak - Trilon.io
8

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.

yetihehe
fuente
Bien, suponiendo que necesito registrar archivos de registro de muchas fuentes diferentes. Cada vez que una aplicación genera una entrada de registro, también necesito enviar esa entrada a otra aplicación para su grabación. Supongo que esto podría ser un proceso de ejecución prolongada porque la aplicación podría tener tiempos de espera de DB, fallas http, etc. Entonces, en este ejemplo, un bloqueo por escrito en la base de datos haría que todo mi sistema de nodo se bloqueara. ¿AKKA sufriría el mismo problema o simplemente no obtengo la correlación?
cbmeeks
1
Ninguno de los dos sufriría, porque el acceso a la base de datos generalmente se implementa como asíncrono en tales casos. Pero si de alguna manera lograras hacer una biblioteca sincrónica haciendo eso, ambos se congelarían.
yetihehe
Gracias. Estoy tratando de no convertir esto en un node vs akkadebate, pero tengo un problema real que necesito resolver. Diría que mis habilidades en Java / JavaScript están bastante cerca, pero tengo muy poca experiencia con Node y ninguna con AKKA (o Scala). Pero tengo varias aplicaciones (internas por ahora pero externas más adelante) y la gente está buscando formas de buscar estos registros masivos. No se pueden utilizar opciones externas de terceros debido a problemas de privacidad. Parece que cualquiera de los dos manejaría el trabajo. Pero me gusta el mensaje de AKKA, así que podría explorar eso. Además, Java se empuja más aquí que JS. Gracias.
cbmeeks
Si necesita buscar registros masivos, intente buscar en logstash o graylog2.
Toddius Zho
6

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.

stevebot
fuente
1
intente configurar un clúster con nodejs, necesita docker, kubernetees y crear el sistema distribuido. También intente configurar el uso de 1 núcleo más en nodejs. Akka está diseñado para lidiar con esos. También la madurez de nodejs en sí, la seguridad y la forma de codificar que requiere otro marco para hacer algo, es un punto que nodejs en sí mismo no se puede usar para un gran sistema distribuido, pero al menos en una forma de MSA. Mi opinión de todos modos.
Raffaello