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

94

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

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

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

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

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

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

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

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

cbmeeks
источник
12
Я проголосовал за то, чтобы вы сказали "уходите" всем этим близким избирателям :)
Nerrve
@cbmeeks, могу я спросить, что вы выбрали и как у вас дела с вашим выбором?
Jas

Ответы:

66

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

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

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

Роланд Кун
источник
2
Как вы думаете, лучший способ использовать PLAY-FRAMEWORK или SPRAY, если я решу использовать AKKA для создания спокойного веб-приложения?
ses
4
Да, оба варианта - хороший выбор. Play подходит в качестве платформы, которая дает вам полностью интегрированный опыт разработки, но это означает, что Play будет запускать ваше приложение. Spray лучше, если вы хотите, чтобы в ваше приложение Akka был встроен тонкий слой REST. Обратите внимание, что в ближайшие месяцы Spray станет akka-http.
Роланд Кун
3
А также, чтобы отметить, вы получаете все преимущества статически типизированного языка с помощью Scala / Java и без ада обратных вызовов в javascript. Java / Scala легче отлаживать, чем javascript.
Чирдип Томар
2
Что касается параллелизма с узлом, следует отметить, что вы можете разветвлять процессы во время выполнения с помощью API ядра кластера . Он будет делать то, что вы имеете в виду под параллельными актерами.
Ядро
2
Мне кажется, что этот ответ от 2012 года сейчас очень устарел, так как с тех пор многое изменилось, особенно с Node. Посмотрите на npmjs.com/package/webworker-threads веб- воркеров в Node, вы можете переместить блокирующую интерактивную работу в частичный процесс (и все это в одном и том же процессе Node).
Марк Пешак - Trilon.io
8

Я еще не использовал 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 делает паузу между вызовами функций, но это происходит со всеми функциями). Вы можете приостанавливать выполнение между сообщениями.

Yetihehe
источник
Хорошо, предполагаю, что мне нужно записывать файлы журналов из разных источников. Каждый раз, когда приложение создает запись в журнале, мне также необходимо отправить эту запись в другое приложение для записи. Я предполагаю, что это может быть длительный процесс, потому что приложение может иметь тайм-ауты БД, сбои HTTP и т. Д. Итак, в этом примере зависание записи в БД приведет к зависанию всей моей системы Node? Будет ли у AKKA такая же проблема, или я просто не улавливаю корреляцию?
cbmeeks
1
Ни то, ни другое не пострадает, потому что доступ к базе данных в таких случаях обычно реализуется как асинхронный. Но если бы вам каким-то образом удалось заставить синхронную библиотеку делать это, они оба зависли бы.
yetihehe
Спасибо. Я очень стараюсь не превращать это в node vs akkaдебаты, но у меня есть реальная проблема, которую мне нужно решить. Я бы сказал, что мои навыки Java / JavaScript довольно близки, но у меня очень мало опыта работы с Node и никакого опыта с AKKA (или Scala). Но у меня есть несколько приложений (на данный момент внутренние, а позже внешние), и люди ищут способы поиска в этих огромных журналах. Невозможно использовать внешние сторонние параметры из-за проблем с конфиденциальностью. Кажется, что любой справится с этой работой. Но мне нравится передача сообщения AKKA, поэтому я мог бы изучить это. Плюс здесь Java продвигается больше, чем JS. Спасибо.
cbmeeks
Если вам нужен поиск в массивных журналах, попробуйте посмотреть logstash или graylog2.
Тоддиус Жо 08
6

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

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

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

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

стивбот
источник
1
попробуйте настроить кластер с nodejs, вам понадобится docker, kubernetees и создайте распределенную систему. Также попробуйте настроить использование еще 1 ядра в nodejs. Akka предназначена для решения этих проблем. Кроме того, зрелость самого nodejs, безопасность и способ кодирования, требующий для чего-то другого фреймворка, - это то, что сам nodejs не может использоваться для большой распределенной системы, но, по крайней мере, в стиле MSA. Во всяком случае, мое мнение.
Raffaello