Хабрахабр

[Из песочницы] Всё что вам нужно знать о Node.js

Представляю вашему вниманию перевод статьи "Everything you need to know about Node.js" автора Jorge Ramón. Привет, Хабр!

Она так же подходит для построения гибридных мобильных приложений, десктопных программ и даже для IoT. В наши дни платформа Node.js является одной из самых популярных платформ для построения эффективных и масштабируемых REST API's.

Этот пост главным образом пытается быть путеводителем по тому, как Node.js работает на самом деле. Я работаю с платформой Node.js более 6 лет и я на самом деле люблю её.

Давайте же начнём!!

О чем пойдёт речь:

Мир до Node.js

Многопоточный сервер

В этой схеме сервер, ответив на запрос, прерывает соединение. Веб-приложения, написанные следуя клиент/серверной архитектуре, работают по следующей схеме — клиент запрашивает нужный ресурс у сервера и сервер отправляет ресурс в ответ.

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

Не совсем! Значит ли это, что сервер может обрабатывать только один запрос за раз? Когда сервер получает новый запрос он создаёт отдельный поток для его обработки.

С учётом сказанного, сервер может обрабатывать несколько запросов одновременно, но только по одному на поток. Поток, если простыми словами, это время и ресурсы, что CPU выделаят на выполнение небольшого блока инструкций. Такая модель так же называться thread-per-request model.

Если сервер получает N+1 запросов, тогда он должен ждать пока один из потоков не станет доступным. Для обработки N запросов серверу нужно N потоков.

На рисунке выше, сервер может обрабатывать до 4 запросов (потоков) единовременно и когда он получает следующие 3 запроса, эти запросы должны ждать пока любой из этих 4 потоков не станет доступным.

д.) на сервер, но это не самое лучшее решение…. Один из способов избавиться от ограничений — добавить больше ресурсов (памяти, ядер процессора и т.

И, конечно, не забываем о технологических ограничениях.

Блокирующий ввод/вывод

Возможно, Вам стало интересно почему один поток не может обрабатывать несколько запросов одновременно? Ограниченное число потоков на сервере не единственная проблема. всё из-за блокирующих операций ввода/вывода.

Допустим, Вы разрабатываете онлайн магазин и Вам нужна страница где пользователь может просматривать список всех товаров.

Совсем не сложно, да? Пользователь стучится на http://yourstore.com/products и сервер рендерит HTML файл со всеми продуктами с базы данных в ответ.

Но, что же происходит за кулисами?

  • Когда пользователь стучится на /products особый метод или функция должна выполниться, что бы обработать запрос. Маленький кусочек кода (Ваш или фреймворка) анализирует URL-адрес запроса и ищет подходящий метод или функцию. Поток работает.
  • Теперь нужный метод или функция выполняться, так как и в первом пункте — поток работает.
  • Так как Вы хороший разработчик, Вы сохраняете все системные логи в файл, ну и конечно же, что бы быть уверенными, что роутер выполняет нужный метод/функцию — Вы так же логируете строку "Method X executing!!». Но всё это блокирующие операции ввода/вывода. Поток ждёт.
  • Все логи сохранены и следующие строки функции выполняются. Поток работает снова.
  • Время обращаться к базе данных и получать все продукты – простой запрос, вроде SELECT * FROM products, выполняет свою работу, но угадайте что? Да-да, это блокирующая операция ввода/вывода. Поток ждёт.
  • Вы получили массив или список всех продуктов, но убедитесь, что Вы всё это залогировали. Поток ждёт.
  • Теперь у Вас есть все продукты и пришло время рендерить шаблон для будущей страницы, но перед этим Вам нужно их прочитать. Поток ждёт.
  • Движок рендеринга делает свою работу и шлёт ответ клиенту. Поток работает снова.
  • Поток свободен, словно птица в небесах.

Ну это зависит от конкретной. На сколько медленны операции ввода/вывода? Давайте обратимся к таблице:

Представьте сколько запросов или обращений к внешним API ваша система могла бы обработать за это время. Операции сети и чтения с диска слишком медленные.

Подбивая итоги: операции ввода/вывода заставляют поток ждать и тратить ресурсы впустую.

Проблема C10K

Проблема

C10k; 10k connections — проблема 10 тысяч соединений) C10k (англ.

Проблема возникала при параллельной обработке 10 000 клиентских соединений к одной машине. В ранние 2000-е, серверные и клиентские машины были медленными.

Что ж, давайте используем немного математики. Но почему традиционная модель thread-per-request (поток на запрос) не могла решить эту проблему?

Да, и не забывайте, мы в начале 2000-х!! Нативная реализация потоков выделаят больше 1 Мб памяти на поток, выходя из этого – для 10 тысяч потоков требуется 10 Гб оперативной памяти и это только для стека потоков.

Но фактически проблема не исчерпана. В наши дни серверные и клиентские компьютеры работают быстрее и эффективней и почти любой язык программирования или фреймворк справляются с этой проблемой. Для 10 миллионов клиентских соединений к одной машине проблема возвращается вновь (но теперь она C10M Problem).

JavaScript спасение?

Осторожно, спойлеры!!!
Node.js на самом деле решает проблему C10K… но как?!

Серверный JavaScript не был чем-то новым и необычным в начале 2000-х, на тот момент уже существовали реализации поверх JVM (java virtual machine) – RingoJS и AppEngineJS, что работали на модели thread-per-request.

Всё из-за того, что JavaScript однопоточный. Но если они не смогли решить проблему, тогда как Node.js смог?!

Node.js и цикл событий

Node.js

Node.js это серверная платформа, что работает на движке Google Chrome – V8, который умеет компилировать JavaScript код в машинный код.

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

Давайте напишем маленький пример:

// Importing native http module
const http = require('http'); // Creating a server instance where every call
// the message 'Hello World' is responded to the client
const server = http.createServer(function(request, response) { response.write('Hello World'); response.end();
}); // Listening port 8080
server.listen(8080);

Non-blocking I/O

Node.js использует неблокирующие ввод/вывод операции, что же это значит:

  • Главный поток не будет блокироваться операциями ввода/вывода.
  • Сервер будет продолжать обслуживать запросы.
  • Нам придётся работать с асинхронным кодом.

Что бы отослать HTML страницу сначала ее нужно прочитать из файла. Давайте напишем пример, в котором на запрос к /home сервер в ответ шлёт HTML страницу, а для всех других запросов — 'Hello World'.

home.html

<html> <body> <h1>This is home page</h1> </body>
</html>

index.js

const http = require('http');
const fs = require('fs'); const server = http.createServer(function(request, response) /home.html`, function (err, content) { if (!err) { response.setHeader('Content-Type', 'text/html'); response.write(content); } else { response.statusCode = 500; response.write('An error has ocurred'); } response.end(); }); } else { response.write('Hello World'); response.end(); }
}); server.listen(8080);

Если запрашиваемый url-адрес /home, тогда используется нативный модуль fs для чтения файла home.html.

Эти функции будут выполнены в какой-то из моментов в будущем (Первая, как только сервер получит запрос, а вторая — когда файл будет прочитан с диска и помещён в буфер). Функции что попадают в http.createServer и fs.readFile как аргументы — колбэки.

Пока файл считывается с диска, Node.js может обрабатывать другие запросы и даже считывать файл снова и всё это в одном потоке… но как?!

Цикл событий

Это буквально бесконечный цикл и на самом деле один поток. Цикл событий — это магия, которая происходит внутри Node.js.

Вы можете узнать больше о libuv здесь. Libuv — C библиотека которая реализует этот паттерн и является частью ядра Node.js.

Цикл событий имеет 6 фаз, каждое исполнение всех 6 фаз называют tick-ом.

  • timers: в этой фазе выполняются коллбэки, запланированные методами setTimeout() и setInterval();
  • pending callbacks: выполняются почти все коллбэки, за исключением событий close, таймеров и setImmediate();
  • idle, prepare: используется только для внутренних целей;
  • poll: ответственен за получение новых событий ввода/вывода. Node.js может блокироваться на этом этапе;
  • check: коллбэки, вызванные методом setImmediate(), выполняються на этом этапе;
  • close callbacks: например, socket.on('close', ...);

Хорошо, есть только один поток, и этот поток и есть цикл событий, но тогда кто выполняет все операции ввода/вывода?

Обратите внимание!!!
Когда циклу событий нужно выполнить операцию ввода/вывода он использует поток ОС с тредпула (thread pool), а когда задача выполнена, коллбэк ставится в очередь во время фазы pending callbacks.

Разве это не круто?

Проблема CPU-ёмких задач

Вы можете создавать всё, что захотите. Node.js кажется идеальным!

Давайте напишем API для вычислений простых чисел.

Простое число – это целое (натуральное) число больше единицы и делимое только на 1 и на само себя.

Дано число N, API должен вычислять и возвращать первые N простых чисел в список (или массив).

primes.js

function isPrime(n) { for(let i = 2, s = Math.sqrt(n); i <= s; i++) { if(n % i === 0) return false; return n > 1; }
} function nthPrime(n) { let counter = n; let iterator = 2; let result = []; while(counter > 0) { isPrime(iterator) && result.push(iterator) && counter--; iterator++; } return result;
} module.exports = { isPrime, nthPrime };

index.js

const http = require('http');
const url = require('url');
const primes = require('./primes'); const server = http.createServer(function (request, response) { const { pathname, query } = url.parse(request.url, true); if (pathname === '/primes') { const result = primes.nthPrime(query.n || 0); response.setHeader('Content-Type', 'application/json'); response.write(JSON.stringify(result)); response.end(); } else { response.statusCode = 404; response.write('Not Found'); response.end(); }
}); server.listen(8080);

prime.js это реализация нужных вычислений: функция isPrime проверяет является ли число простым, а nthPrime возвращает N таких чисел.

Число N прокидывается через строку запроса в URL-адресе. Файл же index.js отвечает за создание сервера и использует модуль prime.js для обработки каждого запроса на /primes.

Что бы получить первых 20 простых чисел нам нужно сделать запрос на http://localhost:8080/primes?n=20.

Предположим, к нам стучатся 3 клиента и пытаются получить доступ к нашему не блокирующемуся вводом/выводом API:

  • Первый запрашивает 5 простых чисел каждую секунду.
  • Второй запрашивает 1000 простых чисел каждую секунду
  • Третий запрашивает 10 000 000 000 простых чисел, но...

Когда главный поток занят исполнением «тяжёлой» задачи он становится недоступен для других задач. Когда третий клиент шлёт запрос – главный поток блокируется и это главный признак проблемы CPU-ёмких задач.

Если Вы помните, эта библиотека помогает Node.js исполнять операции ввода/вывода с помощью потоков ОС избегая блокировки главного потока и Вы абсолютно правы, это решение нашей проблемы, но для того, что бы это стало возможным, наш модуль должен быть написан на языке C++, что бы libuv могла с ним работать. Но как насчёт libuv?

5 в Node.js добавлен нативный модуль Worker Threads. К счастью, начиная с v10.

Воркеры и их потоки

Как говорит нам документация:

Воркеры полезны для выполнения CPU-ёмких JavaScript операций; не используйте их для операций ввода/вывода, уже встроенные в Node.js механизмы более эффективно справляться с такими задачи, чем Worker thread.

Исправление кода

Пришло время переписать наш код:

primes-workerthreads.js

const { workerData, parentPort } = require('worker_threads'); function isPrime(n) { for(let i = 2, s = Math.sqrt(n); i <= s; i++) if(n % i === 0) return false; return n > 1;
} function nthPrime(n) { let counter = n; let iterator = 2; let result = []; while(counter > 0) { isPrime(iterator) && result.push(iterator) && counter--; iterator++; } return result;
} parentPort.postMessage(nthPrime(workerData.n));

index-workerthreads.js

const http = require('http');
const url = require('url');
const { Worker } = require('worker_threads'); const server = http.createServer(function (request, response) { const { pathname, query } = url.parse(request.url, true); if (pathname === '/primes') { const worker = new Worker('./primes-workerthreads.js', { workerData: { n: query.n || 0 } }); worker.on('error', function () { response.statusCode = 500; response.write('Oops there was an error...'); response.end(); }); let result; worker.on('message', function (message) { result = message; }); worker.on('exit', function () { response.setHeader('Content-Type', 'application/json'); response.write(JSON.stringify(result)); response.end(); }); } else { response.statusCode = 404; response.write('Not Found'); response.end(); }
}); server.listen(8080);

Когда список простых чисел просчитан и готов, инициируется событие message – результат попадает в главный поток из-за того, что у воркера не осталось работы он также инициирует событие exit, позволяя основному потоку отправлять данные клиенту. В файле index-workerthreads.js при каждом запросе на /primes создаётся экземпляр класса Worker (с нативного модуля worker_threads) для выгрузки и исполнения файла primes-workerthreads.js в поток воркера.

Он импортирует workerData (это копия параметров, переданных с основного потока) и parentPort через который результат роботы воркера передаётся назад в главный поток. primes-workerthreads.js изменён немного.

Теперь давайте испробуем наш пример снова и посмотрим, что случиться:

Основной поток больше не блокируется !!!!!

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

Заключение

Если Вы знаете, как что-то работает изнутри, Вы сможете работать с этим более эффективно. Node.js мощная технология, которую стоит изучить при возможности.
Моя личная рекомендация – всегда будьте любопытными!

Я надеюсь этот пост был полезен для Вас и вы узнали что-то новое о Node.js. Это всё на сегодня, ребята.

Спасибо за прочтение и до встречи в следующих постах.

Теги
Показать больше

Похожие статьи

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *

Кнопка «Наверх»
Закрыть