Да бросьте, кто сейчас пользуется наличными? Для меня сравнение Биткойна с банковской картой — наиболее актуальное. Банковская карта — это то, чем я пользуюсь каждый день. Если Биткойн претендует на то, чтобы быть полноценной валютой, он должен быть, по крайней мере, не хуже банковской карты по большинству показателей. Должен быть удобен в повседневной жизни, короче говоря.
Было приятно увидеть конструктивную критику Bitcoin. Добавлю свои пять копеек. Биткойн стал новой валютой — это свершившийся факт. Но пока он, к сожалению, проигрывает фиатным деньгам по целому ряду параметров. Из неупомянутых автором это, в первую очередь, безопасность и защита от случайной потери.
Если вы пользуетесь обычной банковской картой, то, согласитесь, сложно представить себе ситуацию, когда вы случайно потеряли деньги. Вы можете потерять карту, забыть пинкод, заплатить недобросовестному продавцу — во всех этих случаях доступ к вашим деньгам легко восстанавливается. Даже если у вас украли карту и расплатились ей за какую-нибудь крупную покупку, в большинстве случаев деньги вернуть можно. В случае хакерских атак на картсчета банки тоже, чаще всего, идут клиентам на встречу и возвращают деньги. Если же у вас Bitcoin, потерять случайно деньги слишком просто. Достаточно забыть пароль от своего кошелька. Есть множество других способов, все их объединяет одно: вам никто не поможет, деньги потеряны навсегда.
Ещё один момент (о котором автор упоминал): пока эта валюта не очень дружественна к пользователю. Вы реально должны разбираться, что под капотом, иначе можете сделать что-нибудь не то. Есть, например, такое явление, как "зависшие транзакции" — это когда пользователь установил слишком низкую цену за транзакцию, и никто не хочет её майнить, поскольку это недостаточно экономически выгодно. В итоге транзакция может висеть в мемпуле неделями, её не откатить, она не отваливается по таймауту. Есть разные ухищрения вроде "child-pays-for-parent", но, опять же, большинство неподготовленных людей в этом не разберётся, да и не должно разбираться.
Тем не менее, надеюсь, что сообществу удастся со временем сделать эту валюту более дружественной. В Биткойне есть механизм модификации протокола, он успешно применялся уже множество раз. Это обнадёживает.
Когда мы только начинали проект SAYMON, Erlang был одной из технологий, которую я рассматривал для бэкенда. Я с ним обязательно познакомлюсь по мере возможности.
По сравнению с другими платформами у Node.JS есть одно, на первый взгляд незаметное, преимущество: вы можете частично переиспользовать фронтэндеров для бэкенд задач. Часто бывает так, что для реализации задачи нужно сделать большой кусок UI и небольшой кусочек сервера (например, добавить простенький REST-метод). Когда этим занимается один и тот же человек, это происходит гораздо быстрее. В маленьких стартапчиках, как наш, это очень спасает.
По аналогии с фреймворком Drama, которым был вдохновлён Comedy. Ну, актёры, театр, драма, комедия...
Это классическое заблуждение. Переход от многопоточной системы к однопоточному event-loop не решает проблем, а лишь переводит их в другую плоскость.
Я с этим не согласен. В многопоточных системах есть и гонки потоков, и гонки ивентов/промисов. То есть, там есть и баги, связанные с многопоточностью, и баги, связанные с асинхронностью. В Node.JS мы имеем только баги второй разновидности. У нас нет проблем с visibility, например — когда мы ошибочно полагаем, что модификация переменной x видна и потоку A, и потоку B. У нас нет deadlock-ов. Их не может быть принципиально.
Я много занимался многопоточным программированием на Java и на C++. По моему опыту, скорость разработки на Node.JS в 2-4 раза выше, чем на Java, а с C++ я даже сравнивать боюсь.
Я на эту тему уже давал комментарий здесь. В нашем случае REST и Nginx — это лишь малая часть нашего приложения.
node-cluster — слишком низкоуровневое API, нам удобнее работать с ООП. Плюс не вынести на удалённые машины. Плюс нет из коробки внешней конфигурации. Плюс самому пилить respawn, если форкнутый процесс отвалился.
Насчёт приведения кода к асинхронному виду — в случае CPU-intensive задач вам это не поможет. В реальных проектах, таких как SAYMON, весь код вдрызг асинхронный, но процессорное время ему нужно так или иначе.
Перевести наш проект полностью на очереди на самом деле было бы более трудоёмко, чем внедрить акторы. Кстати, очереди сообщений могли бы служить низлежащим транспортом для обмена сообщений между акторами. Такая мысль была, и запросы есть, но реализовать пока не успели.
Пожалуйста, перестаньте называть обработчики запросов "ручками".
Я-то могу перестать (я просто в скобочках написал), но боюсь, что жаргон уже устоялся. Вы вряд ли сможете его изменить. Нужно принять и простить :)
Пока что есть только бенчмарки на коммуникацию между акторами, туда входит сериализация и обмен через IPC или loopback socket. Но сравнивать результаты пока не с чем. Думаю, в течение плутора-двух месяцев можно будет потестировать различные варианты сериализации и выбрать лучший + выставить опцию для конфигурирования пользовательской сериализации.
в кластере из четырех акторов можно добиться не более 4-х реально одновременно выполняющихся CPU-bound задач
Да, всё верно.
а почему таки не подпилили под интерфейс web workers?
Честно говоря, с Web-воркерами мало работал и мало про них знаю. Вижу что они, похоже, есть в Node.JS (https://www.npmjs.com/package/webworker-threads). Значит, можно сделать ещё один режим для акторов, в котором они запускаются в веб-воркерах!
По интерфейсу я, скорее, ориентировался на AKKA, поскольку это стандарт де-факто в мире акторов (уж не знаю, насколько они с Comedy в итоге похожи :) ). Во всяком случае, хотелось иметь максимально ООП-шный интерфейс, при котором ваши существующие классы легко превращаются в элегантные акторы.
eval() — это не единственный и не самый рекомендованный способ передачи определения актора. Можно предварительно разместить код проекта на удалённой машине и в качестве определения актора указывать путь к файлу (это как раз то, что рекомендуется). В этом случае, код определения будет подтянут через стандартный require().
comedy-node — это очень тупой процесс, который вообще ничего и никогда не знает про акторы. Всё, что он делает — слушает порт, по которому принимает запросы на создание актора. При каждом таком запросе он запускает подпроцесс, который как раз ответственен за создание актора и управление его жизненным циклом. Этот процесс от comedy-node полностью независим. Он слушает свой собственный порт и переживает смерть comedy-node.
В момент, когда я начинал разрабатывать Comedy, в Node.JS мире на тему акторов я нашёл только маленький экспериментальный фреймворк под названием Drama (собственно, он меня и вдохновил). Сейчас ещё нашёл nactor. В первом даже есть forked режим, который работает в самом простейшем случае (во втором, кажется, нет и этого). Ни в одном из этих ферймворков нет механизма внешнего конфигурирования акторов (только через код), не говоря уж о кластеризации, remote-режиме, поддержки инъекции ресурсов, кастомном маршаллинге, fault tolerance — проще перечислить, что в них есть, чем чего в них нет.
Если сравнивать с фреймфорками в других языках (c AKKA, например), то это, в принципе, отдельная статья :)
Как ни странно, Comedy не гуглится по запросу "actors nodejs". Печалька :(
Если найдёте какие-то другие фреймворки для акторов в Node.JS — пишите обязательно!
Хорошо, когда можно просто взять — и размножить приложение на N экземпляров. Это простой случай.
В случае же с нашим проектом акторы стали реальным спасением, поскольку в SAYMON HTTP-шный веб-сервер — это лишь один из большого множества модулей, слушающих информацию из сети либо обрабатывающих её в фоновом режиме. У нас есть Comet-сервер, обработчик MQTT-сообщений, обработчик SNMP-трапов, обработчик сообщений, приходящих по publish-subscribe от агентов, отправители E-mail и Telegram уведомлений, верификатор состояния модели и прочее. Размножить всё это на N экземпляров — отдельная большая фича, требующая серьёзных трудозатрат. А акторы позволяют более гранулярно отмаштабировать "горячие" модули и оставить в одном экземпляре то, что мы пока не хотим или не можем масштабировать.
Поскольку pm2 будет размножать корневой ("пусковой") процесс — а система акторов у вас создаётся, по-идее, именно там — то у нас получится несколько систем акторов, по одной на каждый корневой процесс. Никаких проблем с этим нет, если вас устраивает, что вместо одного дерева акторов у вас всегда будет лес из N деревьев.
можно дебажить отдельный актор изолированно при запуске его unit-тестов
можно дебажить систему целиком в in-memory режиме (для этого в параметрах системы акторов есть специальная булевская опция debug; она форсит in-memory режим для всех акторов, включает длинные стектрейсы в bluebird и выставляет уровень логирования в debug)
Полноценно дебажить систему с forked или remote акторами с подключением дебаггера не получится. Здесь вам в помощь только логгер и console.log. Возможно, в дальнейшем удастся добавить интроспекцию.
Они работают быстрее ввиду простых факторов вроде компиляции.
Если говорить про NodeJS, то он компилирует JavaScript в нативный код во время запуска (с заглушками, правда). Компиляция в JVM-языках — это компиляция в байт-код. Чтобы он стал нативным кодом, необходим «прогрев» — JIT компилятор должен сообразить, что этот код горячий (вызывается часто), и только после этого происходит компиляция в нативный код. Это вовсе не является преимуществом в плане производительности.
Статья прикольная! Есть над чем задуматься. Картинки очень повеселили!
В целом согласен с тем, что вы говорите, но тут есть и обратная сторона. Людям иногда приходится идти навстречу технологиям. Пример — телефонные номера. Когда появились телефоны, звонить по имени не было возможности. Пришлось пользоваться цифрами. И ничего, до сих пор пользуемся. Потому что надо. Потому что без телефона — никак.
Или другой пример: Wi-Fi. Отличная технология! Зашёл в кафешку, выбрал хот-спот, ввёл пароль — и ты в Интернете! Только чтобы это сделать, человеку нужно знать, что такое Wi-Fi, и как его включить в своём телефоне. Но человек готов в этом разобраться, потому что без Интернета — никак.
QR-коды в определённом смысле похожи на Wi-Fi. Человеку просто нужно знать, что такое QR-код. И если бы производители телефонов встраивали сканер QR-кода в стандартную программу для фотографирования — то проблем бы не было вообще никаких. Направить камеру на квадратик — это ещё проще, чем подключиться к Wi-Fi. Но надо ли оно? Есть ли реальная потребность в технологии? От этого зависит, будут ли использоваться QR-кодами, или нет.
Вы, наверное, имеете в виду не кредитную, а дебетовую карту. Да, здесь Биткойн, пожалуй, выигрывает.
Да бросьте, кто сейчас пользуется наличными? Для меня сравнение Биткойна с банковской картой — наиболее актуальное. Банковская карта — это то, чем я пользуюсь каждый день. Если Биткойн претендует на то, чтобы быть полноценной валютой, он должен быть, по крайней мере, не хуже банковской карты по большинству показателей. Должен быть удобен в повседневной жизни, короче говоря.
Наличные карте уже давно проиграли.
Было приятно увидеть конструктивную критику Bitcoin. Добавлю свои пять копеек. Биткойн стал новой валютой — это свершившийся факт. Но пока он, к сожалению, проигрывает фиатным деньгам по целому ряду параметров. Из неупомянутых автором это, в первую очередь, безопасность и защита от случайной потери.
Если вы пользуетесь обычной банковской картой, то, согласитесь, сложно представить себе ситуацию, когда вы случайно потеряли деньги. Вы можете потерять карту, забыть пинкод, заплатить недобросовестному продавцу — во всех этих случаях доступ к вашим деньгам легко восстанавливается. Даже если у вас украли карту и расплатились ей за какую-нибудь крупную покупку, в большинстве случаев деньги вернуть можно. В случае хакерских атак на картсчета банки тоже, чаще всего, идут клиентам на встречу и возвращают деньги. Если же у вас Bitcoin, потерять случайно деньги слишком просто. Достаточно забыть пароль от своего кошелька. Есть множество других способов, все их объединяет одно: вам никто не поможет, деньги потеряны навсегда.
Ещё один момент (о котором автор упоминал): пока эта валюта не очень дружественна к пользователю. Вы реально должны разбираться, что под капотом, иначе можете сделать что-нибудь не то. Есть, например, такое явление, как "зависшие транзакции" — это когда пользователь установил слишком низкую цену за транзакцию, и никто не хочет её майнить, поскольку это недостаточно экономически выгодно. В итоге транзакция может висеть в мемпуле неделями, её не откатить, она не отваливается по таймауту. Есть разные ухищрения вроде "child-pays-for-parent", но, опять же, большинство неподготовленных людей в этом не разберётся, да и не должно разбираться.
Тем не менее, надеюсь, что сообществу удастся со временем сделать эту валюту более дружественной. В Биткойне есть механизм модификации протокола, он успешно применялся уже множество раз. Это обнадёживает.
Когда мы только начинали проект SAYMON, Erlang был одной из технологий, которую я рассматривал для бэкенда. Я с ним обязательно познакомлюсь по мере возможности.
По сравнению с другими платформами у Node.JS есть одно, на первый взгляд незаметное, преимущество: вы можете частично переиспользовать фронтэндеров для бэкенд задач. Часто бывает так, что для реализации задачи нужно сделать большой кусок UI и небольшой кусочек сервера (например, добавить простенький REST-метод). Когда этим занимается один и тот же человек, это происходит гораздо быстрее. В маленьких стартапчиках, как наш, это очень спасает.
Блин, так из-за этой софтины теперь GitHub закроют.
А не написать ли вам статью про дедлоки и лайвлоки в Node.JS? Я бы прочитал с огромным удовольствием!
По аналогии с фреймворком Drama, которым был вдохновлён Comedy. Ну, актёры, театр, драма, комедия...
Я с этим не согласен. В многопоточных системах есть и гонки потоков, и гонки ивентов/промисов. То есть, там есть и баги, связанные с многопоточностью, и баги, связанные с асинхронностью. В Node.JS мы имеем только баги второй разновидности. У нас нет проблем с visibility, например — когда мы ошибочно полагаем, что модификация переменной
xвидна и потокуA, и потокуB. У нас нет deadlock-ов. Их не может быть принципиально.Я много занимался многопоточным программированием на Java и на C++. По моему опыту, скорость разработки на Node.JS в 2-4 раза выше, чем на Java, а с C++ я даже сравнивать боюсь.
Я на эту тему уже давал комментарий здесь. В нашем случае REST и Nginx — это лишь малая часть нашего приложения.
node-cluster— слишком низкоуровневое API, нам удобнее работать с ООП. Плюс не вынести на удалённые машины. Плюс нет из коробки внешней конфигурации. Плюс самому пилить respawn, если форкнутый процесс отвалился.Насчёт приведения кода к асинхронному виду — в случае CPU-intensive задач вам это не поможет. В реальных проектах, таких как SAYMON, весь код вдрызг асинхронный, но процессорное время ему нужно так или иначе.
Перевести наш проект полностью на очереди на самом деле было бы более трудоёмко, чем внедрить акторы. Кстати, очереди сообщений могли бы служить низлежащим транспортом для обмена сообщений между акторами. Такая мысль была, и запросы есть, но реализовать пока не успели.
Я-то могу перестать (я просто в скобочках написал), но боюсь, что жаргон уже устоялся. Вы вряд ли сможете его изменить. Нужно принять и простить :)
Крутяк! Будем реализовывать!
Оверхед станет понятен как только:
Пока что есть только бенчмарки на коммуникацию между акторами, туда входит сериализация и обмен через IPC или loopback socket. Но сравнивать результаты пока не с чем. Думаю, в течение плутора-двух месяцев можно будет потестировать различные варианты сериализации и выбрать лучший + выставить опцию для конфигурирования пользовательской сериализации.
Привет!
Да, всё верно.
Честно говоря, с Web-воркерами мало работал и мало про них знаю. Вижу что они, похоже, есть в Node.JS (https://www.npmjs.com/package/webworker-threads). Значит, можно сделать ещё один режим для акторов, в котором они запускаются в веб-воркерах!
По интерфейсу я, скорее, ориентировался на AKKA, поскольку это стандарт де-факто в мире акторов (уж не знаю, насколько они с Comedy в итоге похожи :) ). Во всяком случае, хотелось иметь максимально ООП-шный интерфейс, при котором ваши существующие классы легко превращаются в элегантные акторы.
eval()— это не единственный и не самый рекомендованный способ передачи определения актора. Можно предварительно разместить код проекта на удалённой машине и в качестве определения актора указывать путь к файлу (это как раз то, что рекомендуется). В этом случае, код определения будет подтянут через стандартный require().comedy-node — это очень тупой процесс, который вообще ничего и никогда не знает про акторы. Всё, что он делает — слушает порт, по которому принимает запросы на создание актора. При каждом таком запросе он запускает подпроцесс, который как раз ответственен за создание актора и управление его жизненным циклом. Этот процесс от comedy-node полностью независим. Он слушает свой собственный порт и переживает смерть comedy-node.
В момент, когда я начинал разрабатывать Comedy, в Node.JS мире на тему акторов я нашёл только маленький экспериментальный фреймворк под названием Drama (собственно, он меня и вдохновил). Сейчас ещё нашёл nactor. В первом даже есть forked режим, который работает в самом простейшем случае (во втором, кажется, нет и этого). Ни в одном из этих ферймворков нет механизма внешнего конфигурирования акторов (только через код), не говоря уж о кластеризации, remote-режиме, поддержки инъекции ресурсов, кастомном маршаллинге, fault tolerance — проще перечислить, что в них есть, чем чего в них нет.
Если сравнивать с фреймфорками в других языках (c AKKA, например), то это, в принципе, отдельная статья :)
Как ни странно, Comedy не гуглится по запросу "actors nodejs". Печалька :(
Если найдёте какие-то другие фреймворки для акторов в Node.JS — пишите обязательно!
Хорошо, когда можно просто взять — и размножить приложение на N экземпляров. Это простой случай.
В случае же с нашим проектом акторы стали реальным спасением, поскольку в SAYMON HTTP-шный веб-сервер — это лишь один из большого множества модулей, слушающих информацию из сети либо обрабатывающих её в фоновом режиме. У нас есть Comet-сервер, обработчик MQTT-сообщений, обработчик SNMP-трапов, обработчик сообщений, приходящих по publish-subscribe от агентов, отправители E-mail и Telegram уведомлений, верификатор состояния модели и прочее. Размножить всё это на N экземпляров — отдельная большая фича, требующая серьёзных трудозатрат. А акторы позволяют более гранулярно отмаштабировать "горячие" модули и оставить в одном экземпляре то, что мы пока не хотим или не можем масштабировать.
Поскольку pm2 будет размножать корневой ("пусковой") процесс — а система акторов у вас создаётся, по-идее, именно там — то у нас получится несколько систем акторов, по одной на каждый корневой процесс. Никаких проблем с этим нет, если вас устраивает, что вместо одного дерева акторов у вас всегда будет лес из N деревьев.
Для дебага есть такие возможности:
debug; она форсит in-memory режим для всех акторов, включает длинные стектрейсы в bluebird и выставляет уровень логирования в debug)Полноценно дебажить систему с forked или remote акторами с подключением дебаггера не получится. Здесь вам в помощь только логгер и
console.log. Возможно, в дальнейшем удастся добавить интроспекцию.Если говорить про NodeJS, то он компилирует JavaScript в нативный код во время запуска (с заглушками, правда). Компиляция в JVM-языках — это компиляция в байт-код. Чтобы он стал нативным кодом, необходим «прогрев» — JIT компилятор должен сообразить, что этот код горячий (вызывается часто), и только после этого происходит компиляция в нативный код. Это вовсе не является преимуществом в плане производительности.
В целом согласен с тем, что вы говорите, но тут есть и обратная сторона. Людям иногда приходится идти навстречу технологиям. Пример — телефонные номера. Когда появились телефоны, звонить по имени не было возможности. Пришлось пользоваться цифрами. И ничего, до сих пор пользуемся. Потому что надо. Потому что без телефона — никак.
Или другой пример: Wi-Fi. Отличная технология! Зашёл в кафешку, выбрал хот-спот, ввёл пароль — и ты в Интернете! Только чтобы это сделать, человеку нужно знать, что такое Wi-Fi, и как его включить в своём телефоне. Но человек готов в этом разобраться, потому что без Интернета — никак.
QR-коды в определённом смысле похожи на Wi-Fi. Человеку просто нужно знать, что такое QR-код. И если бы производители телефонов встраивали сканер QR-кода в стандартную программу для фотографирования — то проблем бы не было вообще никаких. Направить камеру на квадратик — это ещё проще, чем подключиться к Wi-Fi. Но надо ли оно? Есть ли реальная потребность в технологии? От этого зависит, будут ли использоваться QR-кодами, или нет.