当前位置:主页 > nodejs教程 >

Node.js进程平滑离场剖析小结

发布:2022-06-15 08:21:55 108


本站收集了一篇Node.js相关的编程文章,网友徐洛凝根据主题投稿了本篇教程内容,涉及到Node.js、进程平滑离场相关内容,已被833网友关注,涉猎到的知识点内容可以在下方电子书获得。

使用 Node.js 搭建 HTTP Server 已是司空见惯的事。在生产环境中,Node 进程平滑重启直接关系到服务的可靠性,它的重要性不容我们忽视。既然是平滑重启,就涉及到新旧进程的接替过渡:

  • 首先,保证新进程平滑入场
  • 其次,保证旧进程平滑离场

本文主要谈论下,在新旧进程接替过渡期间,如何保证旧进程平滑离场。那怎样的离场才算平滑的呢?

如何定义平滑离场

以进程离场作为时间分割点,我们可以把请求分为两类:增量请求存量请求

  • 在进程离场前,停止接收新的(增量)请求
  • 在进程离场前,保证未完成的(存量)请求正常响应

所以,达成以上两个目标,基本上我们就认为进程的离场是平滑的。在谈如何做到进程平滑离场前,我们需要一种机制,这种机制能让我们主动通知进程何时离场,这就涉及到进程间通信(IPC)的知识了,我们先简单了解下。

进程间通信

对 Unix 或类 Unix 系统而言,进程间通信的方式有很多种 —— 信号(Signal)是其中的一种。

信号的种类有很多,如 SIGINT、 SIGTERM SIGKILL 等。这些信号视具体需要用于不同的场景,比如 SIGKILL 一般用于强杀进程。

我们可以在命令行执行 kill -l 查看所有的信号,如下所示(其中的数字表示 signal number):

$ kill -l
 1) SIGHUP   2) SIGINT   3) SIGQUIT   4) SIGILL
 5) SIGTRAP   6) SIGABRT   7) SIGEMT   8) SIGFPE
 9) SIGKILL  10) SIGBUS  11) SIGSEGV  12) SIGSYS
13) SIGPIPE  14) SIGALRM  15) SIGTERM  16) SIGURG
17) SIGSTOP  18) SIGTSTP  19) SIGCONT  20) SIGCHLD
21) SIGTTIN  22) SIGTTOU  23) SIGIO  24) SIGXCPU
25) SIGXFSZ  26) SIGVTALRM  27) SIGPROF  28) SIGWINCH
29) SIGINFO  30) SIGUSR1  31) SIGUSR2

我们可以使用 kill 命令向进程发送指定信号:

# 发送 SIGTERM 信号(默认,无须指定信号类型)给进程
$ kill <pid>

# 发送 SIGINT 信号给进程,其中 <pid> 为具体的进程 ID
$ kill -INT <pid>

# 发送 SIGKILL 信号给进程
$ kill -KILL <pid>

# 或者
$ kill -9 <pid>

进程可以对接收到的信号作出回应。对 Node 应用而言,信号是被当作事件发送给 Node 进程的,进程接收到 SIGTERM 及 SIGINT 事件有默认回调,官方文档是这么描述的:

'SIGTERM' and 'SIGINT' have default handlers on non-Windows platforms that reset the terminal mode before exiting with code 128 + signal number. If one of these signals has a listener installed, its default behavior will be removed (Node.js will no longer exit).

这句话写的很抽象,它是什么意思呢?我们以一个简单的 Node 应用为例。

新建文件,键入如下代码,将其保存为 server.js:

const http = require('http');

const server = http.createServer((req, res) => {
 setTimeout(() => {
  res.writeHead(200, { 'Content-Type': 'text/plain' });
  res.end('It works');
 }, 5000);
});

server.listen(9420);

这里为了方便测试,对应用接收到的每个 http 请求,等待 5 秒后再进行响应。
执行 node server.js 启动应用。为了给应用发送信号,我们需要获取应用的进程 ID,我们可以使用 lsof 命令查看:

$ lsof -i TCP:9420
COMMAND  PID    USER  FD  TYPE       DEVICE SIZE/OFF NODE NAME
node  70826 myunlessor  13u IPv6 0xd250033eef8912eb   0t0 TCP *:9420 (LISTEN)

事实上,我们也可以在代码里通过 console.log(process.pid) 获取进程 ID。这里只是顺便介绍一种,在知道监听 TCP 端口的情况获取进程的方式。

随后,我们发起一个请求,在收到响应之前(有 5 秒等待时间),我们给应用发送 SIGINT 信号。

$ curl http://localhost:9420 &

$ kill -INT 70826
curl: (52) Empty reply from server
[1]+ Exit 52         curl http://localhost:9420

可以看到,请求没能正常收到响应。也就是说,默认情况下,Node 应用在接收到 SIGINT 信号时,会马上把进程杀死,无视进程还没处理完成的请求。所幸的是,我们可以手动监听进程的 SIGINT 事件,像这样:

process.on('SIGINT', () => {
 // do something here
});

如果我们在事件回调里什么都不做,就意味着忽略该信号,进程该干嘛干嘛,像什么事情都没发生一样。

那么,如果我手动监听 SIGKILL 会如何呢?对不起,SIGKILL 是不能被监听的,官方文档如是说:

'SIGKILL' cannot have a listener installed, it will unconditionally terminate Node.js on all platforms.

这是合情合理的,要知道 SIGKILL 是用于强杀进程的,你无法干预它的行为。

回到上面的问题,我们可以近似地理解为 Node 应用响应 SIGINT 事件的默认回调是这样子的:

process.on('SIGINT', () => {
 process.exit(128 + 2/* signal number */);
});

我们可以打印 exit code 来验证:

$ node server.js

$ echo $?
130

有了信号,我们就能主动通知进程何时离场了,下面谈一谈进程如何平滑离场。

如何让进程平滑离场

我们在上面示例基础上,也就是在文件 server.js 中,补充如下代码:

process.on('SIGINT', () => {
 server.close(err => {
  process.exit(err ? 1 : 0);
 });
});

这段代码很简单,我们改写应用接收到 SIGINT 事件的默认行为,不再简单粗暴直接杀死进程,而是在 server.close 方法回调中再调用 process.exit 方法,接着继续试验一下。

$ lsof -i TCP:9420
COMMAND  PID    USER  FD  TYPE       DEVICE SIZE/OFF NODE NAME
node  75842 myunlessor  13u IPv6 0xd250033ec7c9362b   0t0 TCP *:9420 (LISTEN)

$ curl http://localhost:9420 &
[1] 75878

$ kill -2 75842

$ It works
[1]+ Done          curl http://localhost:9420

可以看到,应用在退出前(即进程离场前),成功地响应了存量请求。

我们还可以验证,进程离场前,确实不再接收增量请求:

$ curl http://127.0.0.1:9420
curl: (7) Failed to connect to 127.0.0.1 port 9420: Connection refused

这正是 server.close 所做的事,进程平滑离场就是这么简单,官方文档是这么描述这个 API 的:

Stops the server from accepting new connections and keeps existing connections. This function is asynchronous, the server is finally closed when all connections are ended and the server emits a 'close' event. The optional callback will be called once the 'close' event occurs. Unlike that event, it will be called with an Error as its only argument if the server was not open when it was closed.

结束语

进程平滑离场只是 Node 进程平滑重启的一部分。生产环境中,新旧进程的接替涉及进程负载均衡、进程生命周期管理等方方面面的考虑。专业的工具做专业的事,PM2 就是 Node 进程管理很好的选择。

以上就是本文的全部内容,希望对大家的学习有所帮助,也希望大家多多支持码农之家。


相关文章

  • node.js进程管理器Forever安装使用方法

    发布:2020-01-13

    这篇文章主要介绍了node.js应用后台守护进程管理器Forever安装和使用实例,forever可以看做是一个nodejs的守护进程,能够启动,停止,重启我们的app应用,需要的朋友可以参考下


  • Node.js中关于服务器端应用开发框架Hapi.js的用法实例

    发布:2020-06-14

    Hapi.js 是一个用来构建基于 Node.js 的应用和服务的富框架,使得开发者把重点放在便携可重用的应用逻辑而不是构建架构。内建输入验证、缓存、认证和其他 Web 应用开发常用的功能。


  • 关于Node.js编码规范

    发布:2020-03-05

    编码规范比比皆是,但是很少有公司做好编码规范的。忍不住想谈谈编码规范的重要性,希望所有人都能够重视起来。


  • node.js中mysql数据库配置及连接知识点分享

    发布:2020-02-04

    本文主要介绍了node.js平台下的mysql数据库配置及连接的相关知识。具有很好的参考价值,下面跟着小编一起来看下吧


  • node.js中Socket.IO的技巧分享

    发布:2020-02-03

    这篇文章主要介绍了node.js中Socket.IO的进阶使用技巧,本文讲解了配置、房间、事件、授权等内容,需要的朋友可以参考下


  • Node.js特点分析

    发布:2020-01-21

    本文主要对Node.js的特点进行详细介绍。具有很好的参考价值,下面跟着小编一起来看下吧


  • 详细介绍node.js中的url.format方法

    发布:2020-02-01

    这篇文章主要介绍了node.js中的url.format方法使用说明,本文介绍了url.format的方法说明、语法、接收参数、使用实例和实现源码,需要的朋友可以参考下


  • Node.js服务器作为api服务器的解决方案

    发布:2019-11-27

    本篇文章主要介绍了详解本地Node.js服务器作为api服务器的解决办法,具有一定的参考价值,感兴趣的小伙伴们可以参考一下。


  • 关于Node.js查找当前目录下文件夹

    发布:2020-03-16

    本篇文章主要介绍了Node.js查找当前目录下文件夹实例代码,具有一定的参考价值,有兴趣的可以了解一下。


  • Chrome DevTools直接调试Node.js和JavaScript的实例方法

    发布:2019-09-14

    现在我们可以用浏览器调试node.js了!!!下面这篇文章主要介绍了利用Chrome DevTools直接调试Node.js和JavaScript的方法步骤,文中介绍的很详细,需要的朋友可以参考学习,下面来一起看看吧。


网友讨论