本文轉(zhuǎn)載自微信公眾號(hào)“code秘密花園”(code_mmhy)。

作為一個(gè)前端工程師，大家日常也會(huì)維護(hù)一些 Node.js 服務(wù)，對(duì)于一個(gè)服務(wù)我們首先要關(guān)注的就是它的穩(wěn)定性，可能大部分同學(xué)對(duì)服務(wù)端的很多概念不會(huì)理解的特別深刻，所以在穩(wěn)定性上面也不知道去關(guān)注什么。

本篇文章我先給大家介紹一些在服務(wù)端穩(wěn)定性上面我會(huì)關(guān)注的一些指標(biāo)。

整體分為兩個(gè)大的方面：

• 資源穩(wěn)定性：即當(dāng)前服務(wù)所處的運(yùn)行環(huán)境的一些指標(biāo)，一般如果資源穩(wěn)定性的指標(biāo)除了問題，那么服務(wù)有可能已經(jīng)有了大問題，甚至處于不可用狀態(tài)。
• 服務(wù)運(yùn)行穩(wěn)定性：服務(wù)運(yùn)行過程中產(chǎn)生的異常、日志、延遲等等。

[[376610]]

一、資源穩(wěn)定性

1. CPU

(1) CPU Load

CPU Load 即 CPU 的負(fù)載，表示在一段時(shí)間內(nèi) CPU 正在處理以及等待 CPU 處理的進(jìn)程數(shù)之和的統(tǒng)計(jì)信息。CPU 完全空閑時(shí)，CPU Load 為0，CPU 工作越飽和，CPU Load越大。

如果 CPU 每分鐘最多處理 100 個(gè)進(jìn)程，系統(tǒng)負(fù)荷0.2，意味著 CPU 在這1分鐘里只處理20個(gè)進(jìn)程。

下面借用下阮一峰的例子：我們把 CPU 想象成一座大橋，橋上只有一根車道，所有車輛都必須從這根車道上通過。系統(tǒng)負(fù)荷為0，意味著大橋上一輛車也沒有。系統(tǒng)負(fù)荷為0.5，意味著大橋一半的路段有車。

系統(tǒng)負(fù)荷為 1.0，意味著大橋的所有路段都有車，也就是說大橋已經(jīng)"滿"了。但是必須注意的是，直到此時(shí)大橋還是能順暢通行的。系統(tǒng)負(fù)荷為 1.7，意味著車輛太多了，大橋已經(jīng)被占滿了(100%)，后面等著上橋的車輛為橋面車輛的70%。

如果容器有 2個(gè)CPU 表明系統(tǒng)負(fù)荷可以達(dá)到2.0，此時(shí)每個(gè)CPU都達(dá)到100%的工作量。推廣開來，n個(gè)CPU的電腦，可接受的系統(tǒng)負(fù)荷最大為n。多核CPU與多CPU效果類似，所以考慮系統(tǒng)負(fù)荷的時(shí)候，必須考慮這臺(tái)電腦有幾個(gè)CPU、每個(gè)CPU有幾個(gè)核心。

(2) CPU Usage

CPU Usage 代表了程序?qū)?CPU 時(shí)間片的占用情況，也就是我們常說的 CPU 利用率，它可以反應(yīng)某個(gè)采樣時(shí)間內(nèi) CPU 的使用情況，是否處于持續(xù)工作狀態(tài)，可以從 CPU 核心、占用率百分比兩個(gè)角度來看。

正常情況下，CPU Usage 高，CPU Load 也會(huì)比較高。CPU Usage 低，CPU Load也會(huì)比較低。也有例外情況：

CPU Load 低，CPU Usage 高：如果 CPU 執(zhí)行的任務(wù)數(shù)很少，則 CPU Load 會(huì)低，但是這些任務(wù)都是CPU密集型，那么利用率就會(huì)高。

CPU Load 高，CPU Usage 低：如果CPU執(zhí)行的任務(wù)數(shù)很多，則 CPU Load 會(huì)高，但是在任務(wù)執(zhí)行過程中 CPU 經(jīng)?？臻e(比如等待IO)，那么利用率就會(huì)低。

2. 內(nèi)存

(1) 內(nèi)存 RSS

RSS ：常駐內(nèi)存集(Resident Set Size)用于表示系統(tǒng)有多少內(nèi)存分配給當(dāng)前進(jìn)程，它能包括所有堆棧和堆內(nèi)存，是 OOM 主要參考的指標(biāo)。

(1) 內(nèi)存 V8 Heap

表示 JavaScript 代碼執(zhí)行占用的內(nèi)存。

一般我們可以看到 V8 Heap 區(qū)分了 Used 和 Total，這里是主要是因?yàn)?V8 的內(nèi)存回機(jī)制，在進(jìn)程中有一些內(nèi)存是可回收并且沒有馬上被回收的，Total - Used 實(shí)際上是指當(dāng)前可以回收但沒有回收的內(nèi)存。

(3) 內(nèi)存 max-old-space-size

V8 允許的最大的老生代內(nèi)存大小，可以簡(jiǎn)單認(rèn)為是一個(gè) Node.js 進(jìn)程長(zhǎng)期可維持的最大內(nèi)存大小。進(jìn)程的 HeapTotal 接近這個(gè)值時(shí)，進(jìn)程很可能會(huì)因?yàn)?V8 abort 而退出。

(4) 內(nèi)存 External

Node.js 中的 Buffer 是基于 V8 Uint8Array 的封裝，因此在 Node.js 中使用 Buffer 時(shí)，其內(nèi)存占用量會(huì)被記錄到 External 中。

加之 external string 在 Node.js 中使用的得很少，因此我們可以認(rèn)為對(duì)一個(gè)常見的 Node.js web 應(yīng)用來說，process.memoryUsage() 中 的 External 主要指的就是Buffer占用的內(nèi)存量。Buffer經(jīng)常被用在 Node.js 中與 IO 相關(guān)的 api 上，如：文件操作、網(wǎng)絡(luò)通信等。

3. Libuv

Libuv 是跨平臺(tái)的、封裝操作系統(tǒng) IO 操作的庫。Node.js 使用 Libuv 作為自己的 event loop，并由 uv 負(fù)責(zé) IO 操作，諸如：net、dgram、fs、tty 等模塊，以及 Timer 等類都可以認(rèn)為是基于 uv 的封裝。因此與 uv 相關(guān)的數(shù)據(jù)指標(biāo)可以一定程度上反應(yīng)出 Node.js 應(yīng)用的穩(wěn)定性。

(1) Libuv Handles

libuv handles 指示了 Node.js 進(jìn)程中各種IO對(duì)象(tcp, udp, fs, timer 等對(duì)象)的數(shù)量。對(duì)于常見的 web 應(yīng)用來說， libuv handles 較高通常意味著當(dāng)前請(qǐng)求量較大或者有 tcp 連接等未被正確釋放。之前在線上業(yè)務(wù)中還會(huì)經(jīng)常發(fā)現(xiàn)有 handle 沒有被關(guān)閉，如：tcp、udp socket 不斷被創(chuàng)建，并且沒有被關(guān)閉，導(dǎo)致操作系統(tǒng)的端口被耗盡的問題出現(xiàn)。

(2) Libuv Latency

libuv latency 并不是 libuv 或 Node.js API 中可以直接獲取到的數(shù)據(jù)。目前主流的、對(duì) libuv latency 的計(jì)算方式，都是通過 setTimeout() 來設(shè)置 timer ，并記錄回調(diào)函數(shù)被調(diào)用時(shí)所消耗的時(shí)間和預(yù)計(jì)消耗的時(shí)間之間的差值作為 latency ，如：

const kInterval = 1000; 
const start = getCurrentTs(); 
setTimeout(() => { 
    const delay = Math.max(getCurrentTs() - start - kInterval, 0); 
}, kInterval); 

latency 數(shù)值較高通常意味著當(dāng)前應(yīng)用的 eventloop 過于繁忙，導(dǎo)致簡(jiǎn)單的操作也不能按時(shí)完成。而對(duì)于 Node.js 進(jìn)程來說，這類情況很可能是由調(diào)用了耗時(shí)較長(zhǎng)的同步函數(shù)或是阻塞的 IO 操作導(dǎo)致。

發(fā)生這類問題時(shí)，對(duì)應(yīng)的線程將沒辦法進(jìn)行正常的服務(wù)，比如對(duì)于 http server 來說，在這段時(shí)間內(nèi)的請(qǐng)求會(huì)得不到響應(yīng)。因此我們需要保證主線程的 libuv latency盡可能的小。

二、服務(wù)運(yùn)行穩(wěn)定性

1. 狀態(tài)碼

這個(gè)應(yīng)該不用多說，對(duì)于服務(wù)產(chǎn)生的所有 5xx 的狀態(tài)碼都屬于服務(wù)器在嘗試處理請(qǐng)求時(shí)發(fā)生內(nèi)部錯(cuò)誤，這些錯(cuò)誤可能是服務(wù)器本身的錯(cuò)誤，而不是請(qǐng)求出錯(cuò)，都是需要我們關(guān)注的：

• 500 (服務(wù)器內(nèi)部錯(cuò)誤) 服務(wù)器遇到錯(cuò)誤，無法完成請(qǐng)求。
• 501 (尚未實(shí)施) 服務(wù)器不具備完成請(qǐng)求的功能。例如，服務(wù)器無法識(shí)別請(qǐng)求方法時(shí)可能會(huì)返回此代碼。
• 502 (錯(cuò)誤網(wǎng)關(guān)) 服務(wù)器作為網(wǎng)關(guān)或代理，從上游服務(wù)器收到無效響應(yīng)。
• 503 (服務(wù)不可用) 服務(wù)器目前無法使用(由于超載或停機(jī)維護(hù))。通常，這只是暫時(shí)狀態(tài)。
• 504 (網(wǎng)關(guān)超時(shí)) 服務(wù)器作為網(wǎng)關(guān)或代理，但是沒有及時(shí)從上游服務(wù)器收到請(qǐng)求。
• 505 (HTTP 版本不受支持) 服務(wù)器不支持請(qǐng)求中所用的 HTTP 協(xié)議版本。
• 506 由《透明內(nèi)容協(xié)商協(xié)議》(RFC 2295)擴(kuò)展，代表服務(wù)器存在內(nèi)部配置錯(cuò)誤：被請(qǐng)求的協(xié)商變?cè)Y源被配置為在透明內(nèi)容協(xié)商中使用自己，因此在一個(gè)協(xié)商處理中不是一個(gè)合適的重點(diǎn)。
• 507 服務(wù)器無法存儲(chǔ)完成請(qǐng)求所必須的內(nèi)容。這個(gè)狀況被認(rèn)為是臨時(shí)的。
• 509 服務(wù)器達(dá)到帶寬限制。這不是一個(gè)官方的狀態(tài)碼，但是仍被廣泛使用。
• 510 獲取資源所需要的策略并沒有沒滿足。

錯(cuò)誤日志服務(wù)運(yùn)行過程中產(chǎn)生的錯(cuò)誤日志數(shù)量也是衡量一個(gè)服務(wù)是否穩(wěn)定的重要指標(biāo)，對(duì)于錯(cuò)誤日志上報(bào)，不同公司的業(yè)務(wù)可能有不同的實(shí)現(xiàn)，但是應(yīng)該大同小異，一般日志都分為 INFO、WARN、ERROR 幾個(gè)級(jí)別，我們需要關(guān)注的是 ERROR 及以上級(jí)別的日志。

一般在我們的業(yè)務(wù)邏輯中，都需要對(duì)服務(wù)運(yùn)行的過程中產(chǎn)生的異常進(jìn)行捕獲以及日志上報(bào)，但是我們不可能在所有程序運(yùn)行的節(jié)點(diǎn)進(jìn)行異常捕獲，另外 try catch 也不是萬能的，它并不能捕獲異步異常，所以我們一般在我們使用的 Node.js 框架中的關(guān)鍵節(jié)點(diǎn)也會(huì)集成日志的上報(bào)，以 KOA 為例，我們需要監(jiān)聽 app 的 error 事件：

this.on('error', (error, ctx) => { 
    if (error.status === 404) { 
        return; 
    } 
    const message = error.stack || error.message; 
    log(message); 
}); 

另外，我們還需要在 uncaughtException、unhandledRejection 中進(jìn)行異常上報(bào)：

process.on('unhandledRejection', (error) => { 
    if (error) { 
        log({ 
            level: 'error', 
            location: '[gulu-core]::UnhandledRejection', 
            message: error.stack || error.message, 
        }); 
    } 
}); 
process.on('uncaughtException', (error) => { 
    log({ 
        level: 'error', 
        location: '[gulu-core]::UncaughtException', 
        message: error.stack || error.message, 
    }); 
    process.exit(1); 
}); 

進(jìn)行了這樣的操作后，所有在你的業(yè)務(wù)邏輯中產(chǎn)生的異常都會(huì)被捕獲并上報(bào)，所以對(duì)于你想了解到的異常你不應(yīng)該手動(dòng)進(jìn)行 try catch，而是將它們拋出到框架進(jìn)行捕獲上報(bào)。

2. pm2 日志

對(duì)于程序中我們自己打印出的一些 console ，一般生產(chǎn)環(huán)境是默認(rèn)不會(huì)被記錄的。例如某些程序異常我們可能自己通過 try catch 進(jìn)行了捕獲，并使用 console 輸出了 ERROR INFO ，這樣的異常并不會(huì)被當(dāng)作錯(cuò)誤日志進(jìn)行捕獲。

一般在線上運(yùn)行的 Node 服務(wù)都是使用 PM2 啟動(dòng)的。PM2 是 node 進(jìn)程管理工具，可以利用它來簡(jiǎn)化很多 node 應(yīng)用管理的繁瑣任務(wù)，如性能監(jiān)控、自動(dòng)重啟、負(fù)載均衡等。

我們可以通過 pm2 log 命令來查看當(dāng)前程序運(yùn)行的實(shí)時(shí)日志，注意這個(gè)日志是包括開發(fā)者自己打出來的一些 console 的。

另外 pm2 也支持查看所有歷史產(chǎn)生的日志，我們可以通過一些 Error 之類的關(guān)鍵字去檢索錯(cuò)誤日志。

3. 延時(shí)

延時(shí)情況也是衡量一個(gè)服務(wù)穩(wěn)定性的重要指標(biāo)，一些非常慢的接口除了會(huì)影響用戶體驗(yàn)，還有可能會(huì)影響數(shù)據(jù)庫的穩(wěn)定性，一般我們?cè)诮涌诘难訒r(shí)和數(shù)據(jù)庫的延時(shí)兩個(gè)方面關(guān)注服務(wù)延時(shí)，這個(gè)比較好理解，這里我就不再多說了。

4. QPS

QPS：全名 Queries Per Second，意思是“每秒查詢率”，是一臺(tái)服務(wù)器每秒能夠響應(yīng)的查詢次數(shù)，是對(duì)一個(gè)特定的查詢服務(wù)器在規(guī)定 Queries Per Second 時(shí)間內(nèi)所處理流量多少的衡量標(biāo)準(zhǔn)。簡(jiǎn)單的說，QPS = req / sec = 請(qǐng)求數(shù)/秒。它代表的是服務(wù)器的機(jī)器的性能最大吞吐能力。

正常來講服務(wù)的 QPS 可能隨著時(shí)間的變化進(jìn)行有規(guī)律的增長(zhǎng)或減小，但是如果在某段時(shí)間內(nèi) QPS 發(fā)生了成倍的數(shù)量級(jí)的增長(zhǎng)，那么有可能你的服務(wù)正在遭受 DDoS 攻擊，或者正在被非法調(diào)用。