Если в первый момент идея не кажется абсурдной, она безнадёжна.
— Альберт Эйнштейн

Мы собрали для вас самые популярные темы из обсуждений Node.js на Хабре, и попросили рассказать о них признанных экспертов: некоммерческого Node-хакера Матиаса Мэдсена и автора множества книг и курсов по Node, Азата Мардана.

Вот точный список тем:

1. Потоки в Node.js и способы распараллеливания вычислений;
2. Асинхронность в Node.js;
3. Отладка и логирование в Node.js;
4. Проблемы мониторинга производительности на продакшене;

5. Инструменты для мониторинга нод.

   Азат Мардан (Azat Mardan) — Tech Fellow, менеджер в компании Capital One, и эксперт по JavaScript/Node.js с несколькими онлайн-курсами на Udemy и в Node University, а также автор 14 книг по той же тематике, включая «React Quickly» (Manning, 2017), «Full Stack JavaScript» (Apress, 2015), «Practical Node.js» (Apress, 2014) и «Pro Express.js» (Apress, 2014).

В свое свободное время Азат пишет о технологиях на Webapplog.com, выступает на конференциях и вносит свой вклад в open-source. Прежде чем стать экспертом в Node.js, Азат закончил магистратуру в области информационных систем, и поработал в федеральных государственных учреждениях США, небольших стартапах, и в крупных корпорациях с различными технологиями, такими как Java, SQL, PHP, Ruby и т. д.

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

Матиас Буус Мэдсен (Mathias Buus Madsen) — является некоммерческим хакером Node.js, базирующимся в Копенгагене, Дания. Он работает полный рабочий день с открытым исходным кодом и в проекте Dat (http://dat-data.com), создавая открытые инструменты, позволяющие ученым совместно использовать наборы данных. В настоящее время он поддерживает более 400 модулей на npm, что уже само по себе впечатляет.

Напоминаем, что встретиться с ними вживую можно на конференции HolyJS 2017 Moscow.

Появление на сцене серверного JavaScript надолго разделило программистское сообщество на тех, кто его принял, и всех остальных… Нам с вами не привыкать к холиварам, особенно, когда речь заходит о чем-то очевидном, вроде мысли, что сайты отлично пишутся на PHP (хм..., или на Perl? или на Python?.. впрочем, неважно, пост-то о Node.js), нам куда интереснее будет обсудить, не на чем писать, а как из этого, единственно верного хорошо подходящего языка/стека получить достойные результаты. Тем более что Node развивается, комьюнити ширится, версии появляются, серверный движок только совершенствуется, и приход светлого завтра (на фоне серого вчера) — как минимум не за горами!  Посмотрим, что скажут эксперты…

Азат

(я отвечаю на вопросы по состоянию дел на конец 2017 года, что означает Node 8, npm 5, и так далее; сегодня кое-что изменилось по сравнению с ранними днями Node, а что-то осталось более-менее тем же).

1. Потоки в Node.js и способы распараллеливания вычислений

Как многие знают, Node однопоточна; в этом и сильная, и слабая стороны Node. Сильная, потому что так проще реализовать асинхронный неблокирующий код, который позволит вашим системам выполнять больше операций ввода-вывода, что обычно означает обработку большего трафика. Слабая из-за того, что вы можете написать код, который будет блокироваться. Вам поможет инициирование нескольких потоков. В ядре языка существует модуль cluster, но большинство разработчиков Node используют pm2. Он поддерживает разработку (pm2-dev) и контейнеры (pm2-docker). Чтобы начать работу с pm2, просто установите его с помощью npm и запустите в фоновом режиме:

npm i -g pm2
pm2 start server.js -i 0

Если pm2 не подходит по все ваши требования, и вам все равно нужно работать на более низком уровне, вы можете использовать cluster. В новых версиях Node (текущая версия 8) у него есть балансировка нагрузки, как в pm2. В результате, несколько ваших процессов смогут слушать на одном и том же порту, и смогут взаимодействовать друг с другом и с основным процессом. Вам следует использовать fork() с cluster. Вот хороший пример:

const cluster = require('cluster')
const numCPUs = require('os').cpus().length
if (cluster.isMaster) {
  for (var i = 0; i < numCPUs; i++) {
    cluster.fork()
  }
} else if (cluster.isWorker) {
  // your server code
})

Наконец, есть два метода для ручного создания процессов в дополнение к fork(): spawn() и exec(). Первый — для длительных процессов, потоковой передачи и большого объема данных, в то время как второй подходит для небольшого вывода данных.

2. Асинхронное программирование в Node.js

Да, в Node есть async/await функции. Мне все еще нравятся колбеки, но асинхронные функции прекрасны. Их легко понять даже новичкам. Код async функции короче, чем код promise. Взгляните на этот тест Mocha с двумя вложенными async вызовами к БД. Он короткий и симпатичный:

describe('#find()', () => {
    it('responds with matching records', async () => {
        const users = await db.users.find({
            type: 'User'
        })
        expect(users).to.have.length(3)
        for (let user of users) {
            const comments = await db.comments.find({
                user: user.id
            })
            expect(comments).to.be.ok
        }
    })
})

Кстати, вы можете использовать и синтаксис function() {}, не только синтаксис со стрелками:

const async function() {
    const {response: res} = await axios. get('https://webapplog.com/api/cupcakes')
}

Еще один бонус async функций заключается в том, что они совместимы с promise-ами. Да, все верно. Вы можете использовать их вместе, например, создавать async функцию, затем использовать then, или использовать библиотеку на основе promise (например, axios из моего примера), или функцию, созданную util.promisify() (новый метод Node 8!) как async функцию.

3. Отладка в Node.js

Отладчик в Node значительно улучшился в сравнении с тем, что было раньше. Я помню времена, когда я работал в Storify (компании — одном из самых первых пользователей Node), я просто размещал console.log по всему коду. Сегодня вы можете отлаживать в VS Code. Это потрясающий редактор. Я использую его каждый день.

Далее, существует Node Inspector, который, по сути, Chrome DevTools для программ на Node.js. В Node v8 появился Google Chrome V8 Inspector, интегрированный в Node, и все, что вам нужно сделать для начала работы с GUI-дебагером, это просто написать:

node --inspect index.js

затем открыть§chrome://inspect/#devices в браузере Chrome. В версии 7, нужно скопировать URL и открыть его в браузере Chrome. URL будет содержать в начале строку chrome-devtools://. Просто помните, что ваш скрипт на Node должен работать достаточно долго, чтобы отладчик из DevTools успел подключиться к программе, или вам придется расставлять брекпоиты в отладчике или в коде.

Node построен на Chrome V8 и использует Chrome DevTools для отладки, не просто потому, что там есть приятный GUI, но и чтобы обеспечить надежную работу функций и в будущем.

4. Проблемы производительности Node.js

Большинство проблем с производством Node связаны либо с утечками памяти, либо с сетью, либо с проблемами ввода-вывода. Стресс-тестирование поможет вам понять, как ваше приложение и система работают в условиях реальной нагрузки. Хороший инструмент — artillery. Некоторые проблемы с утечкой памяти могут быть устранены или смягчены путем незначительного изменения кода и использования свежей версии Node, которая идет с новым компилятором JIT JavaScript под названием Turbofan. Прочитайте этот отличный пост GET READY: НОВЫЙ V8 ПРИХОДИТ, ПРОИЗВОДИТЕЛЬНОСТЬ NODE.JS МЕНЯЕТСЯ по поводу оптимизации, а также техник, и кода, которые стоило бы либо избегать, либо взять на вооружение.

5. Хорошие инструменты для мониторинга Node.js

Для начала, убедитесь, что код Node готов к работе. В 2018 году это будет означать использование контейнеров, облаков и методов автоматизации. Возможно, вы захотите посмотреть мой курс Node in Production для получения более подробной информации.

Node должен масштабироваться как по вертикали (см. пункт 1), так и по горизонтали. Это, конечно же, затрудняет мониторинг и сбор логов. Вам необходимо будет собирать метрики и журналы.

Создайте сами простой дашбоард, и вы увидите статистику и метрики, которые формируют отдельные серверы и процессы Node… или используйте опен-сорсный дашбоард, скажем, Hygieia, созданный в Capital One (на случай: я работаю в Capital One).

Хорошими инструментами для работы с логами будут winston и bunyan. Вы можете отправлять журналы в любое место, скажем, в сторонний SaaS, например Loggly, Splunk или Papertail (мы использовали его в Storify). Если вы хотите держать все данные у себя, то разверните Elastic Search с Kibana, и отправьте свои журналы туда. Именно это, мы сделали в DocuSign, когда мы не смогли использовать сторонний сервис по соображениям безопасности и конфиденциальности. Мы разработали собственное решение на базе Winston, Elastic и Kibana.

Еще несколько инструментов и услуг, которые стоит учитывать (не все бесплатны), особенно для мониторинга в продакшене: это N|Solid, NewRelic и AWS CloudWatch.

Завершение

Node растет сумасшедшими темпами. Даже без новых версий это уже потрясающая технология. Она быстрая, надежная, и, самое главное, приносит разработчикам радость беззаботного кодирование. При перемещении в стек Node я видел много счастливых разработчиков Java и C#.

Матиас

Делаем несколько дел параллельно

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

Она может позволить себе быть однопотоковой, поскольку все операции ввода/вывода выполняются асинхронно, и, следовательно, не блокируют выполнение программы. Более того, хотя JavaScript в Node имеет один поток исполнения для программы, сам он использует для себя еще несколько потоков, чтобы справляться с помочь с фоновыми I/O задачами и другими служебными задачами.

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

Существует несколько способов достичь этого. Один из таких подходов (который я часто использую) – написать нативный модуль (как правило, все мои процессорно-интенсивные операции все равно требуют использования какого-либо нативного модуля) и использовать действительно симпатичный worker api. При помощи этого API ваша (в прошлом — синхронная) операция сможет использовать колбек, либо вернуть promise, а ваша задача, созданная с использованием C++ и Worker API, будет работать в другом системном потоке исполнения.

Другим подходом будет разбиение программы на небольшие части и одновременный их запуск как множества процессов. По сути, это означает переделку вашей программы в небольшую распределенную систему. Таким способом вы сможете использовать много ядер процессора совершенно нативным образом.

В любом случае, когда вы начинаете реализовывать параллельность исполнения кода Node программы, вы получаете куда более асинхронный код. Управление асинхронным кодом в Node — одна из тех вещей, которые кажутся очень трудными поначалу, но становятся куда более простыми в понимании, по мере роста опыта. В текущей версии Node вы можете использовать возможности вроде async/await, чтобы ваш асинхронный код выглядел синхронным, если вы также используете promise. Одна сложность, вытекающая из этого — поскольку вы вынуждены использовать синтаксис try-catch, вам придется разбираться в т.ч. и с более серьезными багами, поскольку try-catch в JavaScript так же перехватывает ситуации, которые в других языках привели бы к ошибками компиляции (например, опечатки в коде и пр.). Другими словами, поиск багов станет более сложным, т. к. вы в коде обработки ошибок получите сообщения и о синтаксических ошибках, и о ошибках при выполнении программы.

В результате, лично я чаще всего использую колбеки для асинхронного программирования, вкупе с пачкой вспомогательных библиотек, таких, как модуль after-all, и пр.

Отладка и мониторинг

Одна из нравящихся мне черт Node — количество прекрасных средств, которые помогают вам отлаживать и мониторить поведение приложения (да я и сам написал их немало). Когда мы работаем с Node, мы работаем с кодом на JavaScript, который будет выполняться на V8. В свою очередь, V8 имеем богатые функционалом API, позволяющие выжать из него прекрасную производительность. Это позволяет вам отследить действительную причину проблем (то самое «бутылочное горлышко») в вашем приложении без каких-либо лишних угадываний.
Я особенно люблю модуль 0x (https://github.com/davidmarkclements/0x), написанный Девидом Марком Клемнентом и его друзьями. Этот модуль легко превращает бенчмарк в настоящий flamegraph. Просто запускаем ваш бенчмарк с 0x вместо node (плюс создаем flamegraph, и затем открываем его в браузере):

0x -o my-benchmark.js

Этот график четко расскажет, какая JavaScript функция использует при выполнении программы большее время процессора. Такой подход дает наглядное представление, на что обратить при оптимизации наибольшее внимание.

Другой модуль из тех, что я часто использую для ops-задач, мой собственный модуль под названием respawn. Он просто помогает вам запустить процесс, а затем перезапустит его, если процесс по-crash-ится.

К respawn есть симпатичная cli-обертка под названием lil-pids. lil-pids не имеет интерфейса, и требует один лишь файл с названием ./services: вы просто указываете в нем все команды, которые бы хотели видеть запущенными в вашей системе, lil-pids приглядывает за ними, и старается при помощи модуля respawn добиться, чтобы все они были запущены.

Наконец, еще проблема, которую мне чаще всего приходится решать в Node при эксплуатации кода в продакшене — это случайные утечки памяти. Даже несмотря на то, что JavaScript имеет свой сборщик мусора, мы часто допускаем утечки памяти, скажем, добавляя элементы в список, и забывая удалить их оттуда, и т.п. Иногда мы не допускаем утечку памяти, но реализуем алгоритмы, потребляющие столь много памяти, что в какой-то момент система вынуждена остановить программу программу. Для определения ситуации, когда имеет место утечка памяти, я довольно часто применяю модуль Томаса Вотсона под названием memory-usage. Единственная вещь, которую он делает — отдает вам бесконечный поток данных о том, как много памяти использует ваша программа во времени. Если нарисовать график этой величины, вы увидите, когда начинается утечка памяти.

Что бы ни говорила известная пословица, есть вариант лучший, чем «один раз увидеть» — это, в нашем случае, «увидеть и услышать доклады, а потом задать вопросы и пообщаться в кулуарах». Приглашаем на конференцию HolyJS 2017 Moscow!

Автор: Олег Чирухин

Источник