Como um “servidor” Node.js se compara aos servidores Nginx ou Apache?

90

Tenho estudado Node.js recentemente e encontrei algum material sobre como escrever servidores simples baseados em Node.js. Por exemplo, o seguinte.

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

Agora, embora eu pareça entender o que está acontecendo no código, estou um pouco confuso com a terminologia. Quando ouço o termo servidor, penso em coisas como Apache ou Nginx. Estou acostumado a pensar neles como um contêiner que pode conter meus aplicativos da web. Como o servidor Node.js difere do servidor Nginx / Apache? Não é verdade que um servidor baseado em Node.js (ou seja, código) ainda pode ser colocado em algo como o Nginx para ser executado? Então, por que ambos são chamados de "servidores"?

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?Não, isso é incorreto
— Jaromanda X
1
tecnicamente, você pode executar seu aplicativo e ter um nó servindo-o para o cliente efetivamente preenchendo a função de servidor da web, mas provavelmente você está mordendo mais do que deseja mastigar. Recentemente li este ótimo artigo sobre o assunto: nginx.com/blog/nginx-vs-apache-our-view
— datafunk
1
Deixe-me esclarecer que, quando perguntei sobre a diferença entre os dois, NÃO estava falando sobre apache vs nginx. Eu estava falando sobre Node.js vs Nginx.
— Grato
1
Não deixe o título enganá-lo. Se você ler o artigo, vai entender porque eu disse que embora você possa fazer isso sozinho, você pode não querer ...
— datafunk

Respostas:

132

É um servidor, sim.

Um aplicativo da web node.js é um servidor da web completo, como o Nginx ou o Apache.

Você pode realmente servir seu aplicativo node.js sem usar qualquer outro servidor web. Basta alterar seu código para:

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

De fato, alguns projetos usam node.js como balanceador de carga de front-end para outros servidores (incluindo Apache).

Observe que node.js não é a única pilha de desenvolvimento a fazer isso. Estruturas de desenvolvimento da Web em Go, Java e Swift também fazem isso.

Por quê?

No começo era o CGI. CGI estava bem e funcionou bem. O Apache obteria uma solicitação, descobriria que a url precisa executar um aplicativo CGI, executar esse aplicativo CGI e passar dados como variáveis ​​de ambiente, ler o stdout e servir os dados de volta ao navegador.

O problema é que ele é lento. Não há problema quando o aplicativo CGI é um pequeno programa C compilado estaticamente, mas torna-se difícil manter um grupo de pequenos programas C compilados estaticamente. Então, as pessoas começaram a escrever em linguagens de script. Então isso se tornou difícil de manter e as pessoas começaram a desenvolver frameworks MVC orientados a objetos. Agora começamos a ter problemas - CADA PEDIDO deve compilar todas essas classes e criar todos esses objetos apenas para servir a algum HTML, mesmo que não haja nada dinâmico para servir (porque o framework precisa descobrir que não há nada dinâmico para servir).

E se não precisarmos criar todos esses objetos a cada solicitação?

Isso foi o que as pessoas pensaram. E da tentativa de resolver esse problema surgiram várias estratégias. Uma das primeiras foi incorporar intérpretes diretamente em servidores web, como mod_phpno Apache. Classes e objetos compilados podem ser armazenados em variáveis ​​globais e, portanto, em cache. Outra estratégia foi fazer uma pré-compilação. E ainda outra estratégia era executar o aplicativo como um processo de servidor regular e conversar com o servidor da web usando um protocolo personalizado como FastCGI.

Então, alguns desenvolvedores começaram simplesmente a usar HTTP como seu protocolo de aplicativo-> servidor. Na verdade, o aplicativo também é um servidor HTTP. A vantagem disso é que você não precisa implementar nenhum protocolo novo, possivelmente com erros, possivelmente não testado, e pode depurar seu aplicativo diretamente usando um navegador da web (ou também comumente curl). E você não precisa de um servidor web modificado para dar suporte ao seu aplicativo, apenas qualquer servidor web que possa fazer proxy reverso ou redirecionamentos.

Por que usar Apache / Nginx?

Ao servir um aplicativo node.js, observe que você é o autor de seu próprio servidor web. Qualquer bug potencial em seu aplicativo é um bug diretamente explorável na Internet. Algumas pessoas (com razão) não se sentem confortáveis ​​com isso.

Adicionar uma camada de Apache ou Nginx na frente de seu aplicativo node.js significa que você tem um software testado para batalha e com segurança reforçada na Internet ao vivo como uma interface para seu aplicativo. Ele adiciona um pouco de latência (o proxy reverso), mas a maioria considera que vale a pena.

Esse costumava ser o conselho padrão nos primeiros dias do node.js. Mas hoje em dia também existem sites e serviços da web que expõem o node.js diretamente para a Internet. O http.Servermódulo agora foi bem testado em batalhas na Internet para ser confiável.

— slebetman
fonte
1
Eu li em threads semelhantes do SO que colocar uma camada Nginx ou Apache na frente do Node "tira sua natureza sem bloqueios". Alguma opinião sobre isso?
— MrfksIV
4
@MrfksIV Tanto o Nginx quanto o Apache2 não são bloqueadores. Na verdade, eles implementaram o não-bloqueio muito antes de o node.js existir. Não use Apache1
— slebetman
14

NodeJs cria seu próprio servidor. Como você pode ver, a terminologia é bastante clara:

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

Crie um servidor e escute as solicitações de http na porta 3000.

Usamos o nginx em um de nossos projetos, mas era mais como um balanceador de carga para várias instâncias de nodejs.

Digamos que você tenha duas instâncias de nodejs em execução na porta 3000 e 3001. Agora você ainda pode usar nginxcomo um servidor para ouvir suas httpchamadas reais port 80e pode querer redirecionar sua solicitação para o nodejsservidor ou talvez algum outro servidor, mais como um loadbalancer. Portanto, você ainda pode usar o que for nginxfornecido nodejs.

Uma boa pergunta já feita aqui .

— Naeem Shaikh
fonte
1
Na verdade, não estou muito focado no próprio nginx. Eu estava me perguntando sobre a diferença entre o "servidor" node.js e os outros "servidores" como o apache ou nginx. Eu não conseguia entender como o contido (ou seja, código do nó) poderia ser equiparado ao contêiner (ou seja, apache) ... Mas acho que esse entendimento estava incorreto. Agora, eu percebo que o código node.js escuta a porta 3000 assim como o Apache escuta a porta 80 ... Então eu acho que eles são semelhantes. Portanto, é verdade dizer que ambos são servidores que têm seus próprios pontos fortes e fracos?
— Grato
2
createServer apenas cria uma porta de escuta. Não serve a nada.
— Roger F. Gay de
1
Qual seria o ponto de ter nodejs usando createServer para escutar em uma porta se não vai servir algo em uma solicitação para essa porta? ... Portanto, é de uma forma ou de outra por extensão lógica um “servidor”, não?
— GG2
@ RogerF.Gay ... cria um ouvinte em uma porta especificada e executa uma função de retorno de chamada na solicitação de entrada. isso é o que eu diria que cria um servidor.
— Naeem Shaikh
1
@Naeem Shaikh Não serve a nada. Chamar algo que não serve a nada de servidor não faz sentido.
— Roger F. Gay
1

Suponha que haja um hotel chamado Apache Hotel que tenha um garçom para cada cliente.

Assim que o cliente pede uma salada, o garçom vai até o chef e avisa. Enquanto o chef prepara a comida, o garçom espera. Aqui,

Chef => File System,

Waiter => Thread,

Customer => Event.

Mesmo quando o cliente pede água, o garçom só traz depois de servir a salada. O garçom fica esperando até que a salada seja preparada pelo chef. Este estado é conhecido como estado de bloqueio. Mesmo que o hotel cresça, cada cliente deve ter garçons diferentes para servir. Isso aumenta o bloqueio de threads (waiters).

Agora, chegando ao Node Hotel, há apenas um garçom para todos os clientes. Se o primeiro cliente pedir sopa, o garçom informa o chef e vai para o segundo cliente. Depois que a comida está pronta, o garçom entrega ao cliente. Aqui o cliente não espera. Este estado é conhecido como estado de não bloqueio. O único garçom (Thread) atende todos os clientes e os deixa felizes.

Portanto, o Node, que é um aplicativo de thread único, é muito rápido.

— Vamshi Krishna
fonte
Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.