使用 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) SIGSYS13) SIGPIPE 14) SIGALRM 15) SIGTERM 16) SIGURG17) SIGSTOP 18) SIGTSTP 19) SIGCONT 20) SIGCHLD21) SIGTTIN 22) SIGTTOU 23) SIGIO 24) SIGXCPU25) SIGXFSZ 26) SIGVTALRM 27) SIGPROF 28) SIGWINCH29) 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:9420COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAMEnode 70826 myunlessor 13u IPv6 0xd250033eef8912eb 0t0 TCP *:9420 (LISTEN)
事實上，我們也可以在代碼里通過 console.log(process.pid) 獲取進程 ID。這里只是順便介紹一種，在知道監聽 TCP 端口的情況獲取進程的方式。
隨后，我們發起一個請求，在收到響應之前（有 5 秒等待時間），我們給應用發送 SIGINT 信號。
$ curl http://localhost:9420 &$ kill -INT 70826curl: (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:9420COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAMEnode 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:9420curl: (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 進程管理很好的選擇。
以上就是本文的全部內容，希望對大家的學習有所幫助，也希望大家多多支持VeVb武林網。
新聞熱點
疑難解答
