Содержание
| Node.js | |
|---|---|
| Тип | событийно-ориентированный язык программирования[d] |
| Разработчик | Node.js Foundation[d] |
| Написана на | C++[2] , JavaScript и Си |
| Операционная система | macOS , GNU/Linux [d] , SmartOS , FreeBSD , Microsoft Windows , AIX и Android[3] |
| Первый выпуск | 27 мая2009[1] |
| Последняя версия |
|
| Состояние | активное |
| Лицензия | лицензия X11 [d][5] |
| Сайт | nodejs.org |
| Медиафайлы на Викискладе | |
Node или Node.js — программная платформа, основанная на движке V8 (транслирующем JavaScript в машинный код), превращающая JavaScript из узкоспециализированного языка в язык общего назначения. Node.js добавляет возможность JavaScript взаимодействовать с устройствами ввода-вывода через свой API (написанный на C++), подключать другие внешние библиотеки, написанные на разных языках, обеспечивая вызовы к ним из JavaScript-кода. Node.js применяется преимущественно на сервере, выполняя роль веб-сервера, но есть возможность разрабатывать на Node.js и десктопные оконные приложения (при помощи NW.js, AppJS или Electron для Linux, Windows и macOS) и даже программировать микроконтроллеры (например, tessel и espruino). В основе Node.js лежит событийно-ориентированное и асинхронное (или реактивное) программирование с неблокирующим вводом/выводом.
Содержание
История [ править | править код ]
В 1996 году в компании Netscape были попытки создания серверного JavaScript (Server-s >[6] [7] , однако технология не получила распространения.
Node.js разработал Райан Даль (англ. Ryan Dahl ) в 2009 году после двух лет экспериментирования над созданием серверных веб-компонентов. В ходе своих исследований он пришёл к выводу, что вместо традиционной модели параллелизма на основе потоков следует обратиться к событийно-ориентированным системам. Эта модель была выбрана из-за простоты, низких накладных расходов (по сравнению с идеологией «один поток на каждое соединение») и быстродействия. Целью Node является предложить «простой способ построения масштабируемых сетевых серверов».
Разработка Node.js спонсируется компанией Joyent ( англ. ) .
В декабре 2014 года был создан форк io.js.
В мае 2015 года было принято решение о слиянии io.js и Node.js и дальнейшем развитии под эгидой Node.js Foundation. [8]
8 сентября 2015 года вышел Node.js v4.0.0 как результат слияния Node.js v0.12.7 и io.js v3.3.0. [9] [10]
Важными событиями в развитии платформы стало появление Atomics и SharedArrayBuffer в Node.js 9, а так же worker_threads в Node.js 10.5 (и существенное развитие в Node.js 12). [11] Это позволило создавать многопоточные параллельные приложения, реализовывать примитивы параллельного программирования и работать с разделяемой памятью. [12]
Примеры кода [ править | править код ]
Создание и запуск HTTP-сервера на Node.js, выдающего Hello, world!:
Другой пример скрипта, создающего TCP-сервер, который прослушивает порт 8000 и выводит на экран всё, что вводит пользователь:
Дополнительные пакеты сторонних разработчиков [ править | править код ]
В состав Node.js входит собственный установщик пакетов npm. Установка производится при помощи команды:
Все доступные для установки пакеты и их краткое описание:
Этой же командой можно производить выборочный поиск пакетов.
Содержание статьи
Посторонись, пресловутый PHP! Долой Java! Старичок Perl, тебе так вообще давно пора на пенсию. И как же вы уже достали, попсовые Ruby и Python! Все эти давно знакомые технологии уже не торкают. Зато сегодня мы посмотрим на чрезвычайно прогрессивный подход, когда для написания серверного кода используется… JavaScript.
Есть идея для стартапа. Теперь вопрос: на чем его писать? Конечно, есть всеми любимый РНР — что может быть легче для веб-сайта! Но скажи честно, как-то не тянет, правда? Ведь чтобы сделать что-то стоящее, голого РНР не хватит. Сразу придется прикручивать еще и AJAX, чтобы данные незаметно подгружались без обновления всей страницы целиком, да и это не решит всех проблем. О том, что PHP не так хорош, ты задумаешься в тот самый момент, когда к тебе разом ломанется много народа. А все потому что РНР (как и подавляющее большинство других языков, на которых строят сайты) даже в нашем, черт подери, двадцать первом веке, работают по классической схеме "запрос-ответ". Запрос страницы заставляет веб-сервер поднять указанный скрипт, выполнить его (линейно, строка за строкой весь твой код), а результат возвратить браузеру клиента. После этого скрипт "умирает", а следующий же запрос запустит всю эту адскую машинку заново. А если таких запросов одновременно тысяча? Старый добрый подход называется CGI (интерфейс взаимодействия веб-сервера и интерпретатора языка, на котором написана страница). Хитрые надстройки вроде FastCGI расширяют протокол, позволяя избежать выгрузки скрипта после первого запроса. Таким образом, когда второй пользователь запросит ту же страницу, для него будет уже все готово, останется только выполнить скрипт с новыми параметрами. Но все эти ухищрения — все равно не то.
Что такое хорошо, а что такое плохо
Многие разработчики всегда считали JavaScript просто "примочкой" к браузеру, эдаким недоязыком, который годится разве что для управления формами и манипулирования DOM-деревом веб-страницы. Некоторые до сих пор думают, что "java" в названии что-то да значит! 🙂 Действительно, язык очень простой. Впрочем, настоящие программисты давно научились творить с его помощью чудеса, предоставив нам потрясающе удобные онлайн-сервисы, которыми мы ежедневно пользуемся. Многие из таких профи пошли дальше и, трезво посмотрев на сам язык и его возможности, особенно по части работы с событиями, решили: а что если на JavaScript написать сервер? Ты получаешь возможность написать на одном и том же языке все части сайта: что серверную часть, что саму клиентскую страничку. Кроме того, JS отлично, просто идеально подходит для разных веб-штучек. Он очень простой и одновременно гибкий, что позволяет писать код в разных парадигмах: от обычного процедурного до ООП в смеси с функциональным стилем. А главное — это тотальная асинхронность. Это значит, что твой код будет выполняться не последовательно, как в случае с PHP/Perl-скриптами, а именно в тот момент, когда для него будут готовы все данные. Ведь для веба не надо большой вычислительной мощности — большую часть времени сервер ожидает событий вроде получения данных формы, выборки из базы данных или, что еще хуже, ответа на запрос к другому серверу. Обычный РНР-скрипт в такое время простаивает, а значит, простаивает весь поток, не позволяя серверу задействовать его для других пользователей. В такой ситуации не спасает даже Nginx. В случае с JavaScript ты просто указываешь, какую функцию необходимо выполнить, когда произойдет определенное событие, и все. В это время другой код может спокойно выполняться. Такая функция называется callback, или обработчик событий. Хотя писать действительно сложный код в таком стиле немного неудобно, особенно если твоя функция зависит от нескольких событий сразу, но и для этого уже придумали свои фреймворки, зачастую гораздо более мощные и элегантные, чем все эти РНР/Ruby/Python.
А к чему она вообще, эта асинхронность?
Для примера ограничений последовательного выполнения кода рассмотрим два типовых примера кода на PHP и JavaScript, выполняющих одно и то же. Начнем с любимого PHP:
$result = $db->fetchOne(‘SELECT user_name FROM user_accounts WHERE > echo ‘Мое имя: ‘ . $result . ‘;’;
В первой строке мы посылаем простой SQL-запрос к БД на выборку имени пользователя, у которого >
db.query(‘SELECT user_name FROM user_accounts WHERE > <
if (!err) sys.log(‘Мое имя: ‘ + res);
>);
sys.log(‘Продолжаем выполнение’);
Тут опять же создается запрос к базе данных, однако кроме самого SQL-выражения в запросе передается еще и функция-обработчик (callback). Эта функция будет вызвана именно тогда, когда придет ответ от базы данных, а до этого момента выполнение скрипта ни в коем случае не будет стопориться. Для примера в следующей строке мы просто выводим строку в консоль, чтобы показать, что выполнение сценария продолжается сразу после формирования запроса, не ожидая его завершения. Собственно, в основе любого варианта серверного JavaScript заложена концепция событий и callback’ов, то есть обработчиков событий. Ты можешь описывать собственные события. Тогда ход выполнения приложения будет зависеть от событий, которые возникают в результате активности пользователя на странице ("форма заполнена" или "новое сообщение" и т.д.) или генерируются внутри самого сервера (как, например, в случае с обращением к базе данных). Те действия, которые необходимо выполнять в случае наступления событий, описываются внутри функций обработчиков событий.
Движок, вот в чем вопрос
Короче говоря, использовать JavaScript не только для клиентской части, но и на серверной стороне — это хорошо и даже приятно. Другой вопрос — каким образом это возможно осуществить? Сегодня есть четыре основных движка, которые используются на серверах.
Rhino — движок от компании Mozilla, написанный на Java и поддерживающий последнюю 1.7 версию стандарта JS, который к тому же дополняет язык собственными расширениями и объектами. Основным преимуществом движка является работа поверх стандартной JVM, а значит, его можно использовать в любой среде, где работает Java. Другими словами, можно применять современные веб-серверы типа jetty, но при этом писать на любимом JS. Кстати, Rhino применяют на облачном хостинге от Google! А вот с производительностью сложнее. Она зависит, с одной стороны, от движка и применяемых там технологий, вроде JIT-компиляции, и от работы самой Java-машины. Кстати, многие тестеры, которые говорят, что Rhino очень медленный, забывают, что движок имеет два режима работы: интерпретации, когда скрипт каждый раз преобразуется в Java байт-код (аналогично PHP), и компиляции, когда такое преобразование происходит только раз, а потом многократно исполняется. Первый режим выгоден, когда ты отлаживаешь код, который меняется каждую минуту, второй больше подходит для рабочей версии проекта, работающей под нагрузкой.
SpiderMonkey — еще один движок от Mozilla, на этот раз на C. Кстати, это вообще первый в мире движок JS, написанный еще в Netscape — сегодня он открыт и используется в таких популярных продуктах как Firefox, Adobe Acrobat и даже в одном из эмуляторов серверов онлайн-игры Ultima Online. Далее разработчики сильно модифицировали его, добавив компиляцию JS напрямую в ассемблерный код, и переименовали в TraceMonkey — именно этот движок используется в ветке 3.6 Firefox’а. В основном SpiderMonkey используют в ПО, которое написано на С/С++ и нуждается в скриптовом языке. Из известных продуктов: Comet-сервер APE, noSQL БД CouchDB, серверная платформа Jaxer и модуль к Apache mod_js.
Futhark — это движок от Opera, который, кроме браузера, используется в их инновационном сервисе Unite (типа встроенный сервер в каждом браузере), а также на их серверах, обслуживающих мобильный браузер Opera Mini. Жаль, что движок закрыт, и его пока нигде за пределами самой Opera не применяют.
V8 — движок от Google, который используется в Chrome и является основой будущей Chrome OS. Сегодня это самый крутой, быстрый и мощный движок, в котором JS-код напрямую преобразуется в ассемблер целевого процессора, что позволяет обойти по скорости все остальные движки. Кроме этого гугловцы используют множество ухищрений для оптимизации, хранят в памяти скомпилированный код, оптимизируют его на лету (например, удаляют блоки кода, которые по решению компилятора вообще не могут быть задействованы, и т.п.). На базе этого движка построена самая популярная и быстроразвивающаяся серверная платформа — Node.JS.
Node.JS
Вероятно, именно после выхода Chrome разработчики смекнули, что такой быстрый движок можно успешно использовать и на сервере. Первым опытом стал проект V8cgi, который просто позволял писать серверные сценарии, работающие с любым веб-сервером по стандартному протоколу CGI. Дальнейшие эксперименты привели к рождению проекта Node.JS — полностью самостоятельной платформы, включающей, кроме движка, встроенный сервер (HTTP и TCP/UDP/Unix-soket) и базовый набор библиотек, а также предоставляющей полностью асинхронную работу с файлами и сетевыми устройствами.
Проект развивается настолько быстро и активно, что уже сейчас готов к промышленному использованию. Это, в частности, доказывает опыт парней из Plurk (азиатский аналог твиттера), которые полностью перенесли свой comet-сервер, изначально написанный на Java и солидном JBoss Netty, на Node.JS и, по отзывам, сократили потребление памяти буквально на гигабайты. А масштабы у них еще те — более сотни тысяч одновременных соединений.
Запустить HTTP-сервер, способный обрабатывать асинхронно тысячи подключений — это несколько строк кода:
var sys = require(‘sys’), http = require(‘http’);
http.createServer(function (req, res)
<
res.writeHead(200, <‘Content-Type’: ‘text/plain’>);
res.end(‘Hello Worldn’);
>).listen(80, "127.0.0.1");
sys.puts(‘Server running at http://127.0.0.1:80/’);
Чтобы запустить сервер, скопируй код в файл example.js и укажи его при запуске демона node:
% node example.js
Server running at http://127.0.0.1:80/
Маленький тест провести очень просто. Можно взять программу Apache Bench — очень простую тулзу для проведения нагрузочного тестирования, и запустить ее: running "ab -n 1000 -c 100 ‘http://127.0.0.1:80/’". Таким образом, бенчмарк будет "обстреливать" сервер тысячами запросов, используя 100 одновременных подключений. На моем ноутбуке сервер выдержал больше 3000 запросов в секунду. Это очень много!
Сам сервер написан на C++ и совсем немножко на ассемблере, однако большая часть библиотек из дистрибутива разработана на JavaScript. В состав базового набора сервера входят только основные функции, остальное оставлено на плечах разработчиков, которые уже написали сотни разных библиотек и фреймворков. Впрочем, молодость проекта дает о себе знать: многих привычных для других решений модулей еще нет, а у многих библиотек текущая версия — 0.0.1, что не придает уверенности в их стабильности. Некоторые тривиальные задачи могут вообще не иметь готового к закачке решения, но бывает и наоборот — количество реализаций, зачастую радикально разных по архитектуре, исчисляется десятками (доступ к базе MySQL, например). Хотя большинство библиотек написано на чистом JavaScript, есть и такие, что требуют компиляции модуля к серверу, что обещает гораздо большую скорость — они просто расширяют стандартный API сервера.
Готовые наработки для серверного JavaScript
Конечно, ты можешь писать код с чистого листа, что и делают многие правильные программисты. Однако немало из таких правильных программистов создали для себя удобные каркасы и наметки, которые теперь постоянно используют и предлагают всем желающим в виде фреймворков и спецификаций. Если ты всерьез решил использовать серверный JS, то это отличный способ облегчить себе жизнь.
Narwhal — мощное решение, работающее поверх многих JS-движков. Таким образом, программистам не надо париться по поводу различия различных серверов — они могут просто писать код.
CommonJS — попытка стандартизировать платформу и дать общий API для всех движков, предлагая низкоуровневый API, а также API для подключения различных готовых модулей.
JSGI (JavaScript gate interface) — разработан специальный протокол взаимодействия связи веб-демона и серверных сценариев на JavaScript. Увы, спецификацию пока полностью поддерживает только проект Rhino в окружении сервера jetty.
Особенности Node.JS
Основной особенностью Node, кроме полной асинхронности, является его однопоточная модель. Другими словами, все операции выполняются в одном и том же потоке ОС, даже если у твоего сервера тысяча одновременных пользователей. Правда, доступно создание дочерних процессов и низкоуровневое управление исполнением скриптов (загрузка, компиляция, работа с ассемблерным кодом, исполнение). Для реализации многопоточности и задействования всех ядер современных процессоров рекомендуется просто загружать несколько копий приложения, но можно взять на вооружение WebWorker из стандарта HTML5 и распределить работу приложения по нескольким дочерним процессам. Не думай, что раз нет многопоточности — это тормоз и отстой. Вспомни, что веб-приложение делает полезную работу очень быстро, а большую часть времени просто ожидает чего-то (данных от базы, от memcached’а или новомодной NoSQL-базы), либо просто держит в памяти открытые соединения для Comet’а, поэтому в одном потоке можно обработать и десяток тысяч, не прибегая к кластеризации.
Второй особенностью архитектуры Node является событийность. Почти каждая операция имеет коллбэки, генерирует событие, а пользователю доступен объект EventEmiter, через который можно буквально одной строкой генерировать свои события (это несложно, ведь событие — это просто строка с названием, а также список параметров, которые передаются в обработчик).
Сам по себе Node построен вокруг EventLoop — глобального цикла обработки событий, который на каждом тике проверяет, готовы ли данные для какого-либо из определенных пользователем коллбэков. Если данные есть, начинается выполнение кода. Если не осталось больше кода — ожидаем следующего вызова. Цикл выполняется вне JS, а в самом движке, написанном на C, вследствие чего это происходит очень и очень быстро (порядка сотен тысяч раз в секунду). Что-то типа бесконечного цикла. В дополнение к этому в сервер встроен очень эффективный сборщик мусора (GC), поэтому даже тысячи подключений не вызывают переполнения памяти и падения сервера. Node.JS обладает встроенной родной системой работы с событиями.
Простейший Steaming-сервер
Попробуем написать простой, но в тоже время полезный пример, который в реальном времени будет выдавать пользователю полезную информацию без перезагрузки страницы. Вот идея для нашего приложения — брать новые данные, которые добавляются в текстовый лог, и выводить их в реальном времени на веб-странице:
Разработать веб-приложение с хитрой бизнес-логикой и возможностью использовать один код для расчетов как на клиенте так и на сервере.
Java не рассматривается, поскольку:
1. уже существует веб-версия этого приложения и есть пользователи, которые привыкли использовать это приложение через браузер, без установки какого-либо дополнительного ПО, в том числе и с планшетов;
2. есть команда веб-разработчиков, нет команды Java разработчиков.
Серверная часть изначально работает на PHP, но в процессе разработки приложения был выявлен существенный недостаток подхода с разными языками на клиенте и сервере: чтобы приложение было более отзывчивым иногда необходимо выполнять одинаковые вычисления как на сервере так и на клиенте, в связи с этим приходится поддерживать в два раза больше кода, что приводит к различным багам и неточностям.
Расскажите, пожалуйста, о своем опыте использования node.js в качестве сервера для приложений со сложной бизнес-логикой. Какие технологии/фреймворки использовали, на какие подводные камни натолкнулись?
- Вопрос задан более трёх лет назад
- 7847 просмотров
По моему опыту, nodejs — удобная, стабильная и быстрая штука, имеющая отличное сообщество и много хороших библиотек в npm. Преимущества можно перечислять долго, лучше сразу перейти к проблемам.
— Сложно найти готовых к работе толковых программистов, даже среди фронтендщиков. Но можно обучить. На обучение и понимание среды nodejs, API, асинхронности, замыканий, калбэков, событий, функционального подхода — уходит примерно месяц-два.
— Библиотеки из форнтендов использовать можно, но только если они грамотно написаны и оптимизированы для перманентной работы. Иначе есть риск, что они сожрут всю память или повесятся.
— Сервер nodejs обычно однопоточный, со всеми вытекающими. Имеется возможность форкать и открывать дочерные процессы, на это нужны дополнительные затраты труда. Но это требуется только в исключительных случаях.
— Код пишется в основном легко, если следовать чёткому стандарту, который обычно навязывается используемым фреймворком. Однако javascript, ввиду своей нестрогости, неустойчив к коррозии, в спешке или по неопытности можно наделать рака и превратить жизнь своей команды в ад.
— При сложной логике со множеством вызовов можно без злого умысла нагородить «лестниц» из калбеков. Однако, проблема решается разными вариантами библиотек управления задачами (async, Q, и т.д.). Вообще лучше делать максимальную декомпозицию кода, создавать бесчисленные функции внутри функций — не очень хорошая практика.
По поводу камней:
— Обычно, всякие руководства и мануалы типа «hello world» используют один сокет для соединения с БД. На практике оказалось, что если этот сокет зависает под тяжёлым запросом, то все остальные запросы прилежно ждут его освобождения. Поэтому первое, что нужно сделать в новом проекте — это подключить database connection pool.
— Случилось так, что количество одновременных подключений к серверу перевалило за тысячу, и внезапно возникли необъяснимые аномалии и отказы. Как выяснилось, страшного ничего не произошло, и нужно было просто в операционной системе разрешить открывать на порядок больше файловых/сокетных дескрипторов.
— Память для nodejs лучше ограничивать ключами запуска и отдавать больше для БД (если они на одной машине). В противном случае nodejs не спешит запусктать сборщик мусора (это ведь затратная операция) и разрастается.
— Перезагрузки nodejs из-за внезапных падений от багов решаются специальными библиотеками, например forever.
— Чтобы nodejs не вылетал из-за исключений, нужно ставить глобальный обработчик uncaughtException, который пишет их в лог или сразу шлёт на мыло ответственному лицу.
— Нужно не забывать отвязыватсь обработчики от событий по окончании работы подписанного на событие объекта (removeListener()).
По поводу фреймворков, используем express, потому что он красивый, простой и мы к нему привыкли.