Чем «сервер» Node.js отличается от серверов Nginx или Apache?

86

Недавно я изучал 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 для запуска? Так почему оба называются «серверами»?

javascript node.js apache nginx webserver Благодарный
источник
2
Isn't it true that a Node.js based server (i.e. code) will still be placed within something like Nginx to run?Нет, это неверно
Jaromanda X 08
1
технически вы можете запустить свое приложение и иметь узел, обслуживающий его до клиента, эффективно выполняющий роль веб-сервера, но вы, вероятно, откусываете больше, чем хотите прожевать. Недавно я прочитал эту замечательную статью на эту тему: nginx.com/blog/nginx-vs-apache-our-view
datafunk
1
Позвольте мне пояснить, что когда я спросил о разнице между ними, я НЕ имел в виду apache и nginx. Я говорил о Node.js и Nginx.
Благодарный
1
Не позволяйте названию ввести вас в заблуждение. Если вы прочтете статью, то поймете, почему я сказал, что, хотя вы можете сделать это самостоятельно, вы можете не захотеть ...
datafunk

Ответы:

128

Да, это сервер.

Веб-приложение 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 и передать данные в качестве переменных среды, прочитать стандартный вывод и передать данные обратно в браузер.

Проблема в том, что он медленный. Ничего страшного, когда приложение CGI было небольшой статически скомпилированной программой на языке C, но группу небольших статически скомпилированных программ на языке C стало трудно поддерживать. Итак, люди начали писать на скриптовых языках. Затем это стало трудно поддерживать, и люди начали разрабатывать объектно-ориентированные среды MVC. Теперь у нас начались проблемы - КАЖДЫЙ ЗАПРОС должен скомпилировать все эти классы и создать все эти объекты только для обслуживания некоторого HTML, даже если нет ничего динамического для обслуживания (поскольку фреймворк должен выяснить, что нет ничего динамического для обслуживания).

Что, если нам не нужно создавать все эти объекты при каждом запросе?

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

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

Зачем использовать Apache / Nginx?

Когда вы обслуживаете приложение node.js, обратите внимание, что вы являетесь автором собственного веб-сервера. Любая потенциальная ошибка в вашем приложении - это ошибка, которую можно напрямую использовать в Интернете. Некоторым это (справедливо) не нравится.

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

Раньше это был стандартный совет на заре создания node.js. Но в наши дни также существуют сайты и веб-сервисы, которые предоставляют node.js напрямую в Интернет. В http.Serverнастоящее время модуль довольно хорошо протестирован в Интернете, чтобы ему можно было доверять.

слебетман
источник
1
Я читал в аналогичных потоках SO, что размещение уровня Nginx или Apache перед Node «убирает его неблокирующий характер». Есть мысли по этому поводу?
MrfksIV 09
3
@MrfksIV И Nginx, и Apache2 не блокируются. Фактически они реализовали неблокирование задолго до того, как появился node.js. Не используйте Apache1
slebetman
14

NodeJs создает свой собственный сервер. Как видите, терминология довольно понятна:

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

Создайте сервер и слушайте HTTP-запросы на порту 3000.

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

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

Хороший вопрос уже задавал здесь .

Наим Шейх
источник
1
На самом деле я не слишком сосредоточен на самом nginx. Мне было интересно узнать о разнице между «сервером» node.js и другими «серверами», такими как apache или nginx. Я не мог понять, как содержимое (то есть код узла) может быть приравнено к контейнеру (то есть apache) ... Но я думаю, это понимание было неверным. Теперь я понимаю, что код node.js слушает порт 3000 так же, как Apache слушает порт 80 .... Так что, я думаю, они похожи. Так это правда, что оба сервера имеют свои сильные и слабые стороны?
Grateful
2
createServer просто создает порт прослушивания. Это ничего не служит.
Роджер Ф. Гей
1
Какой смысл в использовании nodejs createServer для прослушивания порта, если он не собирается обслуживать что-либо по запросу к этому порту? ... Следовательно, это так или иначе по логическому расширению «сервер», не так ли?
GG2
@ RogerF.Gay ... он создает прослушиватель на указанном порту и выполняет функцию обратного вызова по входящему запросу. вот что я бы сказал, он создает сервер.
Наим Шейх
1
@ Наим Шейх Это ничего не служит. Называть сервером то, что ничего не обслуживает, не имеет смысла.
Роджер Ф. Гей
1

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

Как только клиент заказывает салат, официант идет к повару и сообщает ему. Пока шеф-повар готовит еду, официант ждет. Вот,

Chef => File System,

Waiter => Thread,

Customer => Event.

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

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

Таким образом, Node, который представляет собой однопоточное приложение, работает очень быстро.

Вамши Кришна
источник