Como o sistema de eventos do Node.js é diferente do padrão de ator do Akka?

Trabalho Node.jscom o Java há algum tempo e me considero muito bom com Java. Mas acabei de descobrir Akkae fiquei imediatamente interessado em seu padrão de ator (pelo que entendi).

Agora, supondo que minhas habilidades em JavaScript estejam no mesmo nível de minhas habilidades em Scala / Java, quero me concentrar na praticidade de qualquer um dos sistemas. Principalmente em termos de serviços web.

Eu entendi que o Node é excelente para lidar com muitas operações simultâneas. Eu imagino que um bom serviço da web Node para um sistema de gerenciamento de ativos seria excelente em lidar com muitos usuários enviando alterações ao mesmo tempo (em um aplicativo grande e de tráfego pesado).

Mas depois de ler sobre os atores de Akka, parece que se destacaria na mesma coisa. E gosto da ideia de reduzir o trabalho a pedaços do tamanho de uma mordida. Além disso, anos atrás eu me interessei por Erlang e me apaixonei pelo sistema de passagem de mensagens que ele usa.

Trabalho em muitos aplicativos que lidam com lógicas de negócios complexas e estou pensando que é hora de pular mais pesado em um ou outro. Especialmente atualizando aplicativos legados de Struts e C #.

De qualquer forma, evitando guerras santas, como os dois sistemas são fundamentalmente diferentes? Parece que ambos estão voltados para o mesmo objetivo. Com talvez a arquitetura de "autocura" de Akka tendo uma vantagem.

EDITAR

Parece que estou recebendo votos acirrados. Por favor, não considere esta pergunta como "o que é melhor, node ou akka?". O que estou procurando são as diferenças fundamentais em bibliotecas orientadas a eventos, como Node, e as baseadas em atores, como Akka.

Sem entrar em detalhes (sobre os quais sei muito pouco no caso do Node.js), a principal diferença é que o Node.js oferece suporte apenas à simultaneidade sem paralelismo, enquanto a Akka oferece suporte a ambos. Ambos os sistemas são totalmente orientados por eventos e podem escalar para grandes cargas de trabalho, mas a falta de paralelismo torna difícil em Node.js (ou seja, o paralelismo é explicitamente codificado iniciando vários nós e despachando solicitações de acordo; portanto, é inflexível em tempo de execução) , embora seja bastante fácil na Akka devido aos seus executores multithread ajustáveis. Dadas pequenas unidades isoladas de trabalho (invocações de ator), o Akka paralelizará automaticamente a execução para você.

Outra diferença importante é que o Akka inclui um sistema para lidar com falhas de maneira estruturada (tendo cada ator supervisionado por seu pai, o que é obrigatório), enquanto o Node.js depende de convenções para que os autores passem condições de erro de retorno de chamada para retorno de chamada. O problema subjacente é que os sistemas assíncronos não podem usar a abordagem padrão de exceções empregada por sistemas baseados em pilha síncronos, porque o código de “chamada” terá passado para tarefas diferentes no momento em que o erro de retorno de chamada ocorrer. Ter o tratamento de falhas embutido no sistema torna mais provável que os aplicativos construídos nesse sistema sejam robustos.

O acima exposto não pretende ser exaustivo, tenho certeza de que há muito mais diferenças.

Eu ainda não usei Akka, mas parece que é parecido com erlang, mas em java. Em erlang, todos os processos são como atores em Akka, eles têm caixas de correio, você pode enviar mensagens entre eles, você tem supervisores etc.

Node.js usa simultaneidade cooperativa. Isso significa que você tem simultaneidade quando permite (por exemplo, quando chama a operação io ou algum evento assíncrono). Quando você tem alguma operação longa (calculando algo em um loop longo), bloqueia todo o sistema.

Erlang usa alternância de tarefas preventiva. Quando você tem um loop longo, o sistema pode pausá-lo para executar outra operação e continuar após algum tempo. Para simultaneidade massiva, o Node.js é bom se você fizer apenas operações curtas. Ambos suportam milhões de clientes: http://blog.caustik.com/2012/08/19/node-js-w1m-concurrent-connections/ http://blog.whatsapp.com/index.php/2012/01/ 1 milhão é tão 2011 /

Em java, você precisa de threads para fazer qualquer simultaneidade, caso contrário, você não pode pausar a execução dentro da função que erlang faz (na verdade, erlang faz uma pausa entre as chamadas de função, mas isso acontece com todas as funções). Você pode pausar a execução entre as mensagens.

Não tenho certeza se essa é uma comparação justa de se fazer. Eu li isso mais como "como um sistema baseado em eventos se compara a um modelo de ator?". Nodejs pode suportar um modelo de ator, assim como Scala faz em Akka, ou C # em Orleans, na verdade, verifique nactor , alguém parece já estar tentando.

Quanto à comparação entre um sistema de eventos e um modelo de ator, eu deixaria que pessoas mais sábias o descrevessem. Alguns pontos breves sobre o modelo de ator:

• O modelo de ator é baseado em mensagem
• Os modelos de ator tendem a funcionar bem com sistemas distribuídos (clusters). Claro que os sistemas baseados em eventos podem ser distribuídos, mas acho que o modelo de ator tem distribuição embutida com relação à distribuição de cálculos. Uma nova solicitação pode ser roteada para um novo ator em um silo diferente, sem certeza de como isso funcionaria com base em eventos.
• O modelo de Ator suporta falha em que, se o cluster 1 parecer estar inativo, o observador geralmente pode encontrar um silo diferente para fazer o trabalho

Além disso, verifique o drama . É outra implementação do modelo de ator nodejs.