Construção de servidor de cache de proxy reverso nginx

Tags relacionadas：1. Nginx Ingress Controller
2. Parse nginx logs

Resumo: É usado para fazer proxy das solicitações de conexão (como VPN/NAT) da rede interna para a Internet.

Os serviços de proxy podem ser divididos simplesmente em proxy direto e proxy reverso:

Proxy direto: O cliente especifica o servidor proxy e envia a solicitação HTTP, que originalmente seria enviada diretamente ao servidor web de destino, ao servidor proxy. Em seguida, o servidor proxy acessa o servidor web e retorna a resposta do servidor web ao cliente.

Proxy reverso: Ao contrário do proxy direto, se a rede local fornece recursos para a Internet e permite que outros usuários na Internet acessem recursos na rede local, também é possível configurar um servidor proxy, e o serviço fornecido é um proxy reverso. O servidor de proxy reverso aceita conexões da Internet, encaminha a solicitação ao servidor na rede interna e envia a resposta de volta aos

Clientes na Internet solicitando uma conexão:

1. Proxy reverso nginx: o agendador do servidor web

1. Proxy reverso significa que o servidor proxy aceita a solicitação de conexão do cliente e, em seguida, encaminha a solicitação ao servidor web (pode ser Apache, Nginx, Tomcat, IIS etc.) na rede, e o resultado obtido do servidor web é retornado ao cliente que solicitou a conexão. O servidor proxy atua como um servidor para o mundo externo.

Como pode ser visto na figura acima: o servidor de proxy reverso recebe a solicitação HTTP do site e a encaminha. Além disso, como servidor de proxy reverso, o Nginx pode encaminhar solicitações para diferentes servidores web de back-end de acordo com o conteúdo da solicitação do usuário, como separação estática e dinâmica. Por exemplo, é possível criar vários hosts virtuais no Nginx, permitindo acessar diferentes servidores web ou clusters web no back-end ao inserir diferentes nomes de domínio (URLs) no navegador.

2. Qual é a função do proxy reverso?

① Proteger a segurança do site: qualquer solicitação da Internet deve passar primeiro por um servidor proxy;

wKioL1jsz9yAHyulAABvTU4R-Ew435.png-wh_50

② Acelerar solicitações web configurando a função de cache: alguns recursos estáticos do servidor web real podem ser armazenados em cache para reduzir a pressão de carga do servidor web real;

wKiom1jsz-nwYDqSAABjrKK3l5E661.png-wh_50

③ Realizar balanceamento de carga: Atuar como servidor de balanceamento de carga para distribuir solicitações de maneira equilibrada, equalizando a pressão de carga de cada servidor no cluster;

wKiom1jsz__Q7RpoAAJQnYSWdA8640.png-wh_50

2. O que é Nginx

1. Introdução ao Nginx

O Nginx é um servidor web leve, servidor de proxy reverso e servidor de proxy de e-mail. Conhecido por sua estabilidade, rico conjunto de recursos, arquivos de configuração simples e baixo consumo de recursos do sistema. O Nginx (pronunciado "engine x") foi desenvolvido pelo programador russo Igor Sysoev. Originalmente, era usado pelo grande portal e mecanismo de busca russo Rambler (russo: Рамблер). Este software é lançado sob uma licença do tipo BSD e pode ser executado em UNIX, GNU/Linux, BSD, Mac OS X, Solaris e Microsoft Windows.

Status de aplicação do Nginx

O Nginx já está em execução no Rambler Media (www.rambler.ru), o maior portal da Rússia, e mais de 20% das plataformas de hospedagem virtual na Rússia usam o Nginx como servidor de proxy reverso.

Na China, muitos sites como Taobao, Sina Blog, Sina Podcast, Netease News, Liujianfang, 56.com, Discuz!, Shuimu Community, Douban, YUPOO, Domestic, Xunlei Online etc. já utilizam o Nginx como servidor web ou servidor de proxy reverso.

2. Os principais recursos do Nginx

(1) Multiplataforma: O Nginx pode ser compilado e executado na maioria dos sistemas operacionais, e também existe uma versão para Windows;

(2) Configuração muito simples: é muito fácil começar a usar.

(3) Não bloqueante, alta concorrência de conexões: O teste oficial suporta 50.000 conexões simultâneas e, no ambiente de produção real, opera com 20.000 a 30.000 conexões simultâneas. (Isso se deve ao fato de o Nginx utilizar o modelo epoll mais recente);

Nota:

Para um servidor web, observe primeiro o processo básico de uma solicitação: estabelecer conexão - receber dados - enviar dados. Do ponto de vista do sistema: o processo acima (estabelecer conexão - receber dados - enviar dados) corresponde a eventos de leitura e escrita no nível do sistema.

Se for usado o método de chamada bloqueante, quando os eventos de leitura e escrita não estiverem prontos, a única opção é aguardar — a thread atual é suspensa e os eventos de leitura e escrita só podem ser executados quando estiverem prontos.

Se for usado um método de chamada não bloqueante: o evento retorna imediatamente, informando que ainda não está pronto e que é preciso voltar mais tarde. Depois de um tempo, verifica-se o evento novamente até que esteja pronto. Nesse intervalo, é possível realizar outras tarefas e depois voltar para verificar se o evento está disponível. Embora não haja bloqueio, é necessário verificar o status do evento periodicamente. É possível fazer mais coisas, mas a sobrecarga não é pequena. Uma chamada não bloqueante significa que a chamada não bloqueará a thread atual, mesmo que o resultado não esteja imediatamente disponível.

(4) Orientado a eventos: O mecanismo de comunicação adota o modelo epoll para suportar um maior número de conexões simultâneas.

O método não bloqueante determina se deve realizar operações de leitura e escrita verificando constantemente o status dos eventos, o que gera muita sobrecarga. Por isso, existe um mecanismo assíncrono de processamento de eventos não bloqueantes. Esse mecanismo permite monitorar vários eventos ao mesmo tempo. As chamadas são não bloqueantes, mas é possível definir um tempo limite. Dentro desse tempo limite, se um evento estiver pronto, ele será retornado. Esse mecanismo resolve os dois problemas mencionados acima das chamadas bloqueantes e não bloqueantes.

Tomando o modelo epoll como exemplo: quando o evento não está pronto, ele é colocado na fila epoll. Se um evento estiver pronto, ele é processado; quando o evento não está pronto, aguarda-se no epoll. Dessa forma, é possível processar um grande número de solicitações simultâneas. Naturalmente, as solicitações simultâneas aqui referem-se a solicitações não processadas. Como há apenas uma thread, obviamente apenas uma solicitação pode ser processada por vez. Trata-se de uma alternância constante entre solicitações. A alternância ocorre porque o evento assíncrono ainda não está pronto, sendo cedida ativamente. Não há custo nessa alternância — pode-se entender como um loop percorrendo vários eventos preparados.

Comparado ao método multithread, esse método de processamento de eventos apresenta grandes vantagens. Não é necessário criar threads, e cada solicitação ocupa muito pouca memória. Não há troca de contexto. O processamento de eventos é muito leve, e mesmo com um grande número de conexões simultâneas, não há desperdício desnecessário de recursos (troca de contexto). No servidor Apache, cada solicitação tem uma thread de trabalho exclusiva e, quando o número de conexões simultâneas chega a vários milhares, haverá milhares de threads processando solicitações ao mesmo tempo. Isso representa um grande desafio para o sistema operacional: o uso de memória causado pelas threads é muito alto, a sobrecarga de CPU causada pela troca de contexto das threads é muito grande e o desempenho naturalmente não melhora, resultando em uma queda significativa de desempenho em cenários de alta concorrência.

Resumo: Por meio do mecanismo assíncrono de processamento de eventos não bloqueantes, o Nginx implementa o processamento cíclico de múltiplos eventos preparados pelo processo, alcançando assim alta concorrência e leveza.

(5) Estrutura Master/Worker: um processo mestre gera um ou mais processos trabalhadores.

Nota: O padrão de projeto Master-Worker inclui principalmente dois componentes: Master e Worker. O Master mantém a fila de Workers e envia solicitações a vários Workers para execução paralela. O Worker executa principalmente os cálculos lógicos reais e retorna os resultados ao Master.

Quais são os benefícios de o Nginx adotar esse modelo de processos? O uso de processos independentes evita que eles se afetem mutuamente. Se um processo for encerrado, os demais continuam funcionando e o serviço não é interrompido. O processo Master reiniciará rapidamente o novo processo Worker. Naturalmente, o encerramento anormal do processo Worker deve ser causado por um bug no programa. O encerramento anormal causará falha em todas as solicitações no Worker atual, mas não afetará todas as solicitações, reduzindo assim o risco.

(6) Baixo consumo de memória: O consumo de memória ao processar um grande número de solicitações simultâneas é muito baixo. Com 30.000 conexões simultâneas, apenas 150 MB de memória são consumidos por 10 processos Nginx (15 MB × 10 = 150 MB).

(7) Função de verificação de integridade integrada: Se um servidor web no back-end do proxy Nginx ficar indisponível, isso não afetará o acesso front-end.

(8) Economia de largura de banda: A compressão GZIP é suportada, e o cabeçalho Header armazenado em cache localmente pelo navegador pode ser adicionado.

(9) Alta estabilidade: Quando usado como proxy reverso, a probabilidade de indisponibilidade é mínima.

3. Nginx + Apache para construir balanceamento de carga de clusters de servidores web

Configurar proxy reverso no Nginx

Configure o Nginx como proxy reverso e balanceador de carga, utilize sua função de cache para armazenar páginas estáticas no Nginx, reduza o número de conexões com servidores de back-end e verifique a integridade do servidor web de back-end.



wKiom1js0B-iFnITAACVfFt6894317.png-wh_50

1. Instalar o Nginx

Ambiente:

SO: CentOS 7.2

Nginx: 192.168.31.83

Apache1: 192.168.31.141

Apache2: 192.168.31.250

Instale dependências como zlib-devel e pcre-devel

[root@www ~]# yum -y install gcc gcc-c++ make libtool zlib zlib-devel pcre pcre-devel openssl openssl-devel

Nota:

Combinação dos módulos proxy e upstream para alcançar balanceamento de carga de servidores web de back-end

Cache de arquivos estáticos usando o módulo proxy

Combinado com os módulos padrão do Nginx ngx_http_proxy_module e ngx_http_upstream_module

Para implementar a verificação de integridade do servidor de back-end, também é possível usar o módulo de terceiros nginx_upstream_check_module

Use o módulo de extensão nginx-sticky-module para implementar afinidade de sessão por cookie (manter sessão)

Use o ngx_cache_purge para obter uma função mais poderosa de limpeza de cache

Os dois módulos mencionados acima pertencem a módulos de extensão de terceiros. É necessário baixar o código-fonte antecipadamente e instalá-los juntos com --add-module=caminho_fonte durante a compilação.



Instalar o Nginx

[root@www ~]# groupadd www #Adicionar grupo www

[root@www ~]# useradd -g www www -s /sbin/nologin #Criar conta de execução do Nginx www e adicioná-la ao grupo www, sem permitir que o usuário www faça login direto no sistema

#tar zxf nginx-1.10.2.tar.gz

#tar zxf ngx_cache_purge-2.3.tar.gz

#tar zxf master.tar.gz

# cd nginx-1.10.2/

[root@www nginx-1.10.2]# ./configure --prefix=/usr/local/nginx1.10 --user=www --group=www --with-http_stub_status_module --with-http_realip_module --with- http_ssl_module --with-http_gzip_static_module --http-client-body-temp-path=/var/tmp/nginx/client --http-proxy-temp-path=/var/tmp/nginx/proxy --http-fastcgi- temp-path=/var/tmp/nginx/fcgi --with-pcre --add-module=../ngx_cache_purge-2.3 --with-http_flv_module --add-module=../nginx-goodies-nginx-sticky -module-ng-08a395c66e42

[root@www nginx-1.10.2]# make && make install

Nota: Todos os módulos do Nginx devem ser adicionados no momento da compilação e não podem ser carregados dinamicamente em tempo de execução.

4. Outros esquemas de agendamento para balanceamento de carga:

A seguir, uma introdução a outros algoritmos de agendamento suportados pelo módulo de balanceamento de carga do Nginx:

Polling (padrão): Cada solicitação é alocada para diferentes servidores de back-end sequencialmente, em ordem cronológica. Se um servidor de back-end ficar indisponível, o sistema defeituoso será automaticamente eliminado, de modo que o acesso do usuário não será afetado. Weight especifica o peso do polling. Quanto maior o valor de Weight, maior a probabilidade de acesso alocada. É usado principalmente quando o desempenho de cada servidor no back-end é desigual.

ip_hash: Cada solicitação é alocada de acordo com o resultado do hash do IP de acesso, de modo que visitantes do mesmo IP possam acessar um único servidor de back-end, o que resolve efetivamente o problema de compartilhamento de sessão em páginas web dinâmicas. Naturalmente, se esse nó estiver indisponível, a solicitação será enviada ao próximo nó e, se não houver sincronização de sessão nesse momento, o usuário será desconectado.

least_conn: A solicitação é enviada ao servidor real com o menor número de conexões ativas no momento. O valor de weight será considerado.

url_hash: Este método aloca solicitações de acordo com o resultado do hash da URL de acesso, de modo que cada URL seja direcionada ao mesmo servidor de back-end, o que pode melhorar ainda mais a eficiência do servidor de cache de back-end. O Nginx nativamente não suporta url_hash. Se for necessário usar esse algoritmo de agendamento, é preciso instalar o pacote de hash do Nginx nginx_upstream_hash.

fair: Este é um algoritmo de balanceamento de carga mais inteligente do que os dois anteriores. Esse algoritmo pode realizar balanceamento de carga de forma inteligente com base no tamanho da página e no tempo de carregamento, ou seja, aloca solicitações de acordo com o tempo de resposta do servidor de back-end, priorizando aqueles com menor tempo de resposta. O Nginx nativamente não suporta fair. Se for necessário usar esse algoritmo de agendamento, é preciso baixar o módulo upstream_fair do Nginx.

5. Balanceamento de carga e verificação de integridade:

Estritamente falando, o Nginx não possui verificação de integridade nativa para nós de back-end de balanceamento de carga, mas isso pode ser realizado pelas instruções relevantes nos módulos padrão ngx_http_proxy_module e ngx_http_upstream_module. Quando o nó de back-end falhar, ele alternará automaticamente para o próximo nó para fornecer acesso.

weight: O peso do polling também pode ser usado em ip_hash; o valor padrão é 1

max_fails: O número de vezes permitido para falhas de solicitação; o padrão é 1. Quando o número máximo de vezes for excedido, um erro definido pelo módulo proxy_next_upstream será retornado.

fail_timeout: Tem dois significados — um é permitir até 2 falhas dentro de 10 s; o outro é não alocar solicitações para este servidor dentro de 10 s após 2 falhas.

6. Uso do cache de proxy do Nginx:

O cache consiste em armazenar arquivos estáticos como JS, CSS, imagens etc. do servidor de back-end no diretório de cache especificado pelo Nginx, o que não apenas reduz a carga no servidor de back-end, mas também acelera a velocidade de acesso. No entanto, limpar o cache em tempo hábil torna-se um problema, portanto o módulo ngx_cache_purge é necessário para limpar manualmente o cache antes do tempo de expiração.

As diretivas mais usadas no módulo proxy são proxy_pass e proxy_cache.

A função de cache web do Nginx é realizada principalmente pelo conjunto de instruções proxy_cache, fastcgi_cache e conjuntos de instruções relacionados. A instrução proxy_cache é responsável pelo cache de proxy reverso de conteúdo estático do servidor de back-end, e fastcgi_cache é usado principalmente para lidar com cache de processos dinâmicos FastCGI