Представьте себе: вы только что создали приложение Node.js, теперь вам нужно обеспечить доступность и надежность своих серверов. Мы начнем с очень простого / нерекомендуемого способа понять, что мы сделали не так с развертыванием нашего приложения Node.js. В этом руководстве мы будем использовать Express.
Экспресс приложение
Очень простое приложение с правильным маршрутом и маршрутом, который работает со сбоями.
.env
1-й уровень:
команда:
node index.js
Первый и наихудший способ запустить приложение - прямое выполнение скрипта с помощью узла. Node.js, по своей сути однопоточный с моделью событий, не масштабируется, как ожидалось, в производственной среде.
Некоторые могут не согласиться с комментарием о том, что узел является однопоточным, и могут иметь аргументы с «рабочими потоками», Node.js, использующим различные внутренние процедуры для чтения и записи, и другими вещами, которые люди делают для обходного пути, который просто добавляет сложности к вашему проект.
Начало работы методом проб и ошибок
Что произойдет, когда мы получим вызов на плохой маршрут с помощью нашего клиента или почтальона, приложение не будет работать, и ваше приложение будет стоять на коленях, и вы потеряете своих ценных клиентов и их доверие.
Чего вы можете ожидать от такого подхода?
Как воспроизвести эту ошибку, сделайте запрос на получение вашего здорового маршрута, вы получите «положительный» ответ от сервера, откроете другую вкладку с плохим маршрутом, и приложение выйдет из строя, пока мы не запустим вручную.
Помимо этого, у вас также будут неожиданные результаты и зависания.
Какое решение?
Имейте в наличии механизм «самовосстановления».
«Восстановление - это тяжело. Сожалеть труднее ». - Бриттани Бургундер
Нам нужен какой-то супервизор / диспетчер процессов поверх нашего приложения, который отслеживает, что наше приложение ведет себя хорошо и «как ожидается».
Вы можете подумать о nodemon, nodemon по своей сути - это просто сценарий разработки, который предоставляет вам горячую перезагрузку, избавляя от хлопот, связанных с перезапуском ваших серверов. У него очень мало механизмов мониторинга, и он не идеальный кандидат для заботы о нашем проекте в производстве.
Лучше всего здесь PM2, Forever или что-то подобное.
Уровень 2:
команда:
npm i -g pm2 pm2 start index.js --name "Server" -i 0
PM2 - безусловно, самый проверенный в боях диспетчер процессов для моих приложений Node.js в масштабе, он помогает вам с вертикальным масштабированием большего количества потоков / блоков ЦП, имеющихся на вашем сервере. Количество потоков / ядер прямо пропорционально количеству блоков кластера, которые вы можете запустить.
Помимо балансировки нагрузки нашего приложения, pm2 предлагает плавное развертывание и экономит много времени. Наряду с этим вы сохраняете и управляете своими журналами. С разделением журналов доступа и журналов ошибок.
Команда для перезагрузки приложения после нового развертывания или изменений:
pm2 reload all
Команда для просмотра журналов приложения для развертывания оперативного исправления как можно скорее:
pm2 logs
Это некоторые команды, которые вы будете использовать в повседневной жизни, когда ваше приложение будет развернуто в производственной среде.
Вы также получаете возможность контролировать свое приложение в производственной среде.
pm2 monit
Это даст вам красивый интерфейс терминала старой школы со всеми деталями, необходимыми для аудита производительности вашего приложения.
Эти функции, которые вы получаете с pm2, согласно их официальной документации:
Теперь мы выполнили часть вертикального масштабирования приложения, и приложение разделит нагрузку, а также корректно завершит работу и перезапустится по желанию.
Теперь, несмотря на все замечательные функции, есть способ, по которому pm2 тоже может выйти из строя.
Пример:
Вы выполнили новое развертывание своего приложения; у вас нет пакета тестирования для вашего конвейера CI / CD, в котором мы все виноваты.
Что произошло при новом развертывании: X установил новую зависимость, вы выполнили перезагрузку, установив ее сначала, или вы установили ее, но ваш package.json каким-то образом пропустил, или фиксация была частично отменена при коллегиальной проверке.
Теперь вы перезагрузили свое приложение.
Теперь первая перезагрузка, и приложение мгновенно вылетает из-за отсутствия зависимости. Сейчас в состоянии паники все это нужно обслужить.
Какие здесь рекомендации:
Всегда имейте в наличии надежный конвейер CI / CD. Для развертываний всегда создавайте управление версиями вашего приложения. Решите развернуть свое новое приложение в одном из новых восходящих блоков, чтобы убедиться, что все в порядке, также выполните развертывание в основном работающем приложении.
Инструмент, который делает это намного проще, хорошо масштабируется с помощью max и имеет активное сообщество, стоящее за NGINX.
Уровень 3:
Что такое NGINX?
Согласно официальным документам NGINX:
NGINX - это программное обеспечение с открытым исходным кодом для веб-обслуживания, обратного проксирования, кэширования, балансировки нагрузки, потоковой передачи мультимедиа и многого другого. Он начинался как веб-сервер, рассчитанный на максимальную производительность и стабильность. Помимо возможностей HTTP-сервера, NGINX также может работать как прокси-сервер для электронной почты (IMAP, POP3 и SMTP), а также как обратный прокси-сервер и балансировщик нагрузки для серверов HTTP, TCP и UDP.
NGINX - это высокопроизводительный сервер, но наш пример его использования - создание обратного прокси-сервера / балансировщика нагрузки.
Как мы будем использовать NGINX?
Мы можем разместить 2 разные версии нашего приложения на 2 разных серверах и создать шлюз API из 2.
Если это звучит сбивающе с толку, давайте рассмотрим пример:
Как мы можем понять, old_server - это тот, который, как ожидается, будет отвечать на большую часть трафика, но параллельно мы также можем использовать new_server.
Фактически есть два, чтобы добавить блок нового сервера вверх по течению также в old_server и разрешить балансировку нагрузки NGINX, мы можем использовать любую комбинацию IP-адресов и портов для распределения нагрузки, мы можем иметь некоторый экземпляр, работающий на том же экземпляре балансировки нагрузки NGINX или мы можем распределить его по экземплярам.
То, что мы сделали здесь, - это версия для наших клиентов, позволяющая использовать новый API, который распространяется среди некоторых клиентов, и на основе их отзывов и опыта стабильности и надежности мы можем принять решение о точной настройке отката или фиксации выпуска для всех клиентов.
С помощью Nginx мы можем достичь горизонтального масштабирования, как в нашем примере, для тех, кого путают с горизонтальным и вертикальным масштабированием: Вертикальное масштабирование - для повышения текущих характеристик машины, горизонтальное масштабирование - для присоединения большего количества экземпляров. в смеси и разделить нагрузку.
NGINX - действительно мощный инструмент, и они доказали, что он надежен не только для API-интерфейсов, но и для обслуживания вашего статического дистрибутива, вашего HTML, CSS и других ресурсов с очень высокой пропускной способностью.
Наряду с этим NGINX делает ваши URL-адреса более удобными, если вы решите поделиться ими со своими клиентами. Удаление порта и уродливой конфигурации также поможет вам избавиться от кошмарного управления CORS.
Существуют и другие альтернативы NGINX, в том числе APACHE, HAPROXY и другие.
Надеюсь, вы хорошо разбираетесь в концепциях проблем и их решениях. Обсуждение решения рассматриваемой проблемы также обеспечивает лучшую ясность решения.
Ключевые выводы:
Рассматривая масштабирование, помните как о вертикальном, так и о горизонтальном его аспектах.
PM2 и NGINX предлагают отличные возможности масштабирования для вашего приложения Node.js.
Ресурсы:
Счастливое кодирование + масштабирование
Оставайтесь с нами, чтобы узнать больше мира !!!
