Как вы относитесь к короткоживущим процессам в NodeJS?

Question

[Юрий Пузыня]

Собственно, есть ли у кого-нибудь позитивный опыт использования подобной архитектуры?
Если есть негативный, то тоже интересно послушать. В каких ситуациях была попытка внедрить подобное и почему отказались.

Answer 1

[Александр Прозоров]

Создавать новый процесс для обработки пользовательского запроса, по-сути является шагом назад к протоколу CGI. Это будет медленно и накладно по ресурсам. Собственно поэтому и появился протокол FastCGI, чтобы сократить время отклика за счёт постоянно живущего процесса.

Безотносительно архитектуры приложения, ответить на ваш вопрос сложно. С одной стороны Node рассчитан на долгую жизнь процесса, по крайней мере головного. С другой стороны, реализация web-worker, запуск побочных процессов через spawn и даже в некоторых случаях воркеры в кластере (cluster) вполне могут быть короткоживущими для выполнения разовых задач.

В общем надо плясать от вашей задачи. Очень интересно, что именно заставило вас думать в эту сторону.

Comments

[Юрий Пузыня]

В данном случае идет миграция со старого API, которое и было реализовано подобным образом (JSX). От перехода на NodeJS со старой архитектурой уже будет профит, но я естественно понимаю, что использовать ноду подобным образом - это все равно что не превышать скорость на мотоцикле. Для меня предпочтительнее будет использовать неоднородный кластер с основным процессом в качестве балансера. Плюс переработка архитектуры с расчетом на скорое появление воркеров. Одна из основных проблем при подобной архитектуре - обработка ошибок - недопустимо имень непредсказуемую смерть у зависимых процессов в кластере, но думаю что промисы с легкостью решат эту проблему.
Благодарю за ваше мнение.

Answer 2

[Тимур Шемсединов]

Расскажу, какая ситуация с этим у меня в Impress и что меня в этом устраивает и не устраивает.

Сейчас процессы для обработки запросов порождаются при старте, и повторно порождаются при падении. Утечки памяти или падения процессов - считаю ненормальным поведением, но в реальности не все используемые библиотеки пушу я и даже не весь код приложений пишу я, поэтому нужно как-то с утечками и падениями бороться. Конечно падения минимизированны, т.к. весь прикладной код выполняется в sandbox`ах, и при утечках можно просто создать новый sandbox в том же процессе, восстановить в нем все нужные структуры данных, потом заменить ссылку со старого (утекшего или испорченного при исключении sandbox`а) на новый и убить старый. Это быстрее, чем порождать новый процесс.

Но иногда хочется ответвить обработку одного запроса в отдельный процесс, чтобы он не мешал другим. Сейчас у меня реализовано прозрачное для приложений порождение нового процесса для этих случаев, т.е. сделано нечто подобное воркерам. Но процессы запускаются относительно медленно. Кроме того, есть еще планировщик заданий, который должен выполнять часть бизнес-логики по расписанию.

Как я хочу сделать. Кроме процессов обработки запросов иметь еще некоторый пул подготовленных запущенных процессов, которые уже и соединение к БД установили и развернули все что нужно в памяти. С родительским процессом они связаны TCP-сокетом, через который налажен RPC (полноценный вызов удаленных процедур с поддержкой колбэков, событий, асинхронного вызова нескольких запросов и т.д.) И когда возникает необходимость ответвить обработку или выполнить задание по расписанию, то вместо порождения процесса будет браться первый свободный процесс из пула и ему по RPC приходит заказ. Когда он все выполнил, то он по RPC возвращает колбэк или событие.

Вот все у меня уже вроде готово для этого и сам RPC написан и отлажен, скоро реализую. А дальше по тому же RPC (но с транспортом через вебсокеты) собираюсь связать и клиентские приложения, чтобы они становились единым целым с серверными процессами и воркерами.

Comments

[Юрий Пузыня]

Тимур, я ждал Вас в этом таске =) Утечка памяти это к сожалению далеко не главное чего я опасаюсь в долгоживущих подпроцессах. Меня скорее волнует потеря локальной очереди RPC запросов внутри "воркера" (назовем его так). Не ответить на один запрос - не страшно, страшно не ответить еще на 10 только потому, что рядом с ними исполнился неугодный код. Как Вы поступаете в этой ситуации? Перепосылаете запросы в новый инстанс? Не создаете очередь внутри воркера? Или пытаетесь сделать воркер непадающим?

[Тимур Шемсединов]

Сейчас я отказался от использования встроенного IPC (child_process.send) и ZMQ для вызовов между процессами и трансляции событий, перешел на свой RPC на базе TCP, что в 3-5 раз подняло интенсивность обмена между процессами. Но я еще не использую это для ответвления обработки HTTP запросов в стиле воркеров. Пока что по RPC я гоняю синхронизацию структур данных в памяти (некоторые объекты хочется синхронизировать, чтобы все части приложения имели доступ к одинаковому состоянию, можно выбрать, что именно синхронизируется и с какой точностью по времени). Что же касается ответвления обработчиков, я хочу сделать пул процессов, и если процесс получил задание, то другое задание в него не пихать, это именно для того, чтобы в этих воркерах код мог, например, быть синхронным или опасным, чтобы когда он не будет отдавать время в eventloop, то ни кому от этого хуже не будет или если он все похерит и упадет, то ничего не потеряется. Можно держать на готове десятка два таких процессов, и как только они получают задания, то порождать новые, чтобы кол-во готовых не снизилось до нуля. Но нужно и общее кол-во ограничить, чтобы они не наплодились, да еще и по RPC нужно следить, что они живые, т.е. отвечают на heartbeat, например, каждую минуту должны присылать событие, иначе их нужно убивать из мастера.

Но сейчас у меня еще не так, и как раз приходится в одном процессе иметь параллельно несколько конкурирующих запросов. Более того, эти запросы могут относиться к разным приложениям (разным доменам, вообще к разным проектам и даже заказчикам). Если утечек памяти удается избежать благодаря sandbox`ам, то есть еще исключения, которые ловлю и через domain и через try/catch, а недоловленные и через process.on('uncaughtException', function(err) {...}); В принципе этого хватает, чтобы процессы жили неделями и месяцами железобетонно. Не удается таким образом защититься только от того, что какой-то прикладной код начинает крутить долгую логику, не отдавая управление в eventloop, это действительно подвешивает конкурентные запросы. Какой выход из этого вижу: нужно самому заниматься диспетчеризацией запросов, т.е. отказаться от передачи сокетов из мастера в воркеры через библиотеку cluster и ловить все запросы в главном процессе, а передавать их в дочерние на обработку уже по своему RPC или обернуть IPC. Ну и можно будет добавить таймаут и перепосылать запрос в другой процесс, если за таймаут он не обработан. Так в мастере вообще не будет прикладного кода, только системный, который и проще и лучше отлажен, в общем, не должен падать, а если воркеры падают и виснут, то задача перенаправляется в другой воркер.

Это существенно снизит производительность, ведь сейчас в мастерах не происходит вообще ни какая обработка HTTP, он просто передает сокеты воркерам, и вся нагрузка распыляется на много ядер. Можно сделать трехслойную систему: мастер->системныеВоркеры->прикладныеВоркеры. Тогда нагрузку по обработке HTTP мы распределим на системные воркеры, которые надежные и не падают, а они уже передают запросы дальше в прикладные воркеры, которые менее надежны.

Но в общем, все эти танцы меня не радуют, я считаю, что нужно писать код хорошо, без утечек и с хорошей обработкой исключений. Если это не так, то ни что не спасет, нельзя сделать идеальной защиты от дурака. Дурак всегда изобретательнее нас. Вот, к примеру, упал процесс, потому, что в нем обработка запроса пошла "не так", а почему собственно мы должны надеяться, что в другом процессе тот же самый запрос исполнится успешно? Почему вдруг все должно пойти "так как нужно", если предыдущий раз упало, утекло или сломалось? Я думаю, что если уж начались падения, то нужно блокировать запросы определенного типа, которые к ним приводят и звать разработчика, который может их починить. Решать проблему говнокода увеличением мощности серверов это глубоко отвратительная практика.

Кроме всего, у меня еще все рассчитано на несколько серверов, т.е. на каждом есть свой мастер и воркеры, но один из серверов выделен ведущим. А для распределения нагрузки между серверами в клиентское приложение встроен программный балансировщик, он получает массив IP адресов и выбирает из него рандомно один, с которым работает по API, если что-то не так, то переключается на другой рандомный IP из массива. В конце концов, это интернет, даже сеть не работает с 100% гарантией, так что, наворачивать сложную архитектуру на сервере с несколькими слоями воркеров я не у себя не хочу, лучше клиент будет ждать ответа от сервера и не получив его, перепошлет запрос на другой IP.