Come si confronta un "server" Node.js con i server Nginx o Apache?

90

Recentemente ho studiato Node.js e mi sono imbattuto in materiale sulla scrittura di semplici server basati su Node.js. Ad esempio, il seguente.

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

Ora, sebbene sembri capire cosa sta succedendo nel codice, sono leggermente confuso dalla terminologia. Quando sento il termine server, penso a cose come Apache o Nginx. Sono abituato a pensarli come a un contenitore che può contenere le mie applicazioni web. In che modo il server Node.js differisce dal server Nginx / Apache? Non è vero che un server basato su Node.js (cioè codice) può ancora essere posizionato all'interno di qualcosa come Nginx per essere eseguito? Allora perché entrambi sono chiamati "server"?

javascript  node.js  apache  nginx  webserver 
— Grato
fonte
2
Isn't it true that a Node.js based server (i.e. code) will still be placed within something like Nginx to run?No, non è corretto
— Jaromanda X
1
tecnicamente puoi eseguire la tua app e fare in modo che il nodo la serva al client che ricopre efficacemente il ruolo del server web, ma probabilmente stai mordendo più di quanto vorresti masticare. Recentemente ho letto questo fantastico articolo sull'argomento: nginx.com/blog/nginx-vs-apache-our-view
— datafunk
1
Vorrei chiarire che quando ho chiesto la differenza tra i due, NON stavo prendendo su apache vs nginx. Stavo parlando di Node.js vs Nginx.
— Grato l'
1
Non lasciarti fuorviare dal titolo. Se leggi l'articolo capirai perché ho detto che mentre puoi farlo da solo, potresti non voler ...
— datafunk

Risposte:

133

È un server, sì.

Un'applicazione web node.js è un server web a tutti gli effetti proprio come Nginx o Apache.

Puoi infatti servire la tua applicazione node.js senza utilizzare nessun altro server web. Basta cambiare il codice in:

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

In effetti, alcuni progetti utilizzano node.js come bilanciatore del carico front-end per altri server (incluso Apache).

Nota che node.js non è l'unico stack di sviluppo a farlo. Anche i framework di sviluppo Web in Go, Java e Swift lo fanno.

Perché?

In principio era il CGI. La CGI andava bene e funzionava bene. Apache riceverebbe una richiesta, scoprirà che l'URL deve eseguire un'app CGI, eseguire quell'app CGI e passare i dati come variabili di ambiente, leggere lo stdout e restituire i dati al browser.

Il problema è che è lento. Va bene quando l'app CGI era un piccolo programma C compilato staticamente, ma un gruppo di piccoli programmi C compilati staticamente è diventato difficile da mantenere. Così le persone hanno iniziato a scrivere in linguaggi di scripting. Poi è diventato difficile da mantenere e le persone hanno iniziato a sviluppare framework MVC orientati agli oggetti. Ora abbiamo iniziato ad avere problemi: OGNI RICHIESTA deve compilare tutte quelle classi e creare tutti quegli oggetti solo per servire un po 'di HTML, anche se non c'è nulla di dinamico da servire (perché il framework deve capire che non c'è nulla di dinamico da servire).

E se non avessimo bisogno di creare tutti quegli oggetti ad ogni richiesta?

Questo era quello che pensava la gente. E dal tentativo di risolvere quel problema derivarono diverse strategie. Uno dei primi è stato quello di incorporare interpreti direttamente nei server web come mod_phpin Apache. Le classi e gli oggetti compilati possono essere memorizzati in variabili globali e quindi memorizzati nella cache. Un'altra strategia era fare la pre-compilazione. E ancora un'altra strategia era quella di eseguire l'applicazione come un normale processo del server e parlare con il server web utilizzando un protocollo personalizzato come FastCGI.

Quindi alcuni sviluppatori hanno iniziato a utilizzare semplicemente HTTP come protocollo app-> server. In effetti, l'app è anche un server HTTP. Il vantaggio di questo è che non è necessario implementare alcun protocollo nuovo, possibilmente difettoso, possibilmente non testato e puoi eseguire il debug della tua app direttamente utilizzando un browser web (o anche comunemente curl). E non è necessario un server Web modificato per supportare la tua app, ma solo un server Web qualsiasi in grado di eseguire il proxy inverso o i reindirizzamenti.

Perché usare Apache / Nginx?

Quando servi un'app node.js, nota che sei l'autore del tuo server web. Qualsiasi potenziale bug nella tua app è un bug sfruttabile direttamente su Internet. Alcune persone non sono (giustamente) a proprio agio con questo.

L'aggiunta di un livello di Apache o Nginx davanti alla tua app node.js significa che hai un software collaudato e rinforzato per la sicurezza su Internet live come interfaccia per la tua app. Aggiunge un po 'di latenza (il proxy inverso) ma la maggior parte ritiene che ne valga la pena.

Questo era il consiglio standard nei primi giorni di node.js. Ma oggigiorno ci sono anche siti e servizi web che espongono node.js direttamente a Internet. Il http.Servermodulo è ora abbastanza ben testato su Internet per essere attendibile.

— slebetman
fonte
1
Ho letto in thread SO simili che mettere un layer Nginx o Apache davanti a Node "ne toglie la natura non bloccante". Qualche idea su questo?
— MrfksIV
4
@MrfksIV Sia Nginx che Apache2 non sono bloccanti. In effetti, hanno implementato il non blocco molto prima che esistesse node.js. Non utilizzare Apache1
— slebetman
14

NodeJs crea il proprio server. Come puoi vedere, la terminologia è abbastanza chiara:

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

Crea un server e ascolta le richieste http sulla porta 3000.

Abbiamo utilizzato nginx in uno dei nostri progetti, ma era più simile a un bilanciatore del carico per più istanze di nodejs.

Supponiamo che tu abbia due istanze di nodejs in esecuzione sulla porta 3000 e 3001, ora puoi ancora usarlo nginxcome server per ascoltare le tue httpchiamate effettive port 80e potresti voler reindirizzare la tua richiesta al nodejsserver o forse qualche altro server, più come un file loadbalancer. Quindi puoi ancora usare tutto ciò che nginxforniscenodejs .

Una buona domanda già posta qui .

— Naeem Shaikh
fonte
1
In realtà non sono troppo concentrato su nginx stesso. Mi chiedevo quale fosse la differenza tra il "server" node.js e gli altri "server" come apache o nginx. Non riuscivo a capire come il contenuto (cioè il codice del nodo) potesse essere equiparato al contenitore (cioè apache) ... Ma immagino che questa comprensione fosse errata. Ora, mi rendo conto che il codice node.js ascolta la porta 3000 proprio come Apache ascolta la porta 80 ... Quindi immagino che siano simili. Quindi è vero che sono entrambi server che hanno i loro punti di forza e di debolezza?
— Grato
2
createServer crea solo una porta in ascolto. Non serve a niente.
— Roger F. Gay
1
Quale sarebbe il punto di avere nodejs utilizzare createServer per ascoltare su una porta se non servirà qualcosa su richiesta a quella porta? ... Quindi è in un modo o nell'altro per estensione logica un "server", no?
— GG2
@ RogerF.Gay ... crea un listener su una porta specificata ed esegue una funzione di callback su richiesta in entrata. questo è quello che direi che crea un server.
— Naeem Shaikh
1
@ Naeem Shaikh Non serve a niente. Chiamare qualcosa che non serve a nulla un server non ha senso.
— Roger F. Gay,
1

Supponiamo che ci sia un hotel chiamato Apache Hotel che ha un cameriere per ogni cliente.

Non appena il cliente ordina un'insalata, il cameriere va dallo chef e glielo dice. Mentre lo chef prepara il cibo, il cameriere aspetta. Qui,

Chef => File System,

Waiter => Thread,

Customer => Event.

Anche quando il cliente ordina l'acqua, il cameriere porta solo dopo aver servito l'insalata. Il cameriere continua ad aspettare che l'insalata sia preparata dallo chef. Questo stato viene definito stato di blocco. Anche se l'hotel cresce, ogni cliente dovrebbe avere camerieri diversi da servire. Ciò aumenta il blocco dei thread (camerieri).

Ora, venendo al Node Hotel c'è un solo cameriere per tutti i clienti. Se il primo cliente ordina la zuppa, il cameriere lo dice allo chef e va dal secondo cliente. Dopo che il cibo è pronto, il cameriere lo consegna al cliente. Qui il cliente non aspetterà. Questo stato viene definito stato di non blocco. Il singolo cameriere (Thread) serve tutti i clienti e li rende felici.

Pertanto, Node, che è un'applicazione a thread singolo, è molto veloce.

— Vamshi Krishna
fonte
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.