Lista de Verificação de Produção Ultimate Node.js


Você está fazendo essa coisa do Node diretamente na produção? Vamos ver alguns erros comuns que as pessoas cometem ao executar o Node na produção (passando direto pelos meus próprios projetos – como codedamn) e como isso pode ser mitigado. Você pode considerar isso como sua lista de verificação na produção ao implantar aplicativos Node. Uma vez que este é um Práticas de produção pronta artigo, muitos deles não serão aplicados quando você estiver desenvolvendo aplicativos no sistema local.

Se você gostou deste artigo, vamos nos encontrar nas mídias sociais. Aqui está o meu Instagram e Twitter. Sou super ativo e adoraria conversar! Vamos nos conectar!

Executar nó no modo de cluster / separar processos de nó

Lembre-se de que o Nó é um idioma de thread único. Embora ele possa delegar muitas coisas (como solicitações HTTP e leitura / gravação do sistema de arquivos) para o sistema operacional que lida com ele em um ambiente multithread, ainda assim, o código que você escreve, a lógica do aplicativo sempre é executado em um único encadeamento. Ao executar em um único encadeamento, o processo do Nó é sempre limitado a apenas um núcleo na sua máquina. Portanto, se você tiver um servidor com vários núcleos, estará gastando energia de computação executando o Node apenas uma vez no servidor.

O que significa “executar o Node apenas uma vez”? Veja bem, os sistemas operacionais têm um planejador embutido neles, responsável por como a execução dos processos é distribuída pelas CPUs da máquina. Quando você executa apenas dois processos em uma máquina de dois núcleos, o SO determina que é melhor executar os dois processos em núcleos separados para reduzir o desempenho máximo.

Uma coisa semelhante precisa ser feita com o Node. Você tem duas opções neste momento:

  1. Executar nó no modo de cluster – O modo de cluster é uma arquitetura que é incorporada ao próprio nó. Em palavras simples, o Node cria mais processos próprios e distribui a carga por meio de um único processo mestre.
  2. Executar processos do nó independentemente – Essa opção é um pouco diferente da acima, no sentido de que agora você não possui um processo mestre que controla os processos filhos do Nó. Isso significa que, quando você gerar diferentes processos de Nó, eles serão executados completamente independentes um do outro. Sem memória compartilhada, sem IPC, sem comunicação, nada.

De acordo com um resposta stackoverflow, o último (ponto 2) tem um desempenho muito melhor que o anterior (ponto 1), mas é um pouco mais complicado de configurar. Por quê? Como em um aplicativo de nó, não apenas existe lógica de aplicativo, mas quase sempre quando você está configurando servidores no código do Nó, é necessário ligar as portas. E uma única base de código de aplicativo não pode vincular a mesma porta duas vezes no mesmo sistema operacional. Este problema é, no entanto, facilmente corrigível. Variáveis ​​de ambiente, contêineres de encaixe, proxy de front-end NGiNX etc. são algumas das soluções para isso.

Taxa Limitando seus terminais

Vamos encarar. Nem todo mundo no mundo tem mais interesse pela sua arquitetura. Certamente, ataques como DDoS são simplesmente muito complicados de mitigar, e até gigantes como o GitHub são desativados quando algo assim acontece, mas o mínimo que você poderia fazer é impedir que um script-kiddie derrube seu servidor apenas porque você tem um ponto de extremidade de API caro expostos a partir do seu servidor sem qualquer limite de taxa. Se você usa express com Node, existem 2 pacotes bonitos que funcionam perfeitamente juntos para classificar o tráfego limite na Camada 7:

  1. Limite de taxa expressa – https://www.npmjs.com/package/express-rate-limit
  2. Express Slow Down – https://www.npmjs.com/package/express-slow-down

O Express Slow Down realmente adiciona um atraso incremental às suas solicitações, em vez de descartá-las, para que os usuários legítimos, se DDoS por acidente (super atividade de clicar nos botões aqui e ali), simplesmente diminuam a velocidade e não são limitados pela taxa.

Por outro lado, se houver um script-kiddie executando scripts para derrubar o servidor, o limitador de taxa expressa monitorará e limitará a taxa desse usuário específico, dependendo do IP do usuário, conta do usuário ou qualquer outra coisa que você desejar.

A limitação de taxa também pode (deve!) Ser aplicada na camada 4 (camada 4 significa bloquear o tráfego antes de descobrir o conteúdo dele – HTTP) através do endereço IP. Se desejar, você pode configurar a regra do NGiNX que bloqueia o tráfego na camada 4 e rejeita a inundação de tráfego proveniente de um único IP, economizando assim os processos do servidor.

Use um servidor front-end para terminação SSL

O nó fornece suporte imediato para handshakes SSL com o navegador usando o https módulo servidor combinado com os certificados SSL necessários. Mas sejamos honestos aqui, seu aplicativo não deve se preocupar com SSL em primeiro lugar. Isso não é algo que a lógica do aplicativo deva fazer de qualquer maneira. O código do Nó deve ser responsável apenas pelo que acontece com a solicitação, não pelo pré-processamento e pós-processamento dos dados que entram e saem do seu servidor.

A terminação SSL refere-se à conversão de tráfego de HTTPS para HTTP. E existem ferramentas muito melhores disponíveis que o Node para isso. Eu recomendo NGiNX ou HAProxy para isso. Ambos têm versões gratuitas disponíveis, o que faz o trabalho e descarrega a terminação SSL do Node.

Use um servidor front-end para veiculação de arquivo estático

Novamente, em vez de usar métodos embutidos, como express.static para veicular arquivos estáticos, use servidores proxy reversos de front-end como o NGiNX para veicular arquivos estáticos do disco. Não apenas o NGiNX poderia fazer isso mais rápido que o Node (porque ele foi criado do zero para fazer apenas isso), mas também descarrega a veiculação de arquivos de um processo de Nó de thread único que poderia usar seus ciclos de clock em algo melhor.

Além disso, servidores proxy de front-end como o NGiNX também podem ajudar a fornecer conteúdo mais rapidamente usando a compressão GZIP, definir cabeçalhos de expiração, dados em cache e muito mais, o que não é algo que devemos esperar que o Node faça (no entanto, o Node ainda pode fazê-lo)

Configurar tratamento de erros

O tratamento adequado de erros pode evitar horas de depuração e tentar reproduzir bugs difíceis. No servidor, é especialmente fácil configurar a arquitetura para tratamento de erros, porque você é quem o executa. Eu recomendo ferramentas como Sentinela com Nó que registraria, reportaria e enviaria um e-mail sempre que o servidor travasse devido a um erro no código-fonte.

Uma vez instalado, agora é hora de reiniciar o servidor quando ele falhar, para que o site inteiro não fique parado por horas até que você o recomece manualmente. Para isso, use um gerenciador de processos como PM2 ou melhor ainda, use um ambiente de contêiner encaixado com políticas como restart: always com memória adequada e limites de disco configurados. A configuração do Docker garante que, mesmo que o contêiner seja executado no OME, o processo acelera novamente (o que pode não acontecer em um ambiente PM2, pois o sistema operacional pode matar o PM2 se houver um vazamento de memória em algum lugar do processo em execução)

Configure os logs corretamente

Todas as respostas estão em logs. Hackes de servidor, travamentos de servidor, comportamento suspeito do usuário etc. Para isso, você deve garantir que:

  1. Toda e qualquer tentativa de solicitação é registrada com o endereço IP / método de solicitação / caminho acessado, basicamente o máximo de informações que você pode registrar (exceto informações particulares, como senhas e informações de cartão de crédito, obviamente)
  2. Isso pode ser alcançado através de Morgan pacote
  3. Configuração logs de fluxo de arquivos na produção em vez da saída do console. Isso é mais rápido, fácil de ver e permite exportar logs para serviços de visualização de logs online.
  4. Nem todas as mensagens de log têm peso igual. Alguns logs estão disponíveis apenas para depuração, enquanto que alguns estão presentes, isso pode indicar uma situação de incendio (como uma invasão de servidor ou acesso não autorizado). Use o winston-logger para registrar diferentes níveis de logs.
  5. Configuração rotação de logs para que você não obtenha um tamanho de log em GBs após um mês ou mais, quando vir o servidor.
  6. GZIP seus arquivos de log após a rotação. O texto é barato e é altamente compactável e fácil de armazenar. Você nunca deve enfrentar problemas com logs de texto, desde que compactados e executando um servidor com um espaço em disco decente (25 GB ou mais)

Conclusão

É fácil observar algumas práticas de produção que podem economizar lágrimas e horas de depuração posteriormente. Siga as práticas e deixe-me saber o que você pensa dizendo Olá no meu punho do twitter.

Se você gostou deste artigo, vamos nos encontrar nas mídias sociais. Aqui está o meu Instagram e Twitter. Sou super ativo e adoraria conversar! Vamos nos conectar.

Paz!
Mehul





Fonte

Leave a Reply

Your email address will not be published. Required fields are marked *