Зевая...Сейчас вас тут научат микросервисам. Ага.
Ваша проблема в том, что приложение изначально ненадежно. Первое, что в таком случае нужно сделать, это запускать несколько копий приложения, если такое позволяет архитектура.
Поскольку у вас будет несколько запущенных копий приложения, вам потребуется
балансировщик, чтобы управлять трафиком. Самый простой и дешевый - это nginx.
Например тупо запустить 2 копии приложения на одной машине, но на разных портах, например 8001 и 8002. А при настройке nginx указать два апстрима, первый с портом 8001, а второй 8002. И настроить отвал по таймауту (fail_timeout). Таймаут зависит от того, насколько быстро работает ваше приложение. У меня он 1 секунда, у вас может быть другое значение.
Для того, чтобы внезапно сдохшее приложение воскрешать, нужно поставить какой-нибудь супервизор, например тот же
forever.
Обычно нода падает из-за катяхов в коде, жора памяти или отвала какой-нибудь фигни. Для того, чтобы за всем этим следить, следует поставить хоть какой-нибудь мониторинг ошибок. Например бесплатный
sentry.
ЗЫ для любителей микросервисов: микросервисы не делают вашу архитектуру более устойчивой. Они делают ее более гибкой за счет замены одной реализации микросервиса другой. Например, у вас есть датацентр А, в котором вы храните файлы, которые сохраняются через микросервис. Внезапно там кишильбе-мишельбе-молния ударила, сервира уронила, файлы потеряло. Мат-перемат. Запиливается на коленке микросервис для датацентра Б, приложение перенастраивается. Полетели. Потом раскапывается из хлама бэкап, пишется скрипт, заливается в новый датацентр. Микросервисы хороши пока они микро. Микро понятие своеобразное, для меня оно означает - могу запилить за день в одиночку. Примеры: хранилка файлов, постановка задач в очередь, укорачивалка ссылок, счетчик переходов и т.п.
Опиум для народа
Простой
Простой
