O Node.js já está operando com sucesso em escala global, conforme evidenciado pelos aplicativos implantados nele de empresas como Netflix, Reddit, Walmart e Ebay. No entanto, ele tem seu próprio conjunto de problemas ao dimensionar; do ponto de vista do dimensionamento de pessoas que trabalham em uma única base de código; portanto, do ponto de vista do dimensionamento vertical e horizontal na nuvem. Além da minha experiência pessoal com o dimensionamento do Node.js. para empresas como Reddit e Netflix, conversei com alguns especialistas do Microsoft Azure e criei algumas dicas para você sobre o dimensionamento do Node.js. para sua empresa.
Escreva um Node.js de qualidade
Quanto mais cedo você começar a usar linters, formatação e ferramentas de verificação de tipo no seu código, melhor.
Pode ser complicado introduzir essas coisas no meio de um projeto devido à quantidade potencialmente grande de refatoração que pode ser necessária, mas também pode poluir seu histórico de git, mas no final essas ferramentas ajudarão você a tornar o código legível.
Se você ainda não os usa, volte imediatamente os olhos para
ESLint e
Prettier . O ESLint protegerá seu código de padrões incorretos, o Prettier o ajudará a formatar seu código automaticamente antes da solicitação de recebimento.
Uma solução mais substancial é adicionar ferramentas como Flow ou TypeScript à sua base de código. Essas ferramentas permitem capturar erros mais sutis, como chamar uma função com um parâmetro numérico em vez de uma string ou chamar o método
.filter em objetos em vez de uma matriz. Apesar da complexidade e da necessidade de treinar sua equipe, essas ferramentas merecem sua atenção: elas podem acelerar o desenvolvimento com o Intellisense e evitar erros de tempo de execução com proteção de tipo.
Escrever testes
Os testes sempre foram um problema difícil para os desenvolvedores. Alguns acreditam firmemente no desenvolvimento orientado a testes, enquanto outros raramente escrevem testes. Mas existe um meio termo:
- Defina os módulos principais e escreva testes de unidade abrangentes para eles. Preste atenção especial às “jornadas felizes”: casos extremos e cenários em que os erros podem potencialmente ocorrer. Para outros módulos, escreva um ou dois testes de unidade cobrindo “caminhos felizes” e possivelmente casos comuns que você pode ter descoberto
- Teste mínimo de interface do usuário . A interface do usuário está constantemente mudando e geralmente é impraticável gastar muito tempo fazendo testes de código que mudam com frequência.
- Escreva testes para detectar erros . Sempre que você encontrar e corrigir um erro no seu código, escreva um teste de unidade que detectará esse erro no futuro.
- Faça alguns testes de integração para garantir que todas as peças coincidam.
- Faça ainda menos testes de ponta a ponta . Cubra os principais caminhos do seu site, por exemplo, se você estiver criando um site de comércio eletrônico, pode valer a pena fazer um teste para entrar no site, adicioná-lo à cesta e verificar a lista de produtos. Esses testes são caros de manter; portanto, considere manter um pequeno núcleo de testes que você possa motivar a manter.
O ponto de partida para escrever testes é a capacidade de implantar com segurança um novo código. Escreva tantos testes que não haja menos do que você sente, mas tente escrever não mais do que a lista acima.
Design sem estado
A chave ao escrever o Node.js escalável é que seus servidores não precisam armazenar estados para alguém ou algo. Isso impedirá o dimensionamento horizontal. Mova o estado para outro aplicativo e resolva o problema em outro lugar (por exemplo, Redis, Etcd, ...). Você deve pensar sobre isso com antecedência. Será muito difícil desvendar se você não fez isso antes. Também ajudará se você decidir decompor monólitos em microsserviços.
Estatísticas: para desenvolvimento - Node.js, para produção - CDN
Como eu gostaria que as empresas vissem um erro nesse erro. Servir seus ativos estáticos do seu aplicativo Web (em particular, através de algo como webpack-dev-server ou servidor de desenvolvimento Parsel) é uma ótima experiência para desenvolvedores, pois reduz o ciclo de introdução ao escrever código. No entanto, você nunca deve servir suas estatísticas através do Node.js. Ele deve ser enviado separadamente por meio de uma CDN, como uma CDN do Azure.
Os retornos estáticos com o Node.js são desnecessariamente lentos porque as CDNs são mais dispersas e, portanto, fisicamente mais próximas do usuário final, e os servidores da CDN são altamente otimizados para recursos pequenos. Manter estática no Node também é excessivamente caro, pois o tempo do servidor Node.js. é muito mais caro que o tempo do servidor CDN.
Comece a implantar cedo, implante com mais frequência
Eu não te conheço, mas quando desbloqueio algo pela primeira vez, isso nunca funciona. Isso geralmente ocorre porque esqueci de enviar as chaves privadas corretas ou codifiquei o caminho para o host local. Pequenos problemas que trabalham localmente remotamente se recusam a fazer isso. Esses problemas podem se acumular, e o que poderia ser facilmente resolvido antes, se, é claro, cedo para encontrá-los, pode se transformar em um enorme grupo de erros incompreensíveis que simplesmente não podem ser detectados normalmente.
A propósito, o
Visual Studio Code permite que você resolva esse tipo de problema . Ele permite implantar seu aplicativo diretamente no Azure com um clique. Essa é uma maneira bastante simples de verificar se não há problemas para implantar em outro ambiente.
Implante 2 servidores de uma só vez
Esse conselho vem do meu conhecimento conquistado com muito esforço e de um mar de mágoa. A essência do conselho é que existem poucas diferenças entre a implantação de dois servidores e dez servidores, e não há muita diferença entre a implantação de dez servidores e cem servidores. No entanto, existe simplesmente uma enorme diferença entre implantar um servidor e dois servidores.
Semelhante à questão da implantação de servidores sem estado, começando com dois servidores, você pode superar rapidamente seus problemas de escala horizontal para que, quando houver um aumento acentuado no tráfego, você esteja pronto para escalar.
Não tenha medo de linhas
Os bancos de dados modernos lidam com uma certa quantidade de leitura e gravação por conta própria, sem a sua ajuda. Ao testar sua ideia, fique à vontade para confiar no seu banco de dados para lidar com cargas de trabalho pequenas e médias.
O dimensionamento prematuro tem mais chances de matá-lo do que salvá-lo. Mas, em algum momento, seu aplicativo crescerá e você também não poderá gravar tudo no banco de dados, diante de problemas de largura de banda de leitura e gravação. Para alguns aplicativos que possuem um registro leve, ou se você selecionar um banco de dados como o Cassandra, que lida sozinho com uma escala massiva, isso será um problema mais tarde, para outros será mais cedo.
Se você tiver ou terá esse problema em breve, terá opções para escolher as tecnologias com as quais irá adiante. Uma dessas tecnologias pode ser a fila de mensagens. O padrão atual no momento é o Apache Kafka, que permite organizar suas mensagens em tópicos e, em seguida, aplicativos para assinar este tópico. Assim, por exemplo, você pode acumular mensagens no aplicativo, ouvindo um determinado tópico e, em seguida, gravar em lote dados no banco de dados para que não obstruam o tempo todo.
Além disso, o Kafka é executado facilmente no Azure .
Microsserviços para dimensionamento
À medida que seu aplicativo cresce, divisões lógicas naturais começam a aparecer. Uma parte do aplicativo pode processar pagamentos, enquanto a outra parte servirá a API para o seu front-end. Ao fazer divisões lógicas, considere fazê-las separar microsserviços. Mas tenha cuidado, pois a introdução de microsserviços também é repleta de grande complexidade. Mas vale a pena. Assim, por exemplo, cada microsserviço pode ter sua própria métrica. Ao avaliá-los, você pode escalá-los independentemente.
Use recipientes
Seu aplicativo pode funcionar bem localmente, mas pode haver sérios problemas ao tentar implantar. Ferramentas como Docker e Kubernetes funcionarão para você evitar esse problema. Docker, que você pode imaginar como uma mini-instância (contêiner) do Linux ou Windows, na qual você pode executar o aplicativo; e Kubernetes como uma ferramenta que conecta todos os seus contêineres na nuvem.
Kubernetes pode ser um animal complexo, mas um animal que resolve um problema complexo. Se você é um feiticeiro inexperiente do DevOps, pode ter dificuldades, por isso recomendo começar com o
Rascunho . Se você estiver familiarizado com o
Yeoman para projetos Javascript, poderá avaliar o Rascunho como uma ferramenta semelhante, mas para projetos Kubernetes: uma ferramenta que cria uma estrutura de arame para o seu projeto. A partir daí, você pode usar a ferramenta
Helm para instalar partes adicionais da arquitetura que você precisa construir (por exemplo, nginx, mais Node.js, MongoDB, servidores Kafka etc.), quase como o
npm para o Kubernetes.
Assim que você entender o ecossistema Kubernetes, a partir de agora, a implantação na nuvem se tornará um jogo infantil.
Coletar métricas
Se você não souber responder à pergunta "Como meu aplicativo funciona?", Você terá problemas ou eles em breve. Afinal, vários tipos de indicadores ao longo do tempo ajudarão você a melhorar constantemente o estado do seu aplicativo. Do ponto de vista dos custos para o futuro, e do ponto de vista da conveniência do usuário em termos de melhoria do tempo de resposta. Você definitivamente deve acompanhar as métricas, como caminhos lentos, visualizações de página, tempo de sessão e outras métricas importantes que são importantes para os seus negócios.
Existem muitas maneiras de coletar esses indicadores. Serviços como New Relic e AppDynamics fornecerão informações valiosas sobre como melhorar seu aplicativo.
Se você trabalha com o Azure, o Application Insights também atende a essa necessidade e também é fácil conectar outras ferramentas, como CI / CD.
O CI / CD salvará você de tanta dor
Quantas vezes você estragou a implantação durante o FTP e desativou o servidor por vários minutos? Foi comigo. Você nunca deve confiar em si mesmo na implantação do código de produção. Como fazer isso usando o Visual Studio Code é muito legal, mas é principalmente para fins de desenvolvimento ou demonstração. Quando você estiver pronto para criar um sistema em nível de produção, use a integração e a implantação contínuas (geralmente abreviado como CI / CD - integração e implantação contínuas).
A integração contínua é a prática do desenvolvimento de software, que consiste na fusão de cópias de trabalho em um ramo principal comum do desenvolvimento várias vezes ao dia e na realização de montagens automatizadas frequentes do projeto para identificar rapidamente possíveis defeitos e resolver problemas de integração.
A implantação contínua cuida de levar seu código que passou no IC, executando as etapas necessárias para compilar, contêiner ou empacotá-los e enviá-los ao servidor. É uma boa prática ter vários níveis para testar. Você pode primeiro acessar o servidor de desenvolvimento interno para vê-lo em um ambiente de baixo risco. Você pode testá-lo primeiro antes de enviá-lo para um ambiente de controle de qualidade em que seus engenheiros de controle de qualidade ou possivelmente um serviço externo confirmarão que tudo está funcionando conforme o esperado. A partir daí, você pode ir para um ambiente intermediário no qual seu aplicativo ainda é apenas interno, mas funciona usando dados e configurações de produção, para que você possa testá-lo no próprio ambiente de produção antes de enviá-lo diretamente para produção. Você também pode selecionar um pequeno grupo de servidores para verificar o novo código: você e direciona apenas uma pequena porcentagem de tráfego real a esses servidores para garantir que nada ocorra ao trabalhar com usuários reais. Se quebrar, você sabe onde procurar o problema. Caso contrário, você pode passar de um pequeno grupo de usuários para todos.
Muitos fornecedores e projetos de código aberto atendem a essas necessidades. Jenkins, Travis e CircleCI são ótimas opções para o IC. O Azure tem seu próprio serviço de CI / CD chamado Azure Pipelines e é bastante intuitivo de usar e, novamente, se conecta facilmente ao ecossistema integrado do Azure.
Mantenha segredos
Qualquer aplicativo inevitavelmente tem alguns segredos. Pode ser chaves e linhas secretas de credenciais, bancos de dados e muito mais. Seria muito ruim se eles se voltassem para as mãos erradas. No entanto, eles são necessários para executar o aplicativo. Então o que fazemos? Normalmente, no desenvolvimento, usaremos ferramentas como o
dotenv para salvar o arquivo de configuração localmente e poder lê-lo através do process.env no Node.js. Isso é ótimo para desenvolvedores, mas é péssimo para produção.
Em vez disso, é útil usar algum tipo de ferramenta de gerenciamento secreto. Felizmente, o
Kubernetes possui um sistema embutido e é bastante simples de usar. Você fornece segredos do Kubernetes no lado do contêiner e, em seguida, ele os fornece ao seu aplicativo como um ambiente que complica bastante o ataque.
Outra ferramenta digna de sua atenção é o Azure
Key Vault . O que é interessante sobre o Key Vault, mesmo que a Microsoft não possa ler suas chaves (somente você pode descriptografá-las), o Azure acompanhará seus logs e acompanhará quaisquer usos duvidosos de suas chaves para alertá-lo sobre quaisquer compromissos.
Conclusão
O Node.js, como qualquer outra plataforma, precisa ser escalado. E, como qualquer outra plataforma, possui tarefas próprias e a peculiaridade de dimensionamento, que vale a pena conhecer e que devem ser levadas em consideração ao projetar grandes projetos.
Artigo original: “Onze dicas para escalar o Node.js” (
Pt ).
Sugiro nos comentários para compartilhar dicas que você pode dar sobre o dimensionamento do Node.js. Será interessante ouvir.