Node.js основывал сервер по сравнению с чем-то как Apache сервер HTTP

Я изучал 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 для выполнения? Итак, почему обоих называют "серверами", хотя код Node.js, кажется, приложение, которое может быть помещено и служило использованию Nginx.

62
задан 8 August 2016 в 09:32

3 ответа

Это - сервер, да.

А node.js веб-приложение является законченным веб-сервером точно так же, как Nginx или Apache.

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

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

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

Примечание, что node.js не является единственной стопкой разработки, чтобы сделать это. Платформы веб-разработки в Движении, Java и Swift также делают это.

, Почему?

В начале был CGI. CGI был прекрасен и работал хорошо. Apache получил бы запрос, найти, что URL должен выполнить приложение CGI, выполните то приложение CGI и передайте данные как переменные среды, считайте stdout и служите данным назад браузеру.

проблема состоит в том, что это медленно. Хорошо, когда приложение 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 модуль теперь довольно хорошо проверен в бою в Интернете, которому будут доверять.

99
ответ дан 31 October 2019 в 14:01

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

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

Chef => File System,

Waiter => Thread,

Customer => Event.

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

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

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

2
ответ дан 31 October 2019 в 14:01

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

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

Создают сервер и прислушиваются к запросам HTTP на порте 3000.

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

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

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

11
ответ дан 31 October 2019 в 14:01

Другие вопросы по тегам:

Похожие вопросы: