Node.js 進(jìn)程平滑離場(chǎng)剖析

xbynet 發(fā)布于2019-08-23 14:56 / 1514人閱讀

摘要：在談如何做到進(jìn)程平滑離場(chǎng)前，我們需要一種機(jī)制，這種機(jī)制能讓我們主動(dòng)通知進(jìn)程何時(shí)離場(chǎng)，這就涉及到進(jìn)程間通信的知識(shí)了，我們先簡(jiǎn)單了解下。進(jìn)程間通信對(duì)或類系統(tǒng)而言，進(jìn)程間通信的方式有很多種信號(hào)是其中的一種。

本文由云+社區(qū)發(fā)表作者：草小灰

使用 Node.js 搭建 HTTP Server 已是司空見(jiàn)慣的事。在生產(chǎn)環(huán)境中，Node 進(jìn)程平滑重啟直接關(guān)系到服務(wù)的可靠性，它的重要性不容我們忽視。既然是平滑重啟，就涉及到新舊進(jìn)程的接替過(guò)渡：

首先，保證新進(jìn)程平滑入場(chǎng)

其次，保證舊進(jìn)程平滑離場(chǎng)

本文主要談?wù)撓拢谛屡f進(jìn)程接替過(guò)渡期間，如何保證舊進(jìn)程平滑離場(chǎng)。那怎樣的離場(chǎng)才算平滑的呢？

如何定義平滑離場(chǎng)

以進(jìn)程離場(chǎng)作為時(shí)間分割點(diǎn)，我們可以把請(qǐng)求分為兩類：增量請(qǐng)求和存量請(qǐng)求。

在進(jìn)程離場(chǎng)前，停止接收新的（增量）請(qǐng)求

在進(jìn)程離場(chǎng)前，保證未完成的（存量）請(qǐng)求正常響應(yīng)

所以，達(dá)成以上兩個(gè)目標(biāo)，基本上我們就認(rèn)為進(jìn)程的離場(chǎng)是平滑的。在談如何做到進(jìn)程平滑離場(chǎng)前，我們需要一種機(jī)制，這種機(jī)制能讓我們主動(dòng)通知進(jìn)程何時(shí)離場(chǎng)，這就涉及到進(jìn)程間通信（IPC）的知識(shí)了，我們先簡(jiǎn)單了解下。

進(jìn)程間通信

對(duì) Unix 或類 Unix 系統(tǒng)而言，進(jìn)程間通信的方式有很多種 —— 信號(hào)（Signal）是其中的一種。

信號(hào)的種類有很多，如 SIGINT、 SIGTERM 及 SIGKILL 等。這些信號(hào)視具體需要用于不同的場(chǎng)景，比如 SIGKILL 一般用于強(qiáng)殺進(jìn)程。

我們可以在命令行執(zhí)行 kill -l 查看所有的信號(hào)，如下所示（其中的數(shù)字表示 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 命令向進(jìn)程發(fā)送指定信號(hào)：

# 發(fā)送 SIGTERM 信號(hào)（默認(rèn)，無(wú)須指定信號(hào)類型）給進(jìn)程
$ kill 

# 發(fā)送 SIGINT 信號(hào)給進(jìn)程，其中  為具體的進(jìn)程 ID
$ kill -INT 

# 發(fā)送 SIGKILL 信號(hào)給進(jìn)程
$ kill -KILL 

# 或者
$ kill -9

進(jìn)程可以對(duì)接收到的信號(hào)作出回應(yīng)。對(duì) Node 應(yīng)用而言，信號(hào)是被當(dāng)作事件發(fā)送給 Node 進(jìn)程的，進(jìn)程接收到 SIGTERM 及 SIGINT 事件有默認(rèn)回調(diào)，官方文檔是這么描述的：

"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).

這句話寫的很抽象，它是什么意思呢？我們以一個(gè)簡(jiǎn)單的 Node 應(yīng)用為例。

新建文件，鍵入如下代碼，將其保存為 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);

這里為了方便測(cè)試，對(duì)應(yīng)用接收到的每個(gè) http 請(qǐng)求，等待 5 秒后再進(jìn)行響應(yīng)。

執(zhí)行 node server.js 啟動(dòng)應(yīng)用。為了給應(yīng)用發(fā)送信號(hào)，我們需要獲取應(yīng)用的進(jìn)程 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)

事實(shí)上，我們也可以在代碼里通過(guò) console.log(process.pid) 獲取進(jìn)程 ID。這里只是順便介紹一種，在知道監(jiān)聽(tīng) TCP 端口的情況獲取進(jìn)程的方式。

隨后，我們發(fā)起一個(gè)請(qǐng)求，在收到響應(yīng)之前（有 5 秒等待時(shí)間），我們給應(yīng)用發(fā)送 SIGINT 信號(hào)。

$ curl http://localhost:9420 &

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

可以看到，請(qǐng)求沒(méi)能正常收到響應(yīng)。也就是說(shuō)，默認(rèn)情況下，Node 應(yīng)用在接收到 SIGINT 信號(hào)時(shí)，會(huì)馬上把進(jìn)程殺死，無(wú)視進(jìn)程還沒(méi)處理完成的請(qǐng)求。所幸的是，我們可以手動(dòng)監(jiān)聽(tīng)進(jìn)程的 SIGINT 事件，像這樣：

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

如果我們?cè)谑录卣{(diào)里什么都不做，就意味著忽略該信號(hào)，進(jìn)程該干嘛干嘛，像什么事情都沒(méi)發(fā)生一樣。

那么，如果我手動(dòng)監(jiān)聽(tīng) SIGKILL 會(huì)如何呢？對(duì)不起，SIGKILL 是不能被監(jiān)聽(tīng)的，官方文檔如是說(shuō)：

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

這是合情合理的，要知道 SIGKILL 是用于強(qiáng)殺進(jìn)程的，你無(wú)法干預(yù)它的行為。

回到上面的問(wèn)題，我們可以近似地理解為 Node 應(yīng)用響應(yīng) SIGINT 事件的默認(rèn)回調(diào)是這樣子的：

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

我們可以打印 exit code 來(lái)驗(yàn)證:

$ node server.js

$ echo $?
130

有了信號(hào)，我們就能主動(dòng)通知進(jìn)程何時(shí)離場(chǎng)了，下面談一談進(jìn)程如何平滑離場(chǎng)。

如何讓進(jìn)程平滑離場(chǎng)

我們?cè)谏厦媸纠A(chǔ)上，也就是在文件 server.js 中，補(bǔ)充如下代碼：

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

這段代碼很簡(jiǎn)單，我們改寫應(yīng)用接收到 SIGINT 事件的默認(rèn)行為，不再簡(jiǎn)單粗暴直接殺死進(jìn)程，而是在 server.close 方法回調(diào)中再調(diào)用 process.exit 方法，接著繼續(xù)試驗(yàn)一下。

$ 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

可以看到，應(yīng)用在退出前（即進(jìn)程離場(chǎng)前），成功地響應(yīng)了存量請(qǐng)求。

我們還可以驗(yàn)證，進(jìn)程離場(chǎng)前，確實(shí)不再接收增量請(qǐng)求：

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

這正是 server.close 所做的事，進(jìn)程平滑離場(chǎng)就是這么簡(jiǎn)單，官方文檔是這么描述這個(gè) 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.

結(jié)束語(yǔ)

進(jìn)程平滑離場(chǎng)只是 Node 進(jìn)程平滑重啟的一部分。生產(chǎn)環(huán)境中，新舊進(jìn)程的接替涉及進(jìn)程負(fù)載均衡、進(jìn)程生命周期管理等方方面面的考慮。專業(yè)的工具做專業(yè)的事，PM2 就是 Node 進(jìn)程管理很好的選擇。

此文已由騰訊云+社區(qū)在各渠道發(fā)布

獲取更多新鮮技術(shù)干貨，可以關(guān)注我們騰訊云技術(shù)社區(qū)-云加社區(qū)官方號(hào)及知乎機(jī)構(gòu)號(hào)