Eu já vi pessoas recomendando combinar tudo isso em um fluxo, mas elas parecem ter muitos recursos sobrepostos, então eu gostaria de descobrir por que você pode passar por três programas diferentes antes de acessar o servidor da Web real.

nginx:

• ssl: sim
• comprimir: sim
• cache: sim
• piscina de back-end: sim

verniz:

• ssl: não (stunnel?)
• comprimir: ?
• cache: yes (recurso principal)
• piscina de back-end: sim

haproxy:

• ssl: não (stunnel)
• comprimir: ?
• cache: no
• pool de back-end: sim (recurso principal)

A intenção de encadear tudo isso na frente de seus principais servidores da Web é apenas para obter alguns dos principais benefícios dos recursos?

Parece bastante frágil ter tantos daemons juntos fazendo coisas semelhantes.

Qual é a sua preferência de implantação e pedidos e por quê?

Basta colocar ..

O HaProxy é o melhor loadbalancer de código aberto do mercado.
O verniz é o melhor filtro de arquivos estáticos de código aberto do mercado.
O Nginx é o melhor servidor de código aberto do mercado.

(é claro que esta é a minha opinião e de muitas outras pessoas)

Mas, geralmente, nem todas as consultas passam por toda a pilha.

Tudo passa por haproxy e nginx / múltiplos nginx.
A única diferença é que você "aparafusa" o verniz para solicitações estáticas.

• qualquer solicitação é balanceada por carga para redundância e taxa de transferência (bom, redundância escalável)
• qualquer solicitação de arquivos estáticos está primeiro atingindo o cache de verniz (bom, rápido)
• qualquer solicitação dinâmica vai diretamente para o back-end (ótimo, o verniz não é usado)

No geral, esse modelo se encaixa em uma arquitetura escalável e crescente (elimine o haproxy se você não tiver vários servidores)

Espero que isso ajude: D

Nota: Na verdade, também apresentarei consultas de libra para SSL: D
Você pode ter um servidor dedicado para descriptografar solicitações SSL e distribuir solicitações padrão para a pilha de back-end: D (faz com que toda a pilha seja mais rápida e simples)

Prefácio

Atualização em 2016. As coisas estão evoluindo, todos os servidores estão melhorando, todos eles suportam SSL e a Web está mais incrível do que nunca.

A menos que seja declarado, o seguinte é direcionado a profissionais de negócios e startups, dando suporte a milhares a milhões de usuários.

Essas ferramentas e arquiteturas exigem muitos usuários / hardware / dinheiro. Você pode tentar isso em um laboratório doméstico ou criar um blog, mas isso não faz muito sentido.

Como regra geral, lembre-se de que deseja manter as coisas simples . Todo middleware anexado é outra parte crítica do middleware a ser mantida. A perfeição não é alcançada quando não há nada a acrescentar, mas quando não há mais nada a remover.

Algumas implantações comuns e interessantes

HAProxy (balanceamento) + nginx (aplicativo php + cache)

O servidor web está executando o nginx php. Quando o nginx já está lá, ele também pode lidar com o cache e os redirecionamentos.

HAProxy ---> nginx-php
A       ---> nginx-php
P       ---> nginx-php
r       ---> nginx-php
o       ---> nginx-php
x       ---> nginx-php
y       ---> nginx-php

HAProxy (balanceamento) + Verniz (armazenamento em cache) + Tomcat (aplicativo Java)

O HAProxy pode redirecionar para o Varnish com base no URI da solicitação (* .jpg * .css * .js).

HAProxy ---> tomcat
A       ---> tomcat
        ---> tomcat
P       ---> tomcat <----+
r       ---> tomcat <---+|
o                       ||
x       ---> varnish <--+|
y       ---> varnish <---+

HAProxy (balanceamento) + nginx (SSL para o host e armazenamento em cache) + Servidor da Web (aplicativo)

Os servidores da Web não falam SSL, embora TODOS DEVEM FALAR SSL ( especialmente este link HAProxy-WebServer com informações de usuários particulares passando pelo EC2 ). A adição de um nginx local permite trazer o SSL até o host. Uma vez que o nginx esteja lá, é melhor fazer alguns cache e reescrever URL.

Nota : O redirecionamento de porta 443: 8080 está acontecendo, mas não faz parte dos recursos. Não há sentido em redirecionar portas. O balanceador de carga pode falar diretamente com o servidor da web: 8080.

          (nginx + webserver on same host)
HAProxy ---> nginx:443 -> webserver:8080
A       ---> nginx:443 -> webserver:8080
P       ---> nginx:443 -> webserver:8080
r       ---> nginx:443 -> webserver:8080
o       ---> nginx:443 -> webserver:8080
x       ---> nginx:443 -> webserver:8080
y       ---> nginx:443 -> webserver:8080

Middleware

HAProxy: O balanceador de carga

Principais Características :

• Balanceamento de carga (TCP, HTTP, HTTPS)
• Vários algoritmos (round robin, ip de origem, cabeçalhos)
• Persistência da sessão
• Terminação SSL

Alternativas similares : nginx (servidor da web multifuncional configurável como balanceador de carga)
Diferentes alternativas : nuvem (Amazon ELB, balanceador de carga do Google), hardware (F5, fortinet, citrix netscaler), outros e no mundo inteiro (DNS, anycast, CloudFlare)

O que o HAProxy faz e quando você precisa usá-lo?
Sempre que você precisar de balanceamento de carga. HAProxy é o ir para a solução.

Exceto quando você quer muito barato OU rápido e sujo OU você não tem as habilidades disponíveis, você pode usar um ELB: D

Exceto quando você está no setor bancário / governamental / similar, exigindo usar seu próprio datacenter com requisitos rígidos (infraestrutura dedicada, failover confiável, 2 camadas de firewall, material de auditoria, SLA para pagar x% por minuto de tempo de inatividade, tudo em um) você pode colocar 2 F5 em cima do rack que contém seus 30 servidores de aplicativos.

Exceto quando você deseja passar de 100k HTTP (S) [e vários sites], é necessário ter múltiplos HAProxy com uma camada de balanceamento de carga [global] na frente deles (cloudflare, DNS, anycast). Teoricamente, o balanceador global poderia falar diretamente com os servidores da Web, permitindo abandonar o HAProxy. Normalmente, no entanto, você DEVE manter o HAProxy (s) como ponto de entrada público do seu datacenter e ajustar as opções avançadas para equilibrar de maneira justa os hosts e minimizar a variação.

Opinião pessoal : Um projeto pequeno, contido e de código aberto, inteiramente dedicado a UM VERDADEIRO OBJETIVO. Entre a configuração mais fácil (arquivo ONE), o software de código aberto mais útil e mais confiável que já encontrei na minha vida.

Nginx: Apache que não é ruim

Principais Características :

• Servidor Web HTTP ou HTTPS
• Execute aplicativos em CGI / PHP / outros
• Redirecionamento / reescrita de URL
• Controle de acesso
• Manipulação de cabeçalhos HTTP
• Armazenamento em cache
• Proxy Reverso

Alternativas similares : Apache, Lighttpd, Tomcat, Gunicorn ...

O Apache era o servidor da web de fato, também conhecido como um gigantesco cluster de dezenas de módulos e milhares de linhas httpd.confem cima de uma arquitetura de processamento de solicitação interrompida. O nginx refaz tudo isso, com menos módulos, configuração (um pouco) mais simples e uma arquitetura de núcleo melhor.

O que o nginx faz e quando você precisa usá-lo?
Um servidor da web destina-se a executar aplicativos. Quando seu aplicativo é desenvolvido para rodar no nginx, você já possui o nginx e também pode usar todos os seus recursos.

Exceto quando seu aplicativo não se destina a ser executado no nginx e o nginx não pode ser encontrado em nenhum lugar na sua pilha (o Java compra alguém?), Então há pouco sentido no nginx. É provável que os recursos do servidor da web existam no seu servidor da web atual e as outras tarefas sejam melhor tratadas pela ferramenta dedicada apropriada (HAProxy / Varnish / CDN).

Exceto quando seu servidor / aplicativo está sem recursos, difíceis de configurar e / ou você prefere morrer do que olhar para ele (Gunicorn alguém?), Você pode colocar um nginx na frente (ou seja, localmente em cada nó) para executar a URL reescrever, enviar redirecionamentos 301, impor controle de acesso, fornecer criptografia SSL e editar cabeçalhos HTTP on-the-fly. [Esses são os recursos esperados de um servidor da web]

Verniz: O servidor de cache

Principais Características :

• Armazenamento em cache
• Cache Avançado
• Cache de grãos finos
• Armazenamento em cache

Alternativas similares : nginx (servidor web multiuso configurável como servidor de armazenamento em cache)
Alternativas diferentes : CDN (Akamai, Amazon CloudFront, CloudFlare), Hardware (F5, Fortinet, Citrix Netscaler)

O que o verniz faz e quando você precisa usá-lo?
Faz cache, apenas cache. Geralmente não vale a pena o esforço e é uma perda de tempo. Tente CDN. Esteja ciente de que o cache é a última coisa com a qual você deve se preocupar ao executar um site.

Exceto quando você está executando um site exclusivamente sobre fotos ou vídeos, deve analisar cuidadosamente a CDN e pensar seriamente em cache.

Exceto quando você é forçado a usar seu próprio hardware em seu próprio datacenter (a CDN não é uma opção) e seus servidores da Web são péssimos ao fornecer arquivos estáticos (adicionar mais servidores da Web não ajudam), o Varnish é o último recurso.

Exceto quando você tem um site com conteúdo principalmente estático, porém complexo, gerado dinamicamente (consulte os parágrafos a seguir), o Varnish pode economizar muito poder de processamento em seus servidores da web.

O cache estático é superestimado em 2016

O armazenamento em cache é quase gratuito, sem dinheiro e sem tempo. Basta assinar o CloudFlare, CloudFront, Akamai ou MaxCDN. O tempo que levo para escrever essa linha é maior que o tempo necessário para configurar o armazenamento em cache E a cerveja que estou segurando na mão é mais cara que a assinatura mediana do CloudFlare.

Todos esses serviços funcionam imediatamente para estáticos * .css * .js * .png e muito mais. De fato, eles respeitam principalmente a Cache-Controldiretiva no cabeçalho HTTP. A primeira etapa do armazenamento em cache é configurar seus servidores da Web para enviar diretivas de cache apropriadas. Não importa qual CDN, qual verniz, qual navegador está no meio.

Considerações de desempenho

O verniz foi criado no momento em que os servidores da Web comuns estavam engasgando para exibir uma foto de gato em um blog. Hoje em dia, uma única instância do servidor da web moderno, assíncrono e multi-threaded, médio e moderno, pode entregar confiavelmente gatinhos para um país inteiro. Cortesia de sendfile().

Fiz alguns testes rápidos de desempenho para o último projeto em que trabalhei. Uma única instância do tomcat pode servir de 21.000 a 33.000 arquivos estáticos por segundo no HTTP (arquivos de teste de 20B a 12kB com contagem variável de conexões HTTP / cliente). O tráfego de saída sustentado está além de 2,4 Gb / s. A produção terá apenas interfaces de 1 Gb / s. Não pode fazer melhor do que o hardware, não adianta nem tentar o Varnish.

Armazenamento em cache complexo, alterando conteúdo dinâmico

Os servidores de CDN e de armazenamento em cache geralmente ignoram URL com parâmetros como ?article=1843, ignoram qualquer solicitação com cookies de sessão ou usuários autenticados e ignoram a maioria dos tipos MIME, incluindo o application/jsonde /api/article/1843/info. Existem opções de configuração disponíveis, mas geralmente não são refinadas, e sim "tudo ou nada".

O verniz pode ter regras complexas personalizadas (consulte VCL) para definir o que é aceitável e o que não é. Essas regras podem armazenar em cache conteúdo específico por URI, cabeçalhos e cookies de sessão do usuário atual e tipo MIME e conteúdo TODOS JUNTOS. Isso pode economizar muito poder de processamento nos servidores da Web para um padrão de carga muito específico. É quando o verniz é útil e IMPRESSIONANTE.

Conclusão

Demorei um pouco para entender todas essas peças, quando usá-las e como elas se encaixam. Espero que isso possa ajudá-lo.

Isso acaba sendo bastante longo (6 horas para escrever. OMG!: O). Talvez eu deva começar um blog ou um livro sobre isso. Curiosidade: parece não haver um limite no tamanho da resposta.

É verdade que as três ferramentas compartilham recursos comuns. A maioria das configurações é boa com qualquer combinação de 2 entre as 3. Depende de qual é o objetivo principal. É comum aceitar sacrificar algum cache se você souber que o servidor de aplicativos é rápido em estática (por exemplo: nginx). É comum sacrificar alguns recursos de balanceamento de carga se você deseja instalar dezenas ou centenas de servidores e não se preocupa em tirar o máximo proveito deles nem em solucionar problemas. É comum sacrificar alguns recursos do servidor da Web se você pretende executar um aplicativo distribuído com muitos componentes em todos os lugares. Ainda assim, algumas pessoas constroem fazendas interessantes com todas elas.

Você deve ter em mente que está falando de três produtos sólidos. Geralmente, você não precisará balancear sua carga. Se você precisar de SSL frontal, o nginx primeiro como proxy reverso é bom. Se você não precisar disso, o verniz na frente está ótimo. Em seguida, você pode colocar haproxy para equilibrar a carga de seus aplicativos. Às vezes, você também deseja mudar para diferentes farms de servidores no haproxy, dependendo dos tipos ou caminhos de arquivos.

Às vezes, você terá que se proteger contra ataques DDoS pesados, e a haproxy na frente será mais adequada do que as outras.

Em geral, você não deve se preocupar com o que fazer entre suas escolhas. Você deve escolher como montá-los para obter a melhor flexibilidade para suas necessidades agora e no futuro. Mesmo se você empilhar várias delas várias vezes, às vezes pode ser certo, dependendo de suas necessidades.

Esperando que isso ajude!

Todas as outras respostas são anteriores a 2010, portanto adicionando uma comparação atualizada.

Nginx

• Um servidor web completo, outros recursos também podem ser usados. Por exemplo: compactação HTTP
• Suporte SSL
• Muito leve, pois o Nginx foi projetado para ser leve desde o início.
• Desempenho de cache próximo ao Varnish
• Desempenho próximo ao balanceamento de carga HAProxy

Verniz

• melhor para cenários de armazenamento em cache complexos e incorporados aos aplicativos.
• melhor cacher de arquivo estático
• Sem suporte SSL
• Comedor de memória e CPU

Haproxy

• melhor balanceador de carga, para recursos avançados de balanceamento de carga, comparáveis ​​aos balanceadores de carga de hardware
• SSL é suportado desde 1.5.0
• Mais simples, ser apenas um proxy tcp sem uma implementação http, o que o torna mais rápido e menos propenso a erros.

Portanto, o melhor método parece estar implementando todos eles em uma ordem apropriada.

No entanto, para fins gerais, o Nginx é melhor quando você obtém desempenho acima da média para todos: armazenamento em cache, proxy reverso, balanceamento de carga , com muito pouca sobrecarga na utilização de recursos. E então você tem SSL e recursos completos de servidor da web.

O Varnish tem suporte para balanceamento de carga: http://www.varnish-cache.org/trac/wiki/LoadBalancing

O Nginx tem suporte para balanceamento de carga: http://wiki.nginx.org/NginxHttpUpstreamModule

Eu simplesmente configuraria isso com verniz + stunnel. Se eu precisasse do nginx por algum outro motivo, usaria apenas o nginx + verniz. Você pode fazer com que o nginx aceite conexões SSL e faça o proxy delas para envernizar e, em seguida, faça o verniz falar com o nginx via http.

Algumas pessoas podem jogar nginx (ou Apache) na mistura porque essas são ferramentas de propósito um pouco mais geral do que o verniz. Por exemplo, se você deseja transformar o conteúdo (por exemplo, usando XDV, filtros apache, etc) na camada de proxy, você precisaria de um deles, porque o Varnish não pode fazer isso sozinho. Algumas pessoas podem estar mais familiarizadas com a configuração dessas ferramentas, por isso é mais fácil usar o Varnish como um cache simples e fazer o balanceamento de carga em outra camada, porque eles já estão familiarizados com o Apache / nginx / haproxy como balanceador de carga.