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.