Повышаем отказоустойчивость системы на nodejs

Пожалуйста, тестируйте все.

Меньше мутабельности) Вместо Array.prototype.push.apply(arr1, arr2) лучше [...a, ...b]

Обратите внимание на то, как и где нужно выставлять LimitNOFILE, чтобы изменения не затирались после очередного апдейта.

habrahabr.ru/post/268583/#comment_8608261

Мы это делаем путем внесения правок в конфиг и релоада nginx до и после перезагрузки инстанса.

а почему не через pm2 graceful reload? кстати говоря, у них есть ещё keymetrics.io, из которой можно делать ручной graceful reload и прочие полезные штуки

Несколько сумбурно написано и структурированности не хватает. По пунктам:

Теперь перед этими 4-ма инстанами нужно установить балансировщик, который будет распределять нагрузку

Тут, есть множество вариантов, например: Запустить еще один инстанс ноды и задействовать модуль cluster

Cluster-модуль содержит балансировку по воркерам внутри себя, ничего дополнительно ставить не нужно. А вот для статики — действительно, неплохо иметь nginx сверху. Но это опять же ничуть не исключает наличия кластер-модуля в апстриме.

Периодичность перезагрузки (в зависимости от разных причин) от 1 раза в час до 1 раза в сутки.

Я могу понять когда сервис жрет память и не отдает (от чего кстати хорошо помогают лимиты по использованию памяти в pm2), но от чего сервис может становиться более медленным с течением времени — непонятно. Так или иначе, выше уже упомянули про graceful reload. И да, перезагружать весь инстанс довольно странно, если есть кластер-модуль и можно, грубо говоря, послать SIGTERM медленному воркеру.

написано множество cli утилит, которые следят за процессом ноды и в случае необходимости его перегружают

Не могу сказать за остальные три, но могу сказать за pm2 — падает как миленький весь God Daemon :) Особенно на node/io от 0.11 до 4.1.2, из-за бага, имевшего место быть в тех версиях в модуле кластера. Так что за pm2 тоже желательно следить, через upstart-скрипт, например. А можно вообще впилить голый кластер-модуль и мониторить/перезагружать его опять же через upstart.

По пункту 10 — чот вообще вcё в кучу смешалось. Да, мониторинг нужен. Да, юнит-тестирование нужно. Но из пункта сложилось впечатление, что вы предлагаете использовать mocha/jasmine на продакшене для проверки окружения о.0 Это довольно странный способ использования этих фреймворков.

Спасибо за полезную информацию.

Молодцы!

Уходите от REST-а, вы его переросли. Переходите на AMQP (а именно RabbitMQ с роутингом). Это даст вам асинхронность и все преимущества event-based loose-coupling системы. В том числе такие приятные вещи, как параллелизация нагруженных узлов, кворумные воутеры, возможность рестарта любого сервиса без потерь, dry-run новых версий сервисов, debug «на ходу» и т.д.

А во вторых — очень любопытно, как вы решаете вопросы совместимости API при внесении breaking changes? Когда у вас десятки сервисов, предполагаю, вам нужно или передепловать всю кучу на новую версию API или поддерживать две версии одновременно. Как именно вы поступаете?

Нода под нагрузкой требует увеличения ограничения nofile limit

Зачем он вам? Вы же не отдаете статику через ноду?

Инстанс под нагрузкой, который работает продолжительное время начинает «тормозить»

Можете примерно сказать нагрузку? У нас тоже есть такое, но начинают тормозить инстансы с говнокодом. За нормальными такого замечено не было.

9. Не бойтесь использовать ECMAScript 2015 (ES6)

Извините, но пример совершенно не впечатляет, т.к. можно использовать

arr1 = arr1.concat(arr2);

без всяких ES6

По поводу шестого пункта.
Может кто-нибудь посоветовать пример проекта с грамотно построенной микросервисной архитектурой?

По поводу утечек памяти и перезагрузок. В конечном счёте обычно выясняется, что виноват код, либо ваш, либо npm. У нас игра на nodejs, очень интенсивная, сетевое взаимодействие через websocket с клиентами. Были «детские» проблемы, которые тоже время от времени забивали память и приходилось перезагружать инстанс, но под пристальным анализом они все были выявлены и исправлены, и да, все они были в коде приложения, хотя далеко не все были так очевидны, т.е. на первый взгляд казалось, что всё в коде хорошо. Но анализ дампов heap и примерных ситуаций, в которых они возникали, помог их выявить. Сейчас инстансы работают спокойно столько, сколько нужно. Неделю недавно работали, т.к. долго не апдейтили код.
У меня ещё есть сайт написанный на node.js, там тоже всё отлажено, писал давно его и долго мучился сначала, но после того, как все проблемы устранил — работает без перезагрузок вообще, поскольку код там не обновляется, аптайм там месяцами измеряется. Ну и все относительно популярные модули npm довольно серьёзно относятся к проблемам утечек памяти, в целом с ними там ситуация хорошая, их либо нет, либо их быстро исправляют.

Это ж какой у вас QPS к каждому процессу ноды, что нужно 131070? Или это просто «с потолка», и реально хватило бы 5000-8000? Замеряли реальное потребление fd?