Як "сервер" Node.js порівнюється із серверами Nginx або Apache?

Question 1

Нещодавно я вивчав Node.js і натрапив на деякі матеріали про написання простих серверів на основі Node.js. Наприклад, наступне.

var express = require("express"),
http = require("http"), app;

// Create our Express-powered HTTP server
// and have it listen on port 3000
app = express();
http.createServer(app).listen(3000);

// set up our routes
app.get("/hello", function (req, res) {
    res.send("Hello World!");
});

app.get("/goodbye", function (req, res) {
    res.send("Goodbye World!");
});

Зараз, хоча, здається, я розумію, що відбувається в коді, мене трохи бентежить термінологія. Коли я чую термін сервер, я думаю про такі речі, як Apache чи Nginx. Я звик думати про них як про контейнер, який вміщує мої веб-програми. Чим сервер Node.js відрізняється від сервера Nginx / Apache? Чи не правда, що сервер на основі Node.js (тобто код) все ще може бути розміщений у щось на зразок Nginx для запуску? То чому обох називають «серверами»?

Question 2

Це сервер, так.

Веб-програма node.js - це повноцінний веб-сервер, подібно до Nginx або Apache.

Ви дійсно можете обслуговувати свою програму node.js, не використовуючи будь-який інший веб-сервер. Просто змініть свій код на:

app = express();
http.createServer(app).listen(80); // serve HTTP directly

Дійсно, деякі проекти використовують node.js як інтерфейсний балансир навантаження для інших серверів (включаючи Apache).

Зверніть увагу, що node.js - це не єдиний стек розробки, який робить це. Структури веб-розробки в Go, Java та Swift також роблять це.

Чому?

На початку була CGI. CGI чудово працював і працював нормально. Apache отримає запит, виявить, що URL-адреса повинна виконати програму CGI, виконати цю програму CGI і передати дані як змінні середовища, прочитати stdout і подати дані назад у браузер.

Проблема в тому, що це повільно. Це нормально, коли додаток CGI являв собою невелику статично скомпільовану програму С, але групу невеликих статично скомпільованих програм С було важко підтримувати. Тож люди почали писати мовами сценаріїв. Потім це стало важко підтримувати, і люди почали розробляти об'єктно-орієнтовані фреймворки MVC. Тепер у нас виникли проблеми - КОЖНИЙ ЗАПИТ повинен компілювати всі ці класи і створювати всі ці об’єкти лише для того, щоб обслуговувати якийсь HTML, навіть якщо немає нічого динамічного для обслуговування (оскільки фреймворк повинен з’ясувати, що немає нічого динамічного для обслуговування).

Що робити, якщо нам не потрібно створювати всі ці об’єкти під кожен запит?

Так думали люди. І від спроби вирішити цю проблему виникла кілька стратегій. Одним із перших було вбудовування перекладачів безпосередньо у веб-сервери, як mod_phpв Apache. Складені класи та об'єкти можуть зберігатися в глобальних змінних і, отже, кешуватися. Іншою стратегією було зробити попередню компіляцію. І ще однією стратегією було запуск програми як звичайного серверного процесу та спілкування з веб-сервером за допомогою спеціального протоколу, такого як FastCGI.

Потім деякі розробники почали просто використовувати HTTP як протокол свого додатка-> сервера. По суті, програма також є сервером HTTP. Перевага цього полягає в тому, що вам не потрібно впроваджувати будь-який новий, можливо, помилковий, можливо не перевірений протокол, і ви можете налагоджувати свою програму безпосередньо за допомогою веб-браузера (або також часто, curl). Вам не потрібен модифікований веб-сервер для підтримки вашого додатка, будь-який веб-сервер, який може робити зворотне проксі-сервер або переспрямування.

Навіщо використовувати Apache / Nginx?

Коли ви обслуговуєте програму node.js, зверніть увагу, що ви є автором власного веб-сервера. Будь-яка потенційна помилка у вашому додатку є безпосередньо придатною для використання в Інтернеті. Деяким людям (виправдано) це неприємно.

Додавання шару Apache або Nginx перед вашим додатком node.js означає, що ви маєте перевірену в боях частину програмного забезпечення в реальному Інтернеті як інтерфейс для вашого додатка. Це додає крихітну затримку (зворотне проксі-сервер), але більшість вважають, що це того варте.

Це було стандартною порадою в перші дні node.js. Але в наші дні існують також веб-сайти та веб-сервіси, які виставляють node.js безпосередньо до Інтернету. http.ServerМодуль тепер досить добре бойові випробування в Інтернеті можна довіряти.

Question 3

NodeJs створює власний сервер. Як бачите, термінологія цілком зрозуміла:

http.createServer(app).listen(3000);

Створіть сервер і слухайте запити http на порту 3000.

Ми використовували nginx в одному з наших проектів, але це більше нагадувало балансир навантажень для декількох екземплярів nodejs.

Скажімо, у вас є два екземпляри nodejs, що працюють на портах 3000 і 3001. Тепер ви все ще можете використовуватись nginxяк сервер для прослуховування ваших фактичних httpдзвінків port 80і, можливо, захочете перенаправити ваш запит на nodejsсервер або, можливо, на інший сервер, більше схожий на loadbalancer. Таким чином, ви все ще можете використовувати все, що nginxпередбачено nodejs.

Хороше питання, яке тут вже задано .

Question 4

Припустимо, є готель під назвою Apache Hotel, який має офіціанта для кожного клієнта.

Як тільки клієнт замовляє салат, офіціант підходить до шеф-кухаря і каже йому. Поки шеф-кухар готує їжу, офіціант чекає. Ось,

Chef => File System,

Waiter => Thread,

Customer => Event.

Навіть коли клієнт замовляє воду, офіціант приносить лише після подачі салату. Офіціант продовжує чекати, поки шеф-кухар не приготує салат. Цей стан називається блокуючим. Навіть якщо готель зростає, кожен клієнт повинен мати різних офіціантів для обслуговування. Це збільшує блокування потоків (офіціанти).

Зараз у готелі Node є лише один офіціант для всіх клієнтів. Якщо перший клієнт замовляє суп, офіціант повідомляє шеф-кухареві і переходить до другого клієнта. Після приготування їжі офіціант доставляє замовнику. Тут замовник не буде чекати. Цей стан називається неблокуючим. Один офіціант (Thread) обслуговує всіх клієнтів і робить їх щасливими.

Таким чином, Node, який є однопотоковою програмою, дуже швидкий.