Добро пожаловать в наш небольшой сборник советов от ведущих разработчиков на платформе Node.JS! Цель сей статьи – обобщить все те знания, которые были в свое время опубликованы в различных обучающих постах или журналах.
Автор статьи – Йони Голдберг, независимый разработчик и консультант Node.JS.
Итак, начнем!
1) Мониторинг
Что это: мониторинг – это такая интересная игра в «найти баг быстрее, чем это сделают твои пользователи». И, помимо прочего, эта игра обладает беспрецедентной важностью. Современный рынок переполнен всеми видами предложений - на любой вкус. Учитывайте: вы должны строго следовать заданной концепции, не переполняя ее различными «доп. фичами». Подберите для себя такое решение, которое удовлетворяет всем требованиям.
В противном случае - провал. Разочарованные клиенты. Все просто.
2) «Умное логгирование» - Ваш друг
Что это: логи, как правило, очень быстро превращаются в свалку утверждений и записей всех видов и типов. Однако при должном подходе, логи являют собой образец чистоты, легко дающие понять всю необходимую информацию, связанную с программой. Планируйте ведение логов с самого начала: как они будут собираться, храниться и анализироваться. Убедитесь, что желаемая информация (такая, как частота возникновения ошибок и прочее) в любой момент может быть легко извлечена.
В противном случае: вы окончите бесконечными копаниями в нечитабельных логах и, в конце концов, потратите уйму времени на «костыли», дабы понять хоть что-то из написанного.
3) Сваливайте все возможные задачи на обратный прокси
Что это: увы, но Node.JS ужасен, когда речь заходит о выполнении ресурсоемких задач на центральном процессоре (такие, как g-zip упаковка, SSL-терминация и прочее). Используйте вместо этого промежуточные middleware-сервисы, такие как nginx, HAproxy или облачные.
В противном случае: Ваша невинная однопоточная операция займет процессор на длительное время. Как следствие, ваше устройство будет уделять больше времени различным промежуточным задачам, нежели непосредственно Node.JS-приложению. Не буду говорить о производительности.
4) Блокируйте зависимости
Что это: код должен быть идентичен для всех сред. Однако, на удивление, можно обнаружить, что NPM творит с зависимостями что-то неимоверное – как только Вы попытаетесь установить пакет в различных средах, программа пытается использовать последнюю версию, характерную для конкретной среды, что, безусловно, вносит свои особенности. Дабы избежать этого, используйте файлы конфигурации. npmrc. Они настраивают NPM таким образом, чтобы тот сохранял текущую версию пакета, не последнюю. Как вариант Вы можете использовать “shrinkwrap”-опцию, так как NPM5 блокирует зависимости по умолчанию.
В противном случае: во время тщательного теста QA пропустят версию, которая в продукции будет вести себя неожиданным для разработчика образом. Даже хуже, разные серверы одновременно в том же кластере будут исполнять разный код.
5) Выбирайте правильные инструменты: экономьте время
Что это: процесс должен выполняться и перезапускаться в случае ошибок. Возможно, в обычной ситуации в качестве рестартера может сгодиться и что-то наподобие PM2, но в современном мире, где правит балом Докер и его приспешники, все подобные инструменты должны быть подобраны особенно тщательно.
В противном случае: использование десятков приложений с сотнями своих инструментов в конце концов приведет к хаосу.
6) Убедитесь, что вы используете только лучшие практики отлавливания багов
Что это: как правило, анализ ошибок – наиболее затратная по времени и устрашающая процедура в поддержании стабильности Node.JS-среды. В основном, причина этому – однопоточная модель приложений и отсутствие выработанной стратегии по отношению к ошибкам в многопоточной среде. Быстрых решений не существует, Вы должны в полной мере осознать и приручить это багнутое чудовище.
7) Используйте все ядра процессора
Что это: в своей стандартной ипостаси приложения Node.JS используют только одно ядро процессора, в то время как остальные в задаче никакого участия не принимают. Ответственность за утилизацию всех ядер лежит только на Вас. К примеру, для небольших и средних приложений Вы можете использовать Node Cluster или PM2. Для более полновесных программ обратите внимание на репликацию процесса при помощи Docker-кластера (такие, как K8S, ECS) или деплоймент-скрипты на базе инициализации Linux (system – как вариант).
В противном случае: Ваше приложение, скорее всего, будет использовать только 25 процентов доступных вычислительных ресурсов (!) или даже меньше. Заметьте, типичный сервер минимум 4-х ядерный, наивный деплой обычного NodeJS использует лишь одно (даже если Вы используете PaaS сервисы наподобие AWS beanstalk)!
8) Разумно планируйте диагностику
Что это: работайте с системной информацией как с количеством используемой памяти или REPL и специальных защищенных API. Хотя полагаться на стандартные инструменты и надежней, некоторую ценную информацию и некоторые операции лучше извлекать и производить напрямую в коде.
В противном случае: в один прекрасный момент Вы обнаружите, что тратите очень много информации на деплой – поставляя код в продукцию просто затем, чтобы получить некоторую информацию для диагностики.
9) Используйте APM-программы
Что это: программы мониторинга вроде APM, чтобы активно оценивать кодовую базу. Посему и их действия могут выходить за рамки действий простых программ мониторинга. К примеру: некоторые APM подсвечивают проблемные транзакции, которые могут вызвать падения производительности на стороне клиента и предполагают причину подобных проблем.
В противном случае: Вы можете провести тонны времени на анализ производительности и поиски проблемных мест. Вероятно, Вы так никогда и не будете уверенными, что именно замедляет работу Вашего приложения больше всего и как приложение будет вести себя в «реальном мире».
10) Завершенный код – завершенный продукт
Что это: «только идеальный код может быть выпущен в продукцию». Запомните это с самого первого дня разработки. Возможно, это и звучит как что-то из репертуара законченного перфекциониста, но, поверьте, результат того стоит.
В противном случае: IT-сообщество вряд ли оценит и сохранит для потомков плохо написанную систему.
Відео курси за схожою тематикою:
11) Обращайте внимание на защиту
Что это: Node.JS включает в себя некоторые уникальные защитные механизмы. Понятно и без слов, что более «защищенная» система требует больше времени на ее анализ.
В противном случае: что может быть хуже, чем брешь в защите, когда продукт уже в производстве? Просто банальная проблема, которую Вы забыли исправить.
12) Отслеживайте и контролируйте память
Что это: Node.JS достаточно неоднозначно работает с памятью: движок v8 обладает ограничением в виде 1.4 ГБ, и были известны случаи, когда код был излишне «памятозатратным». Потому и контроль над использованием памяти – вопрос отнюдь не тривиальный. В небольших приложениях Вы можете настраивать работу с памятью, время от времени используя команды оболочки. Однако в проектах больших масштабов позаботьтесь о выводе состояния памяти в надежную систему мониторинга.
В противном случае: вы обнаружите ежедневную «утечку» памяти в несколько сотен мегабайт, как это произошло с Walmart.
13) Разделяйте клиентскую и серверную часть
Что это: для фронт-енд части используйте такие middleware компоненты, как nginx, S3, CDN и прочие. Выполнение подобных задач на Node.JS-сервере очень плохо сказывается на его производительности. Причина этому: обработка великого множества статических файлов в однопотоковой модели.
В противном случае: Ваш единственный Node.JS-поток будет занят обработкой сотен html/изображений/angular/react-файлов вместо того, чтобы заняться непосредственно обработкой динамического контента. Или, другими словами, того, для чего и была разработана технология Node.JS.
14) Храните данные вне сервера
Что это: сохраняйте любую информацию – будь то пользовательские сессии, кэш, загруженные файлы – на внешнем накопителе. Представляйте, как будто Ваш сервер будет регулярно «падать». Используйте «безсерверную» платформу (например, AWS Lambda).
В противном случае: «падение» конкретного сервера в результате приведет не только к утилизации нерабочей машины, но и к падению производительности самого приложения. Более того, зависимость от конкретного сервера значительно уменьшит гибкость всей системы.
15) Используйте инструменты с автоопределением уязвимостей
Что это: даже такие проверенные временем зависимости, как Express и другие, имеют бреши, которые время от времени могут ставить всю систему под угрозу. Однако подобное можно легко обойти, если использовать различные бесплатные или коммерческие продукты, которые постоянно проверяются на предмет уязвимостей и могут быть мгновенно исправлены в случае необходимости.
В противном случае: держать код в чистоте и без уязвимостей в случае неиспользования соответствующих инструментов затребует постоянного отслеживания новостных сводок и обновлений. Немного напрягает.
16) Присваивайте каждой записи лога свой TransactionId
Что это: присваивайте уникальный идентификатор каждой записи в логе. Подобный подход в значительной мере упростит работу и поиск ошибок. К сожалению, из-за асинхронной природы Node.JS реализовать подобное – задача отнюдь не тривиальная.
В противном случае: Поиск производственных ошибок будет достаточно длительным. Как следствие, Вы закопаетесь в логе ко всем чертям.
17) NODE_ENV = production
Что это: устанавливайте переменной окружения NODE_ENV значение production или development. Это нужно для того, чтобы указать NPM, включить ли оптимизацию или нет – так как многие подобные сервисы обладают опцией автоопределения состояния среды.
В противном случае: игнорирование этого нюанса может сильно замедлить производительность. К примеру, если проигнорировать NODE_ENV, используя Express для серверного рендеринга, производительность упадет в три раза!
18) Развертывайте приложение быстро
Что это: исследователи отмечают, что команды, которые проводят большее количество Node.JS-размещений, имеют меньший риск столкнуться с целым рядом проблем. Быстрые и автоматизированные размещения, не требующие рискованных ручных этапов и сервисов, в значительной мере ускоряют процесс размещения. Возможно, Вам стоит обратить свое внимание на Docker в комбинации с CI-инструментами.
Безкоштовні вебінари за схожою тематикою:
В противном случае: длительное размещение -> падения производительности и человеческие ошибки -> неуверенность команды -> меньшее количество размещений и, как следствие, потенциальных фич.
19) Помещайте NPM-версию в каждое размещение
Что это: с каждым новым релизом указывайте в package.json-версию текущего NPM. Это внесет ясность в работе с приложением. Сей фактор важен, так как, к примеру, в среде MicroService некоторые сервисы могут обращать внимание на версию Вашего NPM. Вы можете использовать команду “npm version”, которая укажет версию автоматически.
В противном случае: достаточно часто разработчики пытаются исправить баг, часто в конце обнаруживая, что они ищут его не в той версии, в которой стоило бы.
20) Следите за актуальной информацией
Традиционное: отслеживайте последние обновления Node.JSб NPM и прочих технологий, с которыми Вы работаете. До новых встреч!
Автор перевода: Евгений Лукашук
Статті за схожою тематикою
