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

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

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

整體分為兩個大的方面：

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

[[376610]]

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

1. CPU

(1) CPU Load

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

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

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

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

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

(2) CPU Usage

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

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

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

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

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，這里是主要是因為 V8 的內(nèi)存回機制，在進(jìn)程中有一些內(nèi)存是可回收并且沒有馬上被回收的，Total - Used 實際上是指當(dāng)前可以回收但沒有回收的內(nèi)存。

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

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

(4) 內(nèi)存 External

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

加之 external string 在 Node.js 中使用的得很少，因此我們可以認(rèn)為對一個常見的 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ǒ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對象(tcp, udp, fs, timer 等對象)的數(shù)量。對于常見的 web 應(yīng)用來說， libuv handles 較高通常意味著當(dāng)前請求量較大或者有 tcp 連接等未被正確釋放。之前在線上業(yè)務(wù)中還會經(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ù)。目前主流的、對 libuv latency 的計算方式，都是通過 setTimeout() 來設(shè)置 timer ，并記錄回調(diào)函數(shù)被調(diào)用時所消耗的時間和預(yù)計消耗的時間之間的差值作為 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)致簡單的操作也不能按時完成。而對于 Node.js 進(jìn)程來說，這類情況很可能是由調(diào)用了耗時較長的同步函數(shù)或是阻塞的 IO 操作導(dǎo)致。

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

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

1. 狀態(tài)碼

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

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

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

一般在我們的業(yè)務(wù)邏輯中，都需要對服務(wù)運行的過程中產(chǎn)生的異常進(jìn)行捕獲以及日志上報，但是我們不可能在所有程序運行的節(jié)點進(jìn)行異常捕獲，另外 try catch 也不是萬能的，它并不能捕獲異步異常，所以我們一般在我們使用的 Node.js 框架中的關(guān)鍵節(jié)點也會集成日志的上報，以 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)行異常上報：

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)生的異常都會被捕獲并上報，所以對于你想了解到的異常你不應(yīng)該手動進(jìn)行 try catch，而是將它們拋出到框架進(jìn)行捕獲上報。

2. pm2 日志

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

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

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

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

3. 延時

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

4. QPS

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

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