Комментарии 23
А чего просто Akka не вкрутили?
Используем Vert.x. Он лучше подходит для решения наших задач.
Интересно чем Akka не подошла.
Не рискну за автора отвечать, но предположу:
отсутствием нормальной библиотеки для http/web? Мы ведь понимаем, что spray — это классный прототип и блестящая идея, а akka-http до сих пор в каком-то не очень понятном состоянии?
Вообще, надо сказать, мне как выходцу и Scala-фанатику это не очень приятно писать, но для того, что описал автор (быстрая реализация хотелок заказчика), связка Akka + Scala + Play 2 (или любой другой фреймворк на этом месте) очень дорогая связка. Мало того, что технологии не совсем мейнстримовые, и разработчиков на Scala надо не только найти, но еще и заставить придерживаться более-менее одного код-стайла, так еще и сам стек куда-то в непонятную сторону поворачивает — Typesafe переименовался в LightBend, Scala 2.12 где-то еще в разработке, Akka Http в каком-то невменяемом состоянии, в Play2 впилили !!runtime Dependency Injection.
Оно конечно всё работает, но вот именно Скальность всего происходящего вызывает вопросы.
отсутствием нормальной библиотеки для http/web? Мы ведь понимаем, что spray — это классный прототип и блестящая идея, а akka-http до сих пор в каком-то не очень понятном состоянии?
Вообще, надо сказать, мне как выходцу и Scala-фанатику это не очень приятно писать, но для того, что описал автор (быстрая реализация хотелок заказчика), связка Akka + Scala + Play 2 (или любой другой фреймворк на этом месте) очень дорогая связка. Мало того, что технологии не совсем мейнстримовые, и разработчиков на Scala надо не только найти, но еще и заставить придерживаться более-менее одного код-стайла, так еще и сам стек куда-то в непонятную сторону поворачивает — Typesafe переименовался в LightBend, Scala 2.12 где-то еще в разработке, Akka Http в каком-то невменяемом состоянии, в Play2 впилили !!runtime Dependency Injection.
Оно конечно всё работает, но вот именно Скальность всего происходящего вызывает вопросы.
1. А что не так с runtime DI?
2. Я в одном из проектов вообще использую Akka.Net + Asp.Net WebApi2 + SignalR + C# :)))) очень хорошо себя показывает. И русурсы найти не сложно. Главное за пул реквестами смотреть.
2. Я в одном из проектов вообще использую Akka.Net + Asp.Net WebApi2 + SignalR + C# :)))) очень хорошо себя показывает. И русурсы найти не сложно. Главное за пул реквестами смотреть.
А Akka.Net уже вышел из беты?
1. Почти ничего, кроме того, что Scala — это compile-time typesafe language, в котором этот самый typesafe чуть ли не самая продаваемая и продвигаемая фича, а в одном из самых популярных веб-фреймворков используется runtime DI :)
А можно поподробнее про compile-time typesafe language :) И что вы вкладываете в понятие type-safety?
Насколько я понимаю, вы из .net?
В JVM есть такая приятная особенность — type erasure. Это значит, что информация о типах из дженериков вся теряется. Это справедливо для любого JVM-based языка. Вот пример из Java: http://stackoverflow.com/a/339708/1040070
Соответственно все штуки, которыми так богата Scala, вроде type constraints (http://stackoverflow.com/a/4870084/1040070), path-dependent types (http://stackoverflow.com/questions/2693067/what-is-meant-by-scalas-path-dependent-types), и тотальное выведение-приведение-проверка типов происходят во время компиляции. В runtime типы дженериков затерты. В Scala есть механизм typetags/classtags, который позволяет держать информацию о типах в runtime, но это скорее опция, и повсеместно оно не используется.
В общем всё это здорово работает и проверяется ровно до того момента, пока вместе компилируется.
Runtime DI подразумевает в свою очередь внедрения кода во время исполнения. Этот код также может быть написан на Scala и быть проверен тайпчекером, но результаты могут оказаться различными — например поменяли List[User] -> List[Profile]. Это вроде бы не сильно тревожно, если у нас полтора модуля для DI, но если мы собираем половину приложения через DI, то как-то это уже начинает не внушать оптимизма. При том, что за все эти тайпчеки мы по-прежнему платим временем во время сборки проекта, да и вообще, нафига городить все эти конструкции из безупречно-типизированного кода, который чуть ли не сам себя пишет (привет макросы из 2.12), если в итоге в рантайме мы будем втаскивать зависимости?
Всё конечно не так плохо, и Scala по прежнему работает, но, кажется последнее время свернула со своего труе-пути и пошла рука об руку с Java. А с учетом нововведений Java 8 возникает логичный вопрос — зачем всё вот это вот хозяйство, если в рантайме у нас зависимости, разработчиков всё еще не так просто найти, если есть Java 8, которая перекрывает 70% того, что есть в Scala, никуда не денется послезавтра и разработчиков под которую можно найти в любом селе необъятной?
В JVM есть такая приятная особенность — type erasure. Это значит, что информация о типах из дженериков вся теряется. Это справедливо для любого JVM-based языка. Вот пример из Java: http://stackoverflow.com/a/339708/1040070
Соответственно все штуки, которыми так богата Scala, вроде type constraints (http://stackoverflow.com/a/4870084/1040070), path-dependent types (http://stackoverflow.com/questions/2693067/what-is-meant-by-scalas-path-dependent-types), и тотальное выведение-приведение-проверка типов происходят во время компиляции. В runtime типы дженериков затерты. В Scala есть механизм typetags/classtags, который позволяет держать информацию о типах в runtime, но это скорее опция, и повсеместно оно не используется.
В общем всё это здорово работает и проверяется ровно до того момента, пока вместе компилируется.
Runtime DI подразумевает в свою очередь внедрения кода во время исполнения. Этот код также может быть написан на Scala и быть проверен тайпчекером, но результаты могут оказаться различными — например поменяли List[User] -> List[Profile]. Это вроде бы не сильно тревожно, если у нас полтора модуля для DI, но если мы собираем половину приложения через DI, то как-то это уже начинает не внушать оптимизма. При том, что за все эти тайпчеки мы по-прежнему платим временем во время сборки проекта, да и вообще, нафига городить все эти конструкции из безупречно-типизированного кода, который чуть ли не сам себя пишет (привет макросы из 2.12), если в итоге в рантайме мы будем втаскивать зависимости?
Всё конечно не так плохо, и Scala по прежнему работает, но, кажется последнее время свернула со своего труе-пути и пошла рука об руку с Java. А с учетом нововведений Java 8 возникает логичный вопрос — зачем всё вот это вот хозяйство, если в рантайме у нас зависимости, разработчиков всё еще не так просто найти, если есть Java 8, которая перекрывает 70% того, что есть в Scala, никуда не денется послезавтра и разработчиков под которую можно найти в любом селе необъятной?
Нужна была легковесная платформа, которая бы нативно поддерживала и java и js/nodejs. Где java-часть взяла бы на себя тяжелые вычисления и базовый функционал, а nodejs-часть была бы легко/дешево модифицируема под нужды конечного заказчика.
Можно и Vert.x. Просто странно при наличии Java разработчиков не использовать Akka или Vert.x, а зачем-то рисовать Actor Model на Node.js…
Часть прикладных задач проще решать написав модуль на Node.
Основной сервер (написанный на java) крутится на Vert.x шаря часть шины наружу на которую уже вешаются (событийно) модули написанные на nodejs и которые реализуют дополнительный функционал. Итого вычислительно тяжелую (и медленно меняющуюся по коду/функционалу) часть имеем на java с которой прозрачно интегрируется клиент-специфик часть написанная на nodejs. Обе части объедены в единую информационную экосистему шиной данных от Vert.x. Итого получается некий неоднородный java/nodejs кластер.
Извиняюсь, возможно за глупый вопрос.
>>обменивающихся между собой сообщениями через общую глобальную шину
что имеется ввиду, когда говорится о глобальной шине?
И все же хотелось бы подробнее узнать про эти акторы на nodeJS. Ваша статья и гугление немного вогнало в тупик.
>>обменивающихся между собой сообщениями через общую глобальную шину
что имеется ввиду, когда говорится о глобальной шине?
И все же хотелось бы подробнее узнать про эти акторы на nodeJS. Ваша статья и гугление немного вогнало в тупик.
Возможно, имеется в виду 0mq или rabbitmq.
что имеется ввиду, когда говорится о глобальной шине?
Vertx-eventbus
Модули NodeJS оформляются таким образом, чтобы не иметь зависимостей (в идеале вообще ни от кого). Обмениваются данными они не напрямую, а путем отправки сообщений через общую шину. Такие модули и называются акторами. При запуске инстанции конфигом определяется какие именно модули надо грузить.
Затем заворачиваем это все в кластер или запускаем на разных машинах и живем долго и счастливо.
Ойвей. Расскажите про акторы на ноде немного подробнее?
Что это такое и с чем его едят в сферическом вакууме понятно. Непонятны технические подробности реализации этого добра на node.js.
Насколько мне известно (а применительно к node.js я начал недавно в эту сторону копать), ничего толкового в духе erlang-а нету, причем по достаточно фундаментальным для node.js причинам. Прежде всего это пресловутая однопоточность выполнения JS. Не существует одного хорошего способа запустить thread: вроде бы был/есть node-threads-a-gogo, который через native код умеет делать что-то очень похожее на нити, но если присмотреться в багтрекер, то можно заметить, что многое добро из node.js в ней не работает (например TypedArrays). Вроде бы есть webworker-threads, но тоже не внушает оптимизма реализация, хотя штука, имхо, очень правильная и в духе ноды.
Cluster тоже не решение, потому что точно также блокирует интерпретатор (да, один из нескольких, запущенных в кластере, но тем не менее).
В общем нужно больше деталей. node.js в этом плане достаточно подходящая штука для написания акторов, но очень многих системных вещей не хватает, плюс их реализация таки идет вразрез с основной идеей node.js
Что это такое и с чем его едят в сферическом вакууме понятно. Непонятны технические подробности реализации этого добра на node.js.
Насколько мне известно (а применительно к node.js я начал недавно в эту сторону копать), ничего толкового в духе erlang-а нету, причем по достаточно фундаментальным для node.js причинам. Прежде всего это пресловутая однопоточность выполнения JS. Не существует одного хорошего способа запустить thread: вроде бы был/есть node-threads-a-gogo, который через native код умеет делать что-то очень похожее на нити, но если присмотреться в багтрекер, то можно заметить, что многое добро из node.js в ней не работает (например TypedArrays). Вроде бы есть webworker-threads, но тоже не внушает оптимизма реализация, хотя штука, имхо, очень правильная и в духе ноды.
Cluster тоже не решение, потому что точно также блокирует интерпретатор (да, один из нескольких, запущенных в кластере, но тем не менее).
В общем нужно больше деталей. node.js в этом плане достаточно подходящая штука для написания акторов, но очень многих системных вещей не хватает, плюс их реализация таки идет вразрез с основной идеей node.js
Cluster тоже не решение, потому что точно также блокирует интерпретатор
А зачем писать на Node что-то блокирующее? JS под это в принципе не заточен. Любую действие надо выполнять максимально быстро, все операции должны быть асинхронными — это основа программирования на JS, будь то браузерное приложение или сервер.
Достоинством акторов в данном случае является то, что мы можем запустить любое число инстанций сервера (используя например cluster) или разнести сервер на разные машины, которые абсолютно равны между собой (не считая мастера, который немного ровнее остальных).
При этом код остается неизменным, нагрузка размазывается по всем инстансам, повышается надежность (умер процесс либо забили либо перезапустили, если возможно) и т.д.
Надеюсь я ответил на вопрос.
Хороший вопрос)
А если вычисления есть? Вытаскивать их из ноды и рулить внешним процессом? Причем я не про числодробилку, а про что-то достаточно простое, но не отрабатывающее в течении милисекунды.
Для типичных веб-задач конечно всё это от лукавого, но тем не менее.
Насколько я понимаю под «акторами» на node.js в итоге подразумевалась пачка нодовых процессов, запущенных через cluster, и общающихся через некий внешний event-bus?
Тогда эту штуку конечно по-прежнему можно назвать акторами, но тогда и классы на Java акторы, потому что «получают сообщения» при вызове методов.
А если вычисления есть? Вытаскивать их из ноды и рулить внешним процессом? Причем я не про числодробилку, а про что-то достаточно простое, но не отрабатывающее в течении милисекунды.
Для типичных веб-задач конечно всё это от лукавого, но тем не менее.
Насколько я понимаю под «акторами» на node.js в итоге подразумевалась пачка нодовых процессов, запущенных через cluster, и общающихся через некий внешний event-bus?
Тогда эту штуку конечно по-прежнему можно назвать акторами, но тогда и классы на Java акторы, потому что «получают сообщения» при вызове методов.
А если вычисления есть? Вытаскивать их из ноды и рулить внешним процессом?
JS не такой медленный, как принято считать. Кроме того, большую часть задач можно разбить на более мелкие. Ну а если и это не сделать, у нас есть сервер на JAVA, который может взять на себя эту тяжеловесную задачу.
Насколько я понимаю под «акторами» на node.js в итоге подразумевалась пачка нодовых процессов, запущенных через cluster, и общающихся через некий внешний event-bus?
Нет. Под актором в данном случае подразумевается нодовский модуль(или группа модулей), общающихся через внешний event-bus. В рамках каждого процесса запущенного через cluster живет куча акторов. Вообще запуск через cluster не является обязательным, он нужен лишь для того, чтобы обеспечить большую производительность.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Эволюция сервера приложений на NodeJS