Чем система событий Node.js отличается от шаблона акторов в Akka?

Я работал Node.jsнекоторое время и считаю, что неплохо разбираюсь в Java. Но я только что обнаружил Akkaи сразу заинтересовался его образцом актера (насколько я понимаю).

Теперь, предполагая, что мои навыки JavaScript были на одном уровне с моими навыками Scala / Java, я хочу сосредоточиться на практичности любой системы. Особенно в плане веб-сервисов.

Насколько я понимаю, Node отлично справляется со многими параллельными операциями. Я полагаю, что хороший веб-сервис Node для системы управления активами преуспел бы в обработке множества пользователей, отправляющих изменения одновременно (в большом приложении с интенсивным трафиком).

Но после чтения об актерах в Akka кажется, что он преуспел бы в том же. И мне нравится идея сократить объем работы до мелочей. Кроме того, несколько лет назад я пробовал себя в Erlang и влюбился в систему передачи сообщений, которую он использует.

Я работаю над множеством приложений, которые имеют дело со сложной бизнес-логикой, и я думаю, что пора заняться тем или другим. Особенно обновление устаревших приложений Struts и C #.

В любом случае, если избегать священных войн, как эти две системы принципиально отличаются? Кажется, оба нацелены на одну и ту же цель. Может быть, у "самовосстанавливающейся" архитектуры Akka есть преимущество.

РЕДАКТИРОВАТЬ

Похоже, у меня уже почти все голоса. Пожалуйста, не воспринимайте этот вопрос как вопрос «что лучше: узел или акка?». Я ищу фундаментальные различия в библиотеках, управляемых событиями, таких как Node, и в библиотеках, основанных на акторах, таких как Akka.

Не вдаваясь в подробности (о которых я слишком мало знаю в случае Node.js), основное отличие состоит в том, что Node.js поддерживает только параллелизм без параллелизма, в то время как Akka поддерживает и то, и другое. Обе системы полностью управляемы событиями и могут масштабироваться до больших рабочих нагрузок, но отсутствие параллелизма затрудняет работу в Node.js (т.е. параллелизм явно кодируется запуском нескольких узлов и соответствующей отправкой запросов; поэтому он негибкий во время выполнения) , в то время как в Akka это довольно просто благодаря настраиваемым многопоточным исполнителям. Имея небольшие изолированные единицы работы (вызовы акторов), Akka автоматически распараллеливает выполнение за вас.

Еще одно важное отличие состоит в том, что Akka включает систему для обработки сбоев структурированным образом (за счет того, что каждый субъект контролируется его родителем, что является обязательным), тогда как Node.js полагается на соглашения для авторов, чтобы передать условия ошибки от обратного вызова к обратному вызову. Основная проблема заключается в том, что асинхронные системы не могут использовать стандартный подход исключений, используемый синхронными системами на основе стека, потому что «вызывающий» код перейдет к другим задачам к тому времени, когда возникнет ошибка обратного вызова. Наличие встроенной обработки ошибок в системе повышает вероятность того, что приложения, созданные в этой системе, будут надежными.

Вышеизложенное не является исчерпывающим, я уверен, что различий гораздо больше.

Я еще не использовал Akka, но похоже он похож на Erlang, но на java. В erlang все процессы похожи на акторов в Akka, у них есть почтовые ящики, вы можете отправлять сообщения между ними, у вас есть супервизоры и т. Д.

Node.js использует кооперативный параллелизм. Это означает, что у вас есть параллелизм, когда вы его разрешаете (например, когда вы вызываете операцию io или какое-то асинхронное событие). Когда у вас есть длительная операция (вычисление чего-либо в длинном цикле), вся система блокируется.

Erlang использует вытесняющее переключение задач. Если у вас длинный цикл, система может приостановить его, чтобы запустить другую операцию, и продолжить через некоторое время. Для массового параллелизма Node.js хорош, если вы выполняете только короткие операции. Оба поддерживают миллионы клиентов: http://blog.caustik.com/2012/08/19/node-js-w1m-concurrent-connections/ http://blog.whatsapp.com/index.php/2012/01/ 1-миллион-это-так-2011 /

В java вам нужны потоки для любого параллелизма, иначе вы не можете приостановить выполнение внутри функции, что делает erlang (на самом деле erlang делает паузу между вызовами функций, но это происходит со всеми функциями). Вы можете приостанавливать выполнение между сообщениями.

Я не уверен, что это справедливое сравнение для рисования. Я читаю это больше как «как система на основе событий сравнивается с моделью акторов?». Nodejs может поддерживать модель акторов так же, как Scala в Akka или C # в Орлеане, на самом деле проверьте nactor , кажется, кто-то уже пробует это.

Что касается сравнения системной системы и модели акторов, я бы позволил более мудрым людям описать это. Несколько кратких замечаний о модели Actor:

• Модель актера основана на сообщениях
• Акторские модели обычно хорошо работают с распределенными системами (кластерами). Конечно, системы, основанные на событиях, могут быть распределены, но я думаю, что модель акторов имеет встроенное распределение в отношении распределения вычислений. Новый запрос может быть направлен новому субъекту в другом хранилище, не зная, как это будет работать на основе событий.
• Модель актора поддерживает отказ в том, что если кластер 1 не работает, наблюдатель обычно может найти другой бункер для выполнения работы.

Также посмотрите драму . Это еще одна реализация модели акторов nodejs.