如何在 Node.js 中实现零停机重新部署

Question

为我的 Node.js 应用程序实现零停机时间的最简单方法是什么？

我有一个需要重新部署的应用程序：

• npm install
• node_modules/.bin/bower install
• node_modules/.bin/gulp

这些操作的结果是在名为build 的gulpfile.js 目录中生成了可以运行的应用程序。在这个目录中，我有一个当前正在运行的同一应用程序实例（当前通过 forever 启动，就像这样 -- forever start server.js）。

据我所知，通过forever模块实现零停机是不可能的，所以我决定选择另一种方式。

我看到了pm2，但我发现它非常复杂（如果你不这么认为，请证明我错了）。

我也看到了naught，但我什至无法通过naught start server.js 启动我的应用程序——它甚至不会在标准输出/标准错误中打印任何内容。

我也看到了up-time，但我不明白——当我运行gulp 时，它将如何处理应该替换当前正在运行的实例所在目录中的文件的情况？

Answer 1

关于在构建期间处理替换文件：如果这些文件被 Node.js 应用程序使用，那么所有更改都将在进程重新启动时应用（因为这些文件已加载到内存中），浏览器前端文件也可以缓存在应用程序内存中实现类似的行为（仅在重新启动或/和缓存失效时应用更改）。

我们在集群模式下使用 pm2。

pm2 start app.js -i

上述命令在所有可用 CPU 内核上以集群模式启动 app.js。

零停机重启：

pm2 gracefulReload all

此命令按顺序重新启动所有进程，因此如果您有多个进程启动并运行，则服务器在重新启动期间始终至少有一个进程请求。 如果您只有一个app.js 进程，您可以在集群模式下启动它并运行pm2 scale app.js 2（再启动一个进程）然后运行pm2 gracefulReload all，然后再运行pm2 scale app.js 1（删除之前启动的进程）。

虽然我认为应用重启不是零停机部署的主要问题，但我们还没有设法处理数据库迁移，因此需要完全关闭应用才能应用数据库更改。此外，在部署期间用户获取新版本的浏览器前端文件时，也可能存在问题，但 AJAX 请求是由旧版本的服务器进程处理的，在这种情况下，粘性会话和 API 版本控制就派上用场了。