Melhores Práticas de Processos

Limites de processos e workers protegem a segurança e a estabilidade - crie processos com segurança, dimensione pools honestamente e desligue graciosamente sob sinais do orquestrador.

Como Usar Esta Lista

• Obrigatório para qualquer código que use child_process ou shell: true.
• Revise ao habilitar o módulo cluster ou o modo cluster do PM2.
• Conte as conexões totais de DB como tamanho do pool × workers × pods.
• Emparelhe com os runbooks de Desligamento Gracioso.

A - Segurança do child_process

• Prefira spawn/execFile com arrays de argumentos em vez de exec com shell. Elimina injeção em entradas influenciadas pelo usuário.
• Nunca use shell: true com strings de usuário interpoladas. Bloqueador de revisão de código.
• Defina maxBuffer conscientemente em execFile ou evite APIs bufferizadas para saída grande. Use streaming com spawn em vez disso.
• Reaproveite processos filhos - sempre aguarde exit ou trate error. Evite processos zumbis e vazamentos de FD.
• Execute filhos como usuário do SO com privilégio mínimo em produção. Não como root, a menos que absolutamente necessário.

B - worker_threads e CPU

• Use pools de workers fixos, não criação de Worker por requisição. Limite ao número de núcleos da CPU, a menos que perfilado de outra forma.
• Mantenha I/O na thread principal; transformações de CPU em workers. DB e HTTP permanecem no isolado primário.
• Transfira ArrayBuffer ao postar binários grandes para evitar custo de clonagem. Use a lista de transferência em postMessage.
• Trate worker.on('error') e reinicie workers do pool em caso de falha. Evite que o pool encolha para zero silenciosamente.
• Não assuma que add-ons nativos são thread-safe. Consulte a documentação do add-on antes de usar workers.

C - cluster e Escalabilidade

• Evite escalar workers do cluster duas vezes dentro de muitas réplicas do K8s. Escolha o orquestrador ou o cluster, raramente ambos em escala total.
• Use armazenamento externo (Redis) para sessões e limites de taxa com múltiplos workers. Sem suposições de memória.
• Registre process.pid em logs estruturados. Depure qual worker tratou uma requisição.
• Refork workers com backoff em loops de crash. Evite thrash de CPU em má configuração.
• Dimensionar pools de conexão: poolMax × workers × réplicas. Permaneça abaixo das conexões máximas do banco de dados.

D - Sinais e Ciclo de Vida

• Trate SIGTERM e SIGINT com uma função de desligamento idempotente. O Kubernetes usa SIGTERM.
• Chame server.close() e aguarde pool.end() do DB antes de sair. Feche também os workers do BullMQ.
• Defina um timer de saída forçada abaixo do período de graça da plataforma. Geralmente 25s em um grace period de 30s do K8s.
• Falhe na sonda de prontidão quando o esvaziamento começar. Pare o novo tráfego antes do trabalho de desligamento.
• Trate unhandledRejection como fatal em APIs de produção. Política separada do SIGTERM gracioso.

E - Escolhas de Arquitetura

• Opte por I/O assíncrono in-process para APIs CRUD. Processos/workers são uma escalada, não o padrão.
• Use filas para trabalho em segundo plano durável, não fork por e-mail. BullMQ em vez de child_process cego.
• Documente ADR ao escolher cluster em bare metal vs. escalabilidade apenas em pods. Alinhamento da equipe no modelo de operações.
• Isole código não confiável em sandbox/contêiner do SO, não apenas em worker_thread. Workers compartilham privilégios de processo.
• Teste o desligamento em testes de integração de CI pelo menos uma vez por ciclo de lançamento. Capture hang em keep-alive.

FAQs

Relacionados

• child_process - spawn vs exec
• Sinais de Processo e Desligamento - padrões SIGTERM
• worker_threads - pools de CPU
• Desligamento Gracioso - operações

Versões da Stack: Esta página foi escrita para Node.js 24.18.0 (Active LTS), npm 10+, TypeScript 5.6+, Express 5, Fastify 5, e NestJS 11.