child_process
Тема дорожной карты · Node.js
Модуль child_process позволяет серверному приложению Node.js порождать дочерние процессы операционной системы, что даёт возможность выполнять ресурсоёмкие вычисления, shell-команды и внешние программы за пределами однопоточного цикла событий. Node.js предоставляет четыре основных API: child_process.spawn() для потокового I/O, child_process.exec() для буферизованных shell-команд, child_process.execFile() для запуска исполняемых файлов без оболочки и child_process.fork() для создания дополнительных процессов Node.js со встроенным IPC-каналом. Поскольку Node.js однопоточный, делегирование ресурсоёмких задач — таких как обработка изображений или генерация отчётов — дочерним процессам через child_process.fork() или cluster.fork() предотвращает блокировку цикла событий и сохраняет отзывчивость сервера. Взаимодействие между родительским и дочерним процессами Node.js осуществляется через IPC-механизм с помощью process.send() и process.on('message'). Требования безопасности предписывают валидировать все входные данные перед передачей их в child_process.exec(), чтобы избежать уязвимостей к инъекциям оболочки в приложениях Node.js.
Как это работает
child_process масштабирует Node за одно ядро. Модуль cluster форкает worker-процессы, делящие порт сервера. PM2 оборачивает cluster + добавляет рестарт на crash, управление логами, zero-downtime reload. Контейнеры + оркестратор (Kubernetes, Nomad, Docker Compose с replicas) — современная альтернатива: один процесс на контейнер, масштаб по количеству контейнеров. Перед ними всегда load balancer (nginx, caddy, traefik).
Когда применять
cluster/PM2 — для single-host bare-metal или VM. Контейнеры + оркестратор — для multi-host production: та же модель масштабирования, лучше тулинг. Старый совет "один worker на CPU-ядро" работает; с контейнерами — один Node-процесс на контейнер, оркестратор задаёт количество.
Типичные ошибки
Ловушки child_process: расчёт, что workers делят память (нет — Redis для общего state); неверная sticky session за балансировщиком (WebSocket-клиенты прыгают между workers, теряют state); PM2 внутри контейнеров (двойная оркестрация); нет graceful SIGTERM (in-flight запросы дропаются на rolling restart). Drain соединений на shutdown.