Jak wypada „serwer” Node.js w porównaniu z serwerami Nginx lub Apache?

86

Niedawno studiowałem Node.js i znalazłem materiał na temat pisania prostych serwerów opartych na Node.js. Na przykład następujące.

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!");
});

Teraz, chociaż wydaje mi się, że rozumiem, co się dzieje w kodzie, jestem nieco zdezorientowany terminologią. Kiedy słyszę termin serwer, myślę o takich rzeczach jak Apache czy Nginx. Przywykłem do myślenia o nich jako o pojemniku, w którym mogą znajdować się moje aplikacje internetowe. Czym serwer Node.js różni się od serwera Nginx / Apache? Czy nie jest prawdą, że serwer oparty na Node.js (tj. Kod) nadal można umieścić w czymś takim jak Nginx, aby działał? Dlaczego więc oba nazywane są „serwerami”?

javascript  node.js  apache  nginx  webserver 
— Wdzięczny
źródło
2
Isn't it true that a Node.js based server (i.e. code) will still be placed within something like Nginx to run?Nie, to nieprawda
— Jaromanda X
1
technicznie rzecz biorąc, możesz uruchomić aplikację i mieć węzeł obsługujący ją klientowi, skutecznie wypełniając rolę serwera internetowego, ale prawdopodobnie gryziesz więcej, niż chcesz. Niedawno przeczytałem ten świetny artykuł na ten temat: nginx.com/blog/nginx-vs-apache-our-view
— datafunk
1
Pozwólcie, że wyjaśnię, że kiedy zapytałem o różnicę między nimi, NIE brałem pod uwagę kwestii apache vs nginx. Mówiłem o Node.js vs Nginx.
— Wdzięczny
1
Nie daj się zwieść tytułowi. Jeśli przeczytasz ten artykuł, zrozumiesz, dlaczego powiedziałem, że chociaż możesz to zrobić sam, możesz nie chcieć ...
— datafunk

Odpowiedzi:

128

To serwer, tak.

Aplikacja sieciowa node.js to pełnoprawny serwer WWW, taki jak Nginx czy Apache.

Rzeczywiście możesz obsługiwać swoją aplikację node.js bez korzystania z innego serwera WWW. Po prostu zmień swój kod na:

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

Rzeczywiście, niektóre projekty używają node.js jako front- endowego systemu równoważenia obciążenia dla innych serwerów (w tym Apache).

Zauważ, że node.js nie jest jedynym stosem programistycznym, który to robi. Robią to również frameworki do tworzenia stron internetowych w Go, Java i Swift.

Czemu?

Na początku było CGI. CGI było w porządku i działało OK. Apache otrzymałby żądanie, stwierdził, że adres URL musi wykonać aplikację CGI, wykonać tę aplikację CGI i przekazać dane jako zmienne środowiskowe, odczytać standardowe wyjście i przesłać dane z powrotem do przeglądarki.

Problem w tym, że jest powolny. Jest OK, gdy aplikacja CGI była małym statycznie skompilowanym programem w C, ale grupa małych statycznie skompilowanych programów w C stała się trudna do utrzymania. Więc ludzie zaczęli pisać w językach skryptowych. Potem stało się to trudne do utrzymania i ludzie zaczęli tworzyć zorientowane obiektowo frameworki MVC. Teraz zaczęliśmy mieć kłopoty - KAŻDE ŻĄDANIE musi skompilować wszystkie te klasy i utworzyć wszystkie te obiekty tylko po to, aby obsłużyć jakiś HTML, nawet jeśli nie ma nic dynamicznego do obsłużenia (ponieważ framework musi dowiedzieć się, że nie ma nic dynamicznego do obsłużenia).

A co, jeśli nie musimy tworzyć wszystkich tych obiektów w każdym żądaniu?

Tak myśleli ludzie. Z próby rozwiązania tego problemu wyszło kilka strategii. Jednym z najwcześniejszych było osadzenie tłumaczy bezpośrednio na serwerach internetowych, takich jak mod_phpApache. Skompilowane klasy i obiekty mogą być przechowywane w zmiennych globalnych, a zatem buforowane. Inną strategią było wykonanie wstępnej kompilacji. Kolejną strategią było uruchomienie aplikacji jako zwykłego procesu serwera i rozmowa z serwerem WWW przy użyciu niestandardowego protokołu, takiego jak FastCGI.

Następnie niektórzy programiści zaczęli po prostu używać HTTP jako protokołu aplikacji-> serwera. W efekcie aplikacja jest również serwerem HTTP. Zaletą tego jest to, że nie musisz implementować żadnego nowego, prawdopodobnie błędnego, prawdopodobnie nie przetestowanego protokołu i możesz debugować swoją aplikację bezpośrednio za pomocą przeglądarki internetowej (lub często curl). I nie potrzebujesz zmodyfikowanego serwera internetowego do obsługi swojej aplikacji, po prostu dowolnego serwera internetowego, który może wykonywać odwrotne proxy lub przekierowania.

Dlaczego warto korzystać z Apache / Nginx?

Gdy udostępniasz aplikację node.js, pamiętaj, że jesteś autorem własnego serwera internetowego. Każdy potencjalny błąd w Twojej aplikacji to błąd, który można bezpośrednio wykorzystać w Internecie. Niektórym ludziom (słusznie) to nie odpowiada.

Dodanie warstwy Apache lub Nginx przed aplikacją node.js oznacza, że ​​masz przetestowane w walce, zabezpieczone oprogramowanie w Internecie na żywo jako interfejs do Twojej aplikacji. Dodaje odrobinę opóźnienia (odwrotne proxy), ale większość uważa, że ​​warto.

To była standardowa rada we wczesnych dniach node.js. Ale w dzisiejszych czasach istnieją również witryny i usługi internetowe, które udostępniają node.js bezpośrednio w Internecie. http.ServerModuł jest teraz dość dobrze bitwa testowane w internecie można ufać.

— slebetman
źródło
1
Czytałem w podobnych wątkach SO, że umieszczenie warstwy Nginx lub Apache przed Node "usuwa jego nieblokującą naturę". Jakieś przemyślenia na ten temat?
— MrfksIV
3
@MrfksIV Zarówno Nginx, jak i Apache2 nie blokują. W rzeczywistości zaimplementowali nieblokowanie na długo przed powstaniem node.js. Nie używaj Apache1
— slebetman
14

NodeJs tworzy własny serwer. Jak widać, terminologia jest dość jasna:

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

Utwórz serwer i nasłuchuj żądań http na porcie 3000.

Użyliśmy nginx w jednym z naszych projektów, ale był on bardziej podobny do loadbalancera dla wielu instancji nodejs.

Powiedzmy, że masz dwie instancje nodejs działające na portach 3000 i 3001. Teraz możesz nadal używać nginxjako serwera do nasłuchiwania twoich rzeczywistych httppołączeń port 80i możesz chcieć przekierować twoje żądanie do nodejsserwera lub może innego serwera, bardziej jak loadbalancer. Więc nadal możesz używać tego, co nginxzapewnia nodejs.

Dobre pytanie już tutaj zadane .

— Naeem Shaikh
źródło
1
Właściwie nie jestem zbyt skupiony na samym nginxie. Zastanawiałem się nad różnicą między „serwerem” node.js a innymi „serwerami”, takimi jak Apache czy Nginx. Nie mogłem zrozumieć, jak zawarty (tj. Kod węzła) można przyrównać do kontenera (tj. Apache) ... Ale wydaje mi się, że to zrozumienie było nieprawidłowe. Teraz zdaję sobie sprawę, że kod node.js nasłuchuje na porcie 3000, tak jak Apache nasłuchuje na porcie 80 ... Więc myślę, że są podobne. Więc prawdą jest, że oba są serwerami, które mają swoje mocne i słabe strony?
— Wdzięczny
2
createServer po prostu tworzy port nasłuchiwania. To nic nie służy.
— Roger F. Gay
1
Jaki byłby sens, gdyby nodejs używał createServer do nasłuchiwania na porcie, jeśli nie zamierza obsługiwać czegoś na żądanie do tego portu? ... Dlatego w ten czy inny sposób jest to logiczne rozszerzenie "serwera", prawda?
— GG2
@ RogerF.Gay ... tworzy nasłuchiwanie na określonym porcie i wykonuje funkcję zwrotną na przychodzące żądanie. to właśnie powiedziałbym, że tworzy serwer.
— Naeem Shaikh
1
@Naeem Shaikh To nic nie służy. Nazywanie czegoś, co do niczego nie służy, jako serwer nie ma sensu.
— Roger F. Gay
1

Załóżmy, że istnieje hotel o nazwie Apache Hotel, który ma kelnera dla każdego klienta.

Gdy klient zamówi sałatkę, kelner udaje się do szefa kuchni i mówi mu o tym. Podczas gdy szef kuchni przygotowuje jedzenie, kelner czeka. Tutaj,

Chef => File System,

Waiter => Thread,

Customer => Event.

Nawet gdy klient zamawia wodę, kelner przynosi dopiero po podaniu sałatki. Kelner czeka na przygotowanie sałatki przez szefa kuchni. Ten stan jest nazywany stanem blokującym. Nawet jeśli hotel się rozrasta, każdy klient powinien mieć różnych kelnerów do obsługi. Zwiększa to blokowanie wątków (kelnerów).

Teraz w Node Hotel jest tylko jeden kelner dla wszystkich klientów. Jeśli pierwszy klient zamówi zupę, kelner informuje o tym szefa kuchni i udaje się do drugiego klienta. Po przygotowaniu potraw kelner dostarcza je do klienta. Tutaj klient nie będzie czekał. Ten stan jest nazywany stanem nieblokującym. Jeden kelner (wątek) obsługuje wszystkich klientów i sprawia, że ​​są szczęśliwi.

W ten sposób Node, który jest aplikacją jednowątkową, jest bardzo szybki.

— Vamshi Krishna
źródło
Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.