Почему использование PM2 для управления процессами устарело
До использования eggjs приложения в производственной среде в основном управлялись pm2, и вроде проблем не было.Почему не рекомендуется egg-script?
В официальном документе причина объясняется в FAQ (Часто задаваемые вопросы — создано для корпоративных платформ и приложений) копировать:
- Сам модуль PM2 очень сложен, и устранить неполадки в нем сложно. Мы считаем, что сложность инструментов, используемых фреймворком, не должна быть слишком высокой, а сложность самого PM2 превышает сложность большинства приложений.
- Нет возможности сделать очень глубокую оптимизацию.
- Для проблем с реальным спросом один процесс запускает лидера, а другие процессы проксируют лидера в этом режиме (многопроцессная модель), при разработке на уровне предприятия существует практическая потребность в сокращении удаленных подключений и уменьшении нагрузки на передачу данных. Особенно, когда масштаб приложения достаточно велик, это будет просто необходимо. Яйцо само возникло от Ant Financial и Ali, Отправной точкой нашего теста является создание крупномасштабных корпоративных приложений, поэтому он должен быть очень всеобъемлющим. Эти свойства PM2 сложно сделать
issueтакже упоминается
Node.js по своей сути не может сделать действительно идеальный горячий перезапуск. Так называемый горячий перезапуск в настоящее время состоит из:
* Restart Worker: невозможно контролировать поток, и нет гарантии, что обрабатываемый запрос не будет прерван.
* Удалить require.cahe: Это приведет к утечке памяти и не может быть использовано.
Хотя официальная документация по-прежнему описывает, как использовать PM2, стандартным способом перезапуска веб-приложения должно быть удаление его с внешнего загрузочного компьютера (кластера).полная перезагрузкаЗатем повторно получить запрос на обработку. Крупномасштабный проект со сложными зависимостями, скорее всего, будет иметь проблемы с управлением процессами, подобными PM2. Сам по себе eggjs также предоставляет достаточно стабильный egg-скрипт менеджера процессов. Но в egg-script нет функции перезагрузки, как это реализовать?
Как это сделать без использования PM2?
Небольшие компании или небольшие личные проекты в основном не используют кластерное развертывание, но использование Nginx для проксирования приложений eggjs и настройка восходящего потока на одной машине также обеспечивает балансировку нагрузки, и именно этот метод развертывания делает возможным горячее развертывание на одной машине. Nginx поддерживает настройку плавной перезагрузки, так что вотДинамическое изменение восходящего списка с помощью egg-script для завершения или перезапуска приложения и перезагрузки nginx., который не имеет побочных эффектов, но не должен называться по существуГорячий перезапуск.
Действуйте следующим образом:
- Конфигурация nginx определяет более двух портов как работающих
upstream nginxconf {
server localhost:8001;
server localhost:8002;
}
server {
listen 443;
ssl on;
ssl_certificate *.fullchain.cer;
ssl_certificate_key *.key
server_name vux.li;
location / {
proxy_pass http://nginxconf;
add_header x-upstream $upstream_addr;
}
}
- Циклический список портов, выполните следующие действия:
- отnginx upstreamудалено в
- reload nginx, в это время движение отключено
- Подождите 5 секунд (например), обработайте возможную незавершенную логику (используйте очередь или задачу по времени, чтобы избежать использования setTimeout setInterval)
- использоватьegg-script stopОстановить текущий экземпляр порта
- Используйте запуск egg-script для перезапуска текущего экземпляра порта и ожидания готовности (egg-script ожидает до 300 с)
- Вернуться к списку восходящих потоков nginx
- reload nginx
Заголовок x-upsteam, добавленный в приведенную выше конфигурацию nginx, предназначен для удобства наблюдения за тем, какой восходящий поток является текущим.
как пользоваться
Напишите приведенную выше логику в виде модуля, и она у вас будетegg-deploy,На данный момент реализованы только нужды моего собственного небольшого проекта.Если у вас есть подобные нужды,то можете обратиться к нему.Также милости просим на пр.
Используйте его бездумно:
## 安装
yarn add egg-deploy --dev
Добавьте nginx.conf в каталог, не забудьте включить в глобальную конфигурацию nginx.
Конфигурация в package.json:
{
"scripts": {
"deploy": "egg-deploy"
}
}
yarn deploy
Расширенная конфигурация
Добавить в каталог проекта.deploy.yml
instances:
-
port: 8001
title: 8001 # 自定义标题,避免与同机上其他 eggjs 重名
-
port: 8002
title: 8002
startCommand: service nginx start # nginx 启动命令,运行时若 nginx 未运行会尝试执行
reloadCommand: nginx -s reload # nginx reload 命令
nginxConfig: nginx.conf # nginx 配置地址,可以是绝对地址,如果放置于项目下,记得在 nginx 全局配置里 include
waitStopTime: 5000 # 停止前的等待时间
Автоматическое развертывание
В сочетании с хуком-уведомлением системы ci, таким как circle ci, можно реализовать автоматическое развертывание, и это делается путем выполнения git pull + npm run deploy.
Код
В настоящее время только грубая реализация.
GitHub.com/Love too lazy/Spoof…
разное
Его расширение может фактически заменить PM2 в качестве относительно распространенного решения для автономного развертывания приложений Node.js.
Способ динамического редактирования конфигурации nginx прост и груб, но может быть не очень элегантен, и другие способы в отрасли здесь обсуждаться не будут.
Редактор Zhihu слишком сложен в использовании.