Mejores Prácticas para Procesos

Los límites de procesos y workers protegen la seguridad y la estabilidad: inicia de forma segura, dimensiona los pools honestamente y apaga con gracia bajo las señales del orquestador.

Cómo Usar Esta Lista

• Obligatorio para cualquier código que use child_process o shell: true.
• Revisa al habilitar el módulo cluster o el modo cluster de PM2.
• Cuenta el total de conexiones a la base de datos como tamaño del pool × workers × pods.
• Combina con los runbooks de Apagado Elegante.

A - Seguridad de child_process

• Prefiere spawn/execFile con arrays de argumentos sobre exec con shell. Elimina la inyección en entradas influenciadas por el usuario.
• Nunca uses shell: true con cadenas de usuario interpoladas. Bloqueador de revisión de código.
• Establece maxBuffer conscientemente en execFile o evita las APIs con búfer para grandes salidas. Transmite con spawn en su lugar.
• Cosecha los procesos hijos: siempre espera exit o maneja error. Evita zombies y fugas de descriptores de archivo.
• Ejecuta los hijos como usuario del sistema operativo con menos privilegios en producción. No como root a menos que sea absolutamente necesario.

B - worker_threads y CPU

• Usa pools de workers fijos, no la creación de Workers por solicitud. Limita al número de núcleos de CPU a menos que se perfile lo contrario.
• Mantén la E/S en el hilo principal; las transformaciones de CPU en workers. La base de datos y HTTP permanecen en el aislamiento primario.
• Transfiere ArrayBuffers al publicar binarios grandes para evitar el costo de clonación. Usa la lista de transferencia en postMessage.
• Maneja worker.on('error') y reinicia los workers del pool en caso de fallo. Evita que el pool se reduzca a cero silenciosamente.
• No asumas que los complementos nativos son seguros para hilos. Consulta la documentación del complemento antes de usar workers.

C - cluster y Escalado

• Evita el doble escalado de workers de cluster dentro de muchas réplicas de K8s. Elige orquestador o cluster, rara vez ambos a gran escala.
• Usa un almacenamiento externo (Redis) para sesiones y límites de tasa con múltiples workers. Sin suposiciones en memoria.
• Registra process.pid en logs estructurados. Depura qué worker manejó una solicitud.
• Re-forkea workers con retroceso en bucles de fallos. Evita el thrash de CPU por mala configuración.
• Dimensiona los pools de conexión: poolMax × workers × replicas. Mantente por debajo del máximo de conexiones de la base de datos.

D - Señales y Ciclo de Vida

• Maneja SIGTERM y SIGINT con una función de apagado idempotente. Kubernetes usa SIGTERM.
• Llama a server.close() y espera pool.end() de la base de datos antes de salir. Cierra también los workers de BullMQ.
• Establece un temporizador de salida forzada por debajo del período de gracia de la plataforma. Típicamente 25s en un período de gracia de 30s de K8s.
• Falla la sonda de preparación cuando comienza el drenaje. Detén el tráfico nuevo antes del trabajo de apagado.
• Trata unhandledRejection como fatal en las APIs de producción. Separa la política del SIGTERM elegante.

E - Opciones de Arquitectura

• Por defecto, usa E/S asíncrona en proceso para APIs CRUD. Los procesos/workers son una escalada, no el valor predeterminado.
• Usa colas para trabajos en segundo plano duraderos, no un fork por correo electrónico. BullMQ sobre child_process ciego.
• Documenta ADR al elegir cluster en hardware dedicado versus escalado solo con pods. Alineación del equipo en el modelo de operaciones.
• Aísla el código no confiable en un sandbox/contenedor del sistema operativo, no solo en worker_thread. Los workers comparten privilegios de proceso.
• Prueba el apagado en pruebas de integración de CI al menos una vez por tren de lanzamiento. Atrapa el cuelgue en keep-alive.

Preguntas Frecuentes

Relacionado

• child_process - spawn vs exec
• Señales de Proceso y Apagado - patrones de SIGTERM
• worker_threads - pools de CPU
• Apagado Elegante - operaciones

Versiones de la pila: Esta página fue escrita para Node.js 24.18.0 (LTS Activo), npm 10+, TypeScript 5.6+, Express 5, Fastify 5 y NestJS 11.