摘要：業(yè)務量計算和數(shù)據(jù)打點這里提到的業(yè)務量，指的是監(jiān)控預警系統(tǒng)所關注的數(shù)據(jù)業(yè)務，如內(nèi)存和利用率吞吐量和響應時間。其中，內(nèi)存和利用率可以通過下的相關命令如來查詢，響應時間和吞吐量則通過中間件實現(xiàn)粗略統(tǒng)計。

目前node端的服務逐漸成熟，在不少公司內(nèi)部也開始承擔業(yè)務處理或者視圖渲染工作。不同于個人開發(fā)的簡單服務器，企業(yè)級的node服務要求更為苛刻：

高穩(wěn)定性、高可靠性、魯棒性以及直觀的監(jiān)控和報警

想象下一個存在安全隱患且沒有監(jiān)控預警系統(tǒng)的node服務在生產(chǎn)環(huán)境下運行的場景，當某個node實例掛掉的情況下，運維人員或者對應開發(fā)維護人員無法立即知曉，直到客戶或者測試人員報告bugs才開始解決問題。在這段無人處理的時間內(nèi)，損失的訂單數(shù)和用戶的忠誠度和信任度將是以后無法彌補的，因此對于node程序的業(yè)務開發(fā)者而言，這就要求代碼嚴謹、異常處理完備；對于node框架的維護者而言，則需要提供完善的監(jiān)控預警系統(tǒng)。

當一個服務進程在后端運行時（daemon），作為開發(fā)者我們關注的信息主要有以下幾點：

服務進程是否正在運行，isalive

服務進程的內(nèi)存使用率，是否存在未回收（釋放）的內(nèi)存

服務進程的cpu使用率，在計算量大的情況下是否需要分片處理、延時處理

服務進程的實時響應時間和吞吐量

而作為一個運維人員，關注的不僅僅是node服務進程的相關信息，還包括物理主機的使用狀況：

物理硬盤所剩存儲空間

內(nèi)存、cpu使用率

網(wǎng)絡接入是否正常

可以看出，不管是針對主機還是進程進行監(jiān)控，我們的關注點大多數(shù)是資源使用率和業(yè)務量處理能力，因此我們的監(jiān)控預警系統(tǒng)也著重實現(xiàn)這些功能。

目前生產(chǎn)環(huán)境下的node服務大多采用多進程或者cluster模式，而且為了響應突發(fā)流量往往采用多機部署，因此監(jiān)控和預警的目標實體就是多物理（虛擬）機下的多個子進程。

比如，目前node服務在單機上往往采用1+n的進程模型：所謂1，即1個主進程；n，表示n個工作進程，而且這些工作進程是從主進程上fork出來，同時根據(jù)經(jīng)驗，n的值往往等同于主機的cpu核心數(shù)，充分利用其并行能力。那么，采用該種進程模型的node服務部署在線上4臺物理機上，我們需要監(jiān)控的則是4xn個進程，這涉及到了分布式數(shù)據(jù)同步的問題，需要尋找一種方法實現(xiàn)高效、準確和簡易的數(shù)據(jù)存和讀，并且盡可能的保證這些數(shù)據(jù)的可靠性。

在這里，筆者采用了分布式數(shù)據(jù)一致系統(tǒng)ZooKeeper（下文簡寫為ZK）實現(xiàn)數(shù)據(jù)的存和讀。之所以沒有采用傳統(tǒng)的數(shù)據(jù)庫是由于讀寫表的性能，如為了防止多個進程同時寫表造成沖突必須進行鎖表等操作，而且讀寫硬盤的性能相對內(nèi)存讀寫較低；之所以沒有采用IPC+事件機制實現(xiàn)多進程通信，主要是由于node提供的IPC通信機制僅限于父子進程，對于不同主機的進程無法進行通信或者實現(xiàn)復雜度較高，因此也并未采用該種方式。

采用ZK來實現(xiàn)多節(jié)點下的數(shù)據(jù)同步，可在保證集群可靠性的基礎上達到數(shù)據(jù)的最終一致性，對于監(jiān)控系統(tǒng)而言，不需要時刻都精確的數(shù)據(jù)，因此數(shù)據(jù)的最終一致性完全滿足系統(tǒng)的需求。ZK服務集群通過paxos算法實現(xiàn)選舉，并采用ZK獨特的算法實現(xiàn)數(shù)據(jù)在各個集群節(jié)點的同步，最終抽象為一個數(shù)據(jù)層。這樣ZK客戶端就可以通過訪問ZK集群的任意一個服務節(jié)點獲取或讀寫相同的數(shù)據(jù)，用通俗的語言來形容，就是ZK客戶端看到的所有ZK服務節(jié)點都有相同的數(shù)據(jù)。

另外，ZK提供了一種臨時節(jié)點，即ephemeral。該節(jié)點與客戶端的會話session相綁定，一旦會話超時或者連接斷開，該節(jié)點就會消失，并觸發(fā)對應事件，因此利用該種特性可以設置node服務的isalive（是否存活）功能。不過，目前node社區(qū)針對ZK的客戶端還不是很完善（主要是文檔），筆者采用node-zookeeper-client模塊并且針對所有接口promise化，這樣在進行多級znode開發(fā)時更可讀。

上圖是筆者設計的監(jiān)控預警系統(tǒng)的架構圖，這里需要著重關注一下幾點：

ZooKeeper部署與znode節(jié)點使用

單機內(nèi)部node進程的進程模型：1+n+1

precaution進程的工作內(nèi)容以及與master和worker的通信方式

下面著重詳述以上幾點。

上節(jié)已提到，ZooKeeper抽象為一個數(shù)據(jù)一致層，它是由多個節(jié)點組成的存儲集群，因此在具體的線上環(huán)境下，ZK集群是由多個線上主機搭建而成，所有的數(shù)據(jù)都是存儲在內(nèi)存中，每當對應工作進程的數(shù)據(jù)發(fā)生變化時則修改對應znode節(jié)點的數(shù)據(jù)，在具體實現(xiàn)中每個znode節(jié)點存儲的是json數(shù)據(jù)，便于node端直接解析。

在具體的代碼中，我們需要注意的是ZK客戶端會話超時和網(wǎng)絡斷開重連的問題。默認，ZK客戶端會幫助我們完成網(wǎng)絡斷開后重連過程的簡歷，而且在重新連接的過程中會攜帶上次斷開連接的session id，這樣在session未超時的前提下仍會綁定之前的數(shù)據(jù)；但是當session超時的情況下，對應session id的數(shù)據(jù)將會被清空，這就需要我們的自己處理這種情況，又稱作現(xiàn)場恢復。其實，在監(jiān)控系統(tǒng)中，由于需要實時查詢對應節(jié)點數(shù)據(jù)，需要始終保持session，在設定session expire時間的情況下終究會出現(xiàn)ZK客戶端會話超時的情況，因此需要我們實現(xiàn)現(xiàn)場恢復，需要注意。

大多數(shù)開發(fā)者為了提高node程序的并行處理能力，往往采用一個主進程+多個工作進程的方式處理請求，這在不需要監(jiān)控預警系統(tǒng)的前提下是可以滿足要求的。但是，隨著監(jiān)控預警功能的加入，有很多人估計會把這些功能加入到主進程，這首先不說主進程工作職能的混亂，最主要的是額外增加了風險性（預警系統(tǒng)的職能之一就是打點堆快照，并提醒開發(fā)者。因此主進程內(nèi)執(zhí)行查詢、打點系統(tǒng)資源、發(fā)送郵件等工作存在可能的風險）。因此為了主進程的功能單一性和可靠性，創(chuàng)建了一個precaution進程，該進程與主進程同級。

采用1+n+1模型并不會影響請求處理效率，工作進程的職能仍是處理請求，因此新的進程模型完全兼容之前的代碼，需要做的就是在主進程和precaution進程執(zhí)行的代碼中添加業(yè)務部分代碼。

在監(jiān)控預警系統(tǒng)中，需要實現(xiàn)precaution進程<-->master進程、master進程<-->worker進程、precaution進程<-->worker進程的雙向通信，如打點內(nèi)存，需要由precaution進程通知對應worker進程，worker進行打點完成后發(fā)送消息給precaution進程，precaution進行處理后發(fā)送郵件通知。

首先，worker與master的通信走的是node提供的IPC通道，需要注意的是IPC通道只能傳輸字符串和可結構化的對象?？山Y構化的對象可以用一個公式簡易表述：

o = JSON.parse(JSON.stringify(o))

如RegExp的實例就不是可結構化對象。

其次，worker和precaution的通信是通過master作為橋梁實現(xiàn)的，因此其中的關節(jié)點就在于precaution與master的通信。

最后，precaution與master的通信采用domain socket機制實現(xiàn)，這兩個進程是只是兩個node實例而已，因此無法采用node提供的IPC機制，而進程間通信可以采用其他方法如：命名管道、共享內(nèi)存、信號量和消息隊列等，采用這些方法實現(xiàn)固然簡單，但是缺點在于兩個進程耦合度相對較高，如命名管道需要創(chuàng)建具體的管道文件并且對管道文件大小有限制。使用domain socket，最大的好處就是靈活制定通信協(xié)議，且易于擴展。

node的net模塊提供了domain socket的通信方式，與網(wǎng)絡服務器類似，采用domain通信的服務器偵聽的不是端口而是sock文件，采用這種方式實現(xiàn)全雙工通信。

這里提到的業(yè)務量，指的是監(jiān)控預警系統(tǒng)所關注的數(shù)據(jù)業(yè)務，如內(nèi)存和cpu利用率、吞吐量（request per minute）和響應時間。其中，內(nèi)存和cpu利用率可以通過linux下的相關命令如top來查詢，響應時間和吞吐量則通過koa中間件實現(xiàn)粗略統(tǒng)計。不過為了方便開發(fā)者把精力集中到業(yè)務上去而非兼容底層操作系統(tǒng)，建議使用pidusage模塊完成資源利用率的測量，而針對吞吐量筆者并未找到相關的工具進行測量，僅在中間件中粗略計算得出。

在precaution進程中，設置了兩個閾值。一個是warning值，當使用內(nèi)存大小超過了該值則進行日志打點，并開始周期性的node堆內(nèi)存打點；另一個是danger值，超過該值則進行內(nèi)存打點并發(fā)送郵件提醒，根據(jù)附件中的近三個快照分析內(nèi)存。

采用上述監(jiān)控預警架構，可以有效的實現(xiàn)多節(jié)點下多進程的監(jiān)控，在確保進程可靠性的基礎上完成侵入性較小的、安全性較高的、可擴展性強的實現(xiàn)。以后不管是臨時擴張主機節(jié)點還是更改子進程數(shù)量，都可以瞬時在UI界面上直觀體現(xiàn)，如