Что такое Node.js?

Я не полностью понимаю, что Node.js. Может быть, потому что я в основном веб-разработчик бизнес-приложений. Что это такое и каково его использование?

Правильно ли я понимаю? Если да, то каковы преимущества событий ввода-вывода, это просто больше для concurrency материала? Кроме того, является ли направление Node.js стать основой, например, моделью на основе JavaScript (на основе V8)?

Ответы

Ответ 2

Я использую Node.js на работе и считаю его очень мощным. Вынужденный выбрать одно слово для описания Node.js, я бы сказал "интересно" (что не является чисто положительным прилагательным). Сообщество живое и растет. JavaScript, несмотря на его странности, может быть отличным языком для кодирования. И вы ежедневно переосмыслите свое собственное понимание "лучшей практики" и шаблонов хорошо структурированного кода. Там огромная энергия идей, втекающих в Node.js прямо сейчас, и работающая в ней подвергает вас всему этому мышлению - большой умственной тяжелой атлетике.

Node.js в производстве определенно возможно, но далеко от развертывания "под ключ", казалось бы, обещанного документацией. С Node.js v0.6.x "платформа" была интегрирована в платформу, предоставляя один из основных строительных блоков, но мой "production.js" script все еще ~ 150 строк логики для обработки вещей например, создание каталога журналов, переработка мертвых работников и т.д. Для "серьезного" производственного обслуживания вам также необходимо быть готовым к подавлению входящих соединений и делать все, что делает Apache для PHP. Справедливости ради, Ruby on Rails имеет эту точную проблему. Он решается с помощью двух дополнительных механизмов: 1) Помещение Ruby on Rails/ Node.js за выделенный веб-сервер (написанный на C и проверенный на ад и обратно), например Nginx (или Apache/Lighttd). Вебсервер может эффективно обслуживать статический контент, вести журнал доступа, переписывать URL-адреса, завершать SSL, применять правила доступа и управлять несколькими под-службами. Для запросов, которые попадают в фактическую службу node, веб-сервер проксирует запрос. 2) Используя фреймворк, например Unicorn, который будет управлять рабочими процессами, периодически их перерабатывать и т.д. Я еще не нашел Node.js, который кажется полностью испеченным; он может существовать, но я еще не нашел его и все еще использую ~ 150 строк в ручном прокате "production.js".

Считывание фреймворков, таких как Express, похоже, что стандартная практика состоит в том, чтобы просто обслуживать все через один кусок всех сделок Node.js service... "app.use(express.static(__ dirname + '/public'))". Для служб с низкой нагрузкой и разработки это, вероятно, прекрасно. Но как только вы попытаетесь установить большую нагрузку на свой сервис и запустить его 24/7, вы быстро обнаружите мотивы, которые побуждают большие сайты иметь хорошо испеченный, закаленный C-код, например Nginx, выходящие на свой сайт и обрабатывающие все статические запросы контента (... до тех пор, пока вы не настроите CDN, например Amazon CloudFront)). Для немного юмористического и беззастенчиво негативного отношения к этому, см. этого парня.

Node.js также находит все больше и больше не связанных с обслуживанием целей. Даже если вы используете что-то еще для обслуживания веб-контента, вы можете использовать Node.js в качестве инструмента построения, используя npm модули для организации вашего кода Browserify, чтобы сшить его в один актив, и uglify-js, чтобы минимизировать его для развертывания. JavaScript для работы с Интернетом - идеальный соответствие импеданса, и часто это делает его самым легким путем атаки. Например, если вы хотите нащупать кучу JSON ответных нагрузок, вы должны использовать Underscore-CLI модуль, пояс службы структурированных данных.

Плюсы/минусы:

Pro: для парня-сервера писать JavaScript на бэкэнде было "лекарством шлюза" для изучения современных шаблонов пользовательского интерфейса. Я больше не боюсь писать код клиента.
Pro: имеет тенденцию поощрять правильную проверку ошибок (err возвращается практически всеми обратными вызовами, проталкивает программиста к его обработке, а также async.js и другие библиотеки обрабатывают "сбой, если какая-либо из этих подзадач не работает", парадигма намного лучше, чем типичный синхронный код)
Pro: некоторые интересные и обычно трудные задачи становятся тривиальными - например, получение статуса в задачах в полете, общение между работниками или совместное использование кеша.
Pro: огромное сообщество и множество отличных библиотек, основанных на надежном менеджере пакетов (npm).
Con: JavaScript не имеет стандартной библиотеки. Вы так привыкли импортировать функциональность, которая кажется странной, когда вы используете JSON.parse или какой-либо другой метод сборки, который не требует добавления модуля npm. Это означает, что существует пять версий всего. Даже модули, включенные в ядро Node.js, имеют еще пять вариантов, если вы недовольны реализацией по умолчанию. Это приводит к быстрой эволюции, но также и к некоторому путанице.

В сравнении с простой моделью с одним процессом за запрос (LAMP):

Pro: масштабируется до тысяч активных подключений. Очень быстро и очень эффективно. Для веб-флота это может означать сокращение в 10 раз в количестве ящиков, требуемых по сравнению с PHP или Ruby.
Pro: Написание параллельных шаблонов легко. Представьте, что вам нужно получить три (или N) капли из Memcached. Сделайте это в PHP... вы просто пишете код, который извлекает первый капля, затем второй, затем третий? Вау, это медленно. Там специальный PECL модуль, чтобы исправить эту конкретную проблему для Memcached, но что, если вы хотите получить некоторые данные Memcached параллельно с вашей базой данных запрос? В Node.js, поскольку парадигма асинхронна, наличие веб-запроса делает несколько параллельных операций очень естественным.
Con: Асинхронный код существенно сложнее, чем синхронный код, а предварительная кривая обучения может быть сложной для разработчиков без четкого понимания того, что на самом деле означает одновременное выполнение. Тем не менее, это намного менее сложно, чем писать любой многопоточный код с блокировкой.
Con: Если запрос с интенсивным вычислением выполняется, например, 100 мск, он остановит обработку других запросов, которые обрабатываются в том же процессе Node.js... AKA, совместная многозадачность. Это можно смягчить с помощью шаблона Web Workers (отключение подпроцесса для решения дорогостоящей задачи). В качестве альтернативы вы можете использовать большое количество рабочих Node.js и разрешать каждому обрабатывать один запрос одновременно (все еще достаточно эффективно, потому что нет процесса перекодирования).
Con: Запуск производственной системы намного сложнее, чем модель CGI, такая как Apache + PHP, Perl, Ruby и т.д. Необработанные исключения снимут весь процесс, требуя логики для перезапуска неработающих работников (см. cluster). Модули с базовым кодом с ошибкой могут привести к сбою процесса. Всякий раз, когда рабочий умирает, любые запросы, которые он обрабатывает, удаляются, поэтому один багги-API может легко ухудшить обслуживание других коучированных API.

В отличие от написания "реальной" службы в Java/С#/C (действительно?)

Pro: Выполнение асинхронности в Node.js проще, чем защита потоков в любом месте и, возможно, обеспечивает большую выгоду. Node.js - безусловно наименее болезненная асинхронная парадигма, с которой я когда-либо работал. С хорошими библиотеками это немного сложнее, чем писать синхронный код.
Pro: Нет многопоточных/блокирующих ошибок. Правда, вы вкладываете в начало более подробный код, который выражает правильный асинхронный рабочий процесс без каких-либо операций блокировки. И вам нужно написать несколько тестов и заставить работать (это язык сценариев, а имена переменных толстых пальцев - только во время единичного тестирования). НО, как только вы его заработаете, площадь поверхности heisenbugs - странные проблемы, которые проявляются только один раз в миллионе пробегов - эта поверхность площадь намного меньше. Написание налогов Node.js код сильно загружается на фазу кодирования. Затем вы, как правило, получаете стабильный код.
Pro: JavaScript гораздо более легкий для выражения функциональности. Трудно это доказать словами, но JSON, динамическая типизация, лямбда-нотация, прототипное наследование, легкие модули, что угодно... это просто имеет тенденцию брать меньше кода для выражения тех же идей.
Con: Возможно, вам действительно нравятся службы кодирования в Java?

Для другой перспективы JavaScript и Node.js, выберите От Java до Node.js, сообщение в блоге о разработчики демонстрируют впечатления и опыт обучения Java Node.js.

Модули Рассматривая node, имейте в виду, что ваш выбор библиотек JavaScript ОПРЕДЕЛЯЕТ ваш опыт. Большинство людей используют как минимум два помощника асинхронного шаблона (Step, Futures, Async) и сахарный модуль JavaScript (Underscore.js).

Помощник/JavaScript Sugar:

Underscore.js - используйте это. Просто сделай это. Это делает ваш код приятным и читаемым с такими вещами, как _.isString() и _.isArray(). Я не уверен, как вы могли бы написать безопасный код в противном случае. Кроме того, для расширенной командной строки-fu проверьте мою собственную Underscore-CLI.

Асинхронные шаблонные модули:

Step - очень элегантный способ выражения комбинаций последовательных и параллельных действий. Моя личная рекомендация. См. мой пост о том, как выглядит код этапа.
Futures - гораздо более гибкий (это действительно хорошо?) способ выразить порядок с помощью требований. Может выражать такие вещи, как "запускать a, b, c параллельно. Когда A и B заканчиваются, запустите AB. Когда закончите A и C, запустите AC". Такая гибкость требует большей осторожности, чтобы избежать ошибок в вашем рабочем процессе (например, никогда не вызывать обратный вызов или вызывать его несколько раз). См. сообщение Raynos об использовании фьючерсов (это сообщение, которое заставило меня "получить" фьючерсы).
Async - более традиционная библиотека с одним методом для каждого шаблона. Я начал с этого до моего религиозного преобразования на шаг и последующую реализацию того, что все шаблоны в Async могут быть выражены в Шаге с помощью одной более читаемой парадигмы.
TameJS - Написанный OKCupid, это прекомпилятор, который добавляет новый примитив языка "ожидание" для элегантного написания последовательных и параллельных рабочих процессов, Этот шаблон выглядит потрясающе, но он требует предварительной компиляции. Я все еще решаю эту проблему.
StreamlineJS - конкурент TameJS. Я склоняюсь к Тейму, но вы можете составить свой собственный разум.

Или прочитать все о асинхронных библиотеках, см. эту панель-интервью с авторами.

Веб-платформа:

Express Великая Ruby on Rails-esk для организации веб-сайтов. Он использует JADE в качестве механизма шаблонов XML/HTML, что делает построение HTML гораздо менее болезненным, почти элегантным даже.
jQuery Пока технически модуль node, jQuery быстро становится стандартом де-факто для клиентского интерфейса пользователя, jQuery предоставляет селекторам, подобным CSS, для "запроса" для наборов элементов DOM, которые затем можно использовать (установить обработчики, свойства, стили и т.д.). В том же ключе, Twitter Bootstrap CSS framework, Backbone. js для шаблон MVC и Browserify.js, чтобы сшить все ваши файлы JavaScript в один файл. Эти модули все становятся стандартами де-факто, поэтому вы должны хотя бы проверить их, если вы не слышали о них.

Тестирование:

JSHint- должен использовать; Сначала я не использовал это, что сейчас кажется непонятным. JSLint добавляет несколько основных проверок, которые вы получаете с помощью скомпилированного языка, такого как Java. Непредвиденная скобка, необъявленные переменные, типы многообразных форм и размеров. Вы также можете включить различные формы того, что я называю "анальным режимом", где вы проверяете стиль пробелов и многое другое, что хорошо, если ваша чашка чая - но реальная ценность исходит от получения мгновенной обратной связи о точном номере строки, где вы забыли закрытие ")"... без необходимости запускать свой код и ударить по линии нарушения. "JSHint" - это более настраиваемый вариант Дуглас Крокфорд JSLint.
Mocha конкурент к обетов, которые я предпочитаю. Оба фреймворка достаточно хорошо справляются с основами, но сложные шаблоны, как правило, легче выразить в Mocha.
Vows Обеты очень элегантны. И он распечатывает прекрасный отчет (--spec), показывающий вам, какие тестовые случаи прошли/не удалось. Проведите 30 минут обучения, и вы можете создавать базовые тесты для своих модулей с минимальными усилиями.
Zombie - Безгласное тестирование для HTML и JavaScript с помощью JSDom как виртуальный "браузер". Очень мощный материал. Объедините его с Replay, чтобы получить молниеносные детерминированные тесты кода в браузере.
Комментарий о том, как "думать о" тестировании:
- Тестирование не является необязательным. С динамическим языком, подобным JavaScript, очень мало статических проверок. Например, передача двух параметров в метод, который ожидает, что 4 не будет прерываться до тех пор, пока код не будет выполнен. Довольно низкий бар для создания ошибок в JavaScript. Основные тесты необходимы для создания разрыва проверки с использованием компилированных языков.
- Забудьте о проверке, просто запустите свой код. Для каждого метода мой первый пример проверки - "ничего не сломается", и тот случай, который срабатывает чаще всего. Доказав, что ваш код работает без бросания, улавливает 80% ошибок и сделает так много, чтобы повысить уверенность в вашем коде, что вы обнаружите, что возвращаетесь и добавляете ненужные случаи проверки, которые вы пропустили.
- Начните с малого и разрушите инерционный барьер. Мы все ленивы и нажимаем на время, и легко видеть тестирование как "лишнюю работу". Так что начните с малого. Напишите тестовый пример 0 - загрузите свой модуль и сообщите об успехе. Если вы заставляете себя делать так много, то инерционный барьер для тестирования нарушается. Это 30 минут, чтобы сделать это в первый раз, включая чтение документации. Теперь напишите тестовый пример 1 - вызовите один из ваших методов и проверьте "ничего не сломается", то есть вы не получите ошибку. Тестовый кейс 1 должен занимать менее одной минуты. По мере того, как инерция ушла, становится легче постепенно расширять зону покрытия.
- Теперь разработайте свои тесты с помощью своего кода. Не пугайтесь того, что "правильный" сквозной тест будет выглядеть с макетными серверами и все такое. Код начинается просто и развивается для обработки новых случаев; тесты тоже должны. Когда вы добавляете новые случаи и новую сложность в свой код, добавьте тестовые примеры для реализации нового кода. Когда вы найдете ошибки, добавьте проверки и/или новые случаи, чтобы покрыть ошибочный код. Когда вы отлаживаете и теряете уверенность в части кода, вернитесь назад и добавьте тесты, чтобы доказать, что он делает то, что вы считаете. Захватывайте строки примерных данных (из других сервисов, которые вы вызываете, сайты, которые вы царапаете, что угодно) и отправляете их на ваш синтаксический код. Несколько случаев здесь, улучшенная проверка там, и вы получите высоконадежный код.

Кроме того, ознакомьтесь с официальным списком рекомендованных модулей Node.js. Тем не менее, GitHub Node Модули Wiki много более полный и хороший ресурс.

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

Node.js СОБЫТИЕ и ASYNCHRONOUS/ НЕБЛОКИРОВАНИЕ, События, такие как входящее HTTP-соединение, закроют функцию JavaScript, которая выполняет немного работы и запускает другие асинхронные задачи, такие как подключение к базе данных или вытягивание содержимого с другого сервера. После того, как эти задачи были начаты, функция события заканчивается, и Node.js снова возвращается в режим сна. Как только происходит что-то еще, например, как установлено соединение с базой данных или внешний сервер, отвечающий содержимым, функции обратного вызова запускаются, и выполняется еще один код JavaScript, что может привести к еще более асинхронным задачам (например, к запросу базы данных). Таким образом, Node.js будет счастливо перемежать действия для нескольких параллельных рабочих процессов, выполняя любые действия, которые разблокируются в любой момент времени. Вот почему Node.js отлично справляется с тысячами одновременных подключений.

Почему бы просто не использовать один процесс/поток для каждого подключения, как и все остальные? В Node.js новое соединение - это очень небольшое распределение кучи. Спиннинг нового процесса занимает значительно больше памяти, мегабайт на некоторых платформах. Но реальная стоимость - это накладные расходы, связанные с переключением контекста. Когда у вас есть 10 ^ 6 потоков ядра, ядро должно выполнить много работы, выясняя, кто должен выполнить следующий. Куча работы занялась созданием планировщика O (1) для Linux, но в конце концов, это просто способ повысить эффективность одного процесса, управляемого событиями, чем 10 ^ 6 процессов, конкурирующих за процессорное время. Кроме того, в условиях перегрузки модель с несколькими процессами ведет себя очень плохо, голодающие критически важные службы администрирования и управления, особенно SSHD (что означает, что вы даже не можете войти в поле, чтобы понять, насколько это действительно на самом деле).

Node.js SINGLE THREADED и БЕСПЛАТНО. Node.js, так как очень продуманный выбор дизайна имеет только один поток для каждого процесса. Из-за этого принципиально невозможно, чтобы несколько потоков имели доступ к данным одновременно. Таким образом, никаких блокировок не требуется. Нити жесткие. На самом деле очень сложно. Если вы не верите в это, вы не сделали достаточно многопрограммного программирования. Правильное запирание затруднено и приводит к ошибкам, которые действительно трудно отследить. Устранение блокировок и многопоточность делает один из самых неприятных классов ошибок просто уйти. Это может быть самым большим преимуществом Node.

Но как я могу использовать 16-ядерный ящик?

Два способа:

Для больших тяжелых вычислительных задач, таких как кодирование изображений, Node.js может запускать дочерние процессы или отправлять сообщения дополнительным рабочим процессам. В этом дизайне у вас будет один поток, управляющий потоком событий, и N процессов, выполняющих тяжелые вычислительные задачи и пережевывающие другие 15 процессоров.
Для масштабирования пропускной способности в веб-сервисе вы должны запускать несколько серверов Node.js на одном поле, по одному на ядро, используя cluster (С Node.js v0.6.x официальный модуль "кластер", связанный здесь, заменяет версию learnboost, которая имеет другой API). Эти локальные серверы Node.js могут затем конкурировать в сокете, чтобы принимать новые соединения, балансируя нагрузку через них. Как только соединение принято, оно становится тесно связанным с одним из этих общих процессов. Теоретически это звучит плохо, но на практике это работает достаточно хорошо и позволяет избежать головной боли при написании кода, защищенного потоками. Кроме того, это означает, что Node.js получает отличную близость кэш-памяти процессора, более эффективно используя пропускную способность памяти.

Node.js позволяет вам делать действительно мощные вещи, не разбивая пота. Предположим, у вас есть программа Node.js, которая выполняет множество задач, слушает TCP порт для команд, кодирует некоторые изображения, что угодно. С пятью строками кода вы можете добавить в портал управления веб-интерфейсом HTTP, который показывает текущий статус активных задач. Это ЛЕГКО:

var http = require('http');
http.createServer(function (req, res) {
    res.writeHead(200, {'Content-Type': 'text/plain'});
    res.end(myJavascriptObject.getSomeStatusInfo());
}).listen(1337, "127.0.0.1");

Теперь вы можете нажать URL-адрес и проверить состояние выполняемого процесса. Добавьте несколько кнопок, и у вас есть "портал управления". Если у вас запущен Perl/Python/Ruby script, просто "бросать в портал управления" не совсем просто.

Но не JavaScript медленный/плохой/злой/порожденный дьяволом?JavaScript имеет некоторые странные странности, но с "хорошими деталями" там очень мощный язык, и в любом случае JavaScript - это язык на клиенте (браузере). JavaScript здесь, чтобы остаться; другие языки нацелены на него как на ИЛ, а талант мирового класса конкурирует за создание самых современных движков JavaScript. Из-за роли JavaScript в браузере огромное количество инженерных усилий бросается на быстрое ускорение JavaScript. V8 - это самый последний и самый большой механизм javascript, по крайней мере, в этом месяце. Он сбрасывает другие языки сценариев как по эффективности, так и по стабильности (глядя на вас, Ruby). И это только улучшится с огромными командами, работающими над проблемой в Microsoft, Google и Mozilla, конкурируя за создание лучшего движка JavaScript (он больше не является "интерпретатором" JavaScript, поскольку все современные двигатели делают тонны JIT компиляция под капотом с интерпретацией только в качестве резервной копии для кода исполнения). Да, мы все желаем, чтобы мы могли исправить несколько лишних вариантов языка JavaScript, но это действительно не так уж плохо. И язык настолько прочен, что вы действительно не кодируете JavaScript, вы кодируете Step или jQuery - больше, чем любой другой язык, в JavaScript, библиотеки определяют опыт. Чтобы создавать веб-приложения, вы в значительной степени должны знать JavaScript в любом случае, поэтому кодирование с ним на сервере имеет своего рода симулятор набора навыков. Это заставило меня не страшно писать код клиента.

Кроме того, если вы ДЕЙСТВИТЕЛЬНО ненавидите JavaScript, вы можете использовать синтаксический сахар, например CoffeeScript. Или что-нибудь еще, что создает код JavaScript, например Google Toolkit (GWT).

Говоря о JavaScript, что такое "закрытие"?. Довольно причудливый способ сказать, что вы сохраняете лексически ограниченные переменные в цепочках вызовов.;) Например:

var myData = "foo";
database.connect( 'user:pass', function myCallback( result ) {
    database.query("SELECT * from Foo where id = " + myData);
} );
// Note that doSomethingElse() executes _BEFORE_ "database.query" which is inside a callback
doSomethingElse();

Посмотрите, как вы можете просто использовать "myData", не делая ничего неудобного, как сложение его в объект? И в отличие от Java, переменная "myData" не обязательно должна быть доступна только для чтения. Эта мощная функция языка делает асинхронное программирование гораздо менее подробным и менее болезненным.

Написание асинхронного кода всегда будет сложнее, чем писать простой однопоточный script, но с Node.js, это не намного сложнее, и вы получаете много преимуществ в дополнение к эффективности и масштабируемость до тысяч одновременных подключений...

Ответы

Ответ 1

Ответ 2

Плюсы/минусы:

В сравнении с простой моделью с одним процессом за запрос (LAMP):

В отличие от написания "реальной" службы в Java/С#/C (действительно?)

Ответ 3

Ответ 4

Ответ 5

Ответ 6

Ответ 7

Ответ 8

Ответ 9

Ответ 10