本文由尚妝前端開發工程師欲休撰寫
本文發表於github尚妝部落格,歡迎訂閱!
需求背景
目前node端的服務逐漸成熟,在不少公司內部也開始承擔業務處理或者檢視渲染工作。不同於個人開發的簡單伺服器,企業級的node服務要求更為苛刻:
高穩定性、高可靠性、魯棒性以及直觀的監控和報警
想象下一個存在安全隱患且沒有監控預警系統的node服務在生產環境下執行的場景,當某個node例項掛掉的情況下,運維人員或者對應開發維護人員無法立即知曉,直到客戶或者測試人員報告bugs才開始解決問題。在這段無人處理的時間內,損失的訂單數和使用者的忠誠度和信任度將是以後無法彌補的,因此對於node程式的業務開發者而言,這就要求程式碼嚴謹、異常處理完備;對於node框架的維護者而言,則需要提供完善的監控預警系統。
功能
當一個服務程式在後端執行時(daemon),作為開發者我們關注的資訊主要有以下幾點:
- 服務程式是否正在執行,isalive
- 服務程式的記憶體使用率,是否存在未回收(釋放)的記憶體
- 服務程式的cpu使用率,在計算量大的情況下是否需要分片處理、延時處理
- 服務程式的實時響應時間和吞吐量
而作為一個運維人員,關注的不僅僅是node服務程式的相關資訊,還包括物理主機的使用狀況:
- 物理硬碟所剩儲存空間
- 記憶體、cpu使用率
- 網路接入是否正常
可以看出,不管是針對主機還是程式進行監控,我們的關注點大多數是資源使用率和業務量處理能力,因此我們的監控預警系統也著重實現這些功能。
系統簡易架構
目前生產環境下的node服務大多采用多程式或者cluster模式,而且為了響應突發流量往往採用多機部署,因此監控和預警的目標實體就是多物理(虛擬)機下的多個子程式。
比如,目前node服務在單機上往往採用1+n的程式模型:所謂1,即1個主程式;n,表示n個工作程式,而且這些工作程式是從主程式上fork出來,同時根據經驗,n的值往往等同於主機的cpu核心數,充分利用其並行能力。那麼,採用該種程式模型的node服務部署線上上4臺物理機上,我們需要監控的則是4xn個程式,這涉及到了分散式資料同步的問題,需要尋找一種方法實現高效、準確和簡易的資料存和讀,並且儘可能的保證這些資料的可靠性。
在這裡,筆者採用了分散式資料一致系統ZooKeeper(下文簡寫為ZK)實現資料的存和讀。之所以沒有采用傳統的資料庫是由於讀寫表的效能,如為了防止多個程式同時寫表造成衝突必須進行鎖表等操作,而且讀寫硬碟的效能相對記憶體讀寫較低;之所以沒有采用IPC+事件機制實現多程式通訊,主要是由於node提供的IPC通訊機制僅限於父子程式,對於不同主機的程式無法進行通訊或者實現複雜度較高,因此也並未採用該種方式。
採用ZK來實現多節點下的資料同步,可在保證叢集可靠性的基礎上達到資料的最終一致性,對於監控系統而言,不需要時刻都精確的資料,因此資料的最終一致性完全滿足系統的需求。ZK服務叢集通過paxos演算法實現選舉,並採用ZK獨特的演算法實現資料在各個叢集節點的同步,最終抽象為一個資料層。這樣ZK客戶端就可以通過訪問ZK叢集的任意一個服務節點獲取或讀寫相同的資料,用通俗的語言來形容,就是ZK客戶端看到的所有ZK服務節點都有相同的資料。
另外,ZK提供了一種臨時節點,即ephemeral。該節點與客戶端的會話session相繫結,一旦會話超時或者連線斷開,該節點就會消失,並觸發對應事件,因此利用該種特性可以設定node服務的isalive(是否存活)功能。不過,目前node社群針對ZK的客戶端還不是很完善(主要是文件),筆者採用node-zookeeper-client模組並且針對所有介面promise化,這樣在進行多級znode開發時更可讀。
上圖是筆者設計的監控預警系統的架構圖,這裡需要著重關注一下幾點:
- ZooKeeper部署與znode節點使用
- 單機內部node程式的程式模型:1+n+1
- precaution程式的工作內容以及與master和worker的通訊方式
下面著重詳述以上幾點。
ZooKeeper部署與編碼細節
上節已提到,ZooKeeper抽象為一個資料一致層,它是由多個節點組成的儲存叢集,因此在具體的線上環境下,ZK叢集是由多個線上主機搭建而成,所有的資料都是儲存在記憶體中,每當對應工作程式的資料發生變化時則修改對應znode節點的資料,在具體實現中每個znode節點儲存的是json資料,便於node端直接解析。
在具體的程式碼中,我們需要注意的是ZK客戶端會話超時和網路斷開重連的問題。預設,ZK客戶端會幫助我們完成網路斷開後重連過程的簡歷,而且在重新連線的過程中會攜帶上次斷開連線的session id,這樣在session未超時的前提下仍會繫結之前的資料;但是當session超時的情況下,對應session id的資料將會被清空,這就需要我們的自己處理這種情況,又稱作現場恢復。其實,在監控系統中,由於需要實時查詢對應節點資料,需要始終保持session,在設定session expire時間的情況下終究會出現ZK客戶端會話超時的情況,因此需要我們實現現場恢復,需要注意。
程式模型
大多數開發者為了提高node程式的並行處理能力,往往採用一個主程式+多個工作程式的方式處理請求,這在不需要監控預警系統的前提下是可以滿足要求的。但是,隨著監控預警功能的加入,有很多人估計會把這些功能加入到主程式,這首先不說主程式工作職能的混亂,最主要的是額外增加了風險性(預警系統的職能之一就是打點堆快照,並提醒開發者。因此主程式內執行查詢、打點系統資源、傳送郵件等工作存在可能的風險)。因此為了主程式的功能單一性和可靠性,建立了一個precaution程式,該程式與主程式同級。
採用1+n+1模型並不會影響請求處理效率,工作程式的職能仍是處理請求,因此新的程式模型完全相容之前的程式碼,需要做的就是在主程式和precaution程式執行的程式碼中新增業務部分程式碼。
通訊方式
在監控預警系統中,需要實現precaution程式<-->master程式、master程式<-->worker程式、precaution程式<-->worker程式的雙向通訊,如打點記憶體,需要由precaution程式通知對應worker程式,worker進行打點完成後傳送訊息給precaution程式,precaution進行處理後傳送郵件通知。
首先,worker與master的通訊走的是node提供的IPC通道,需要注意的是IPC通道只能傳輸字串和可結構化的物件。可結構化的物件可以用一個公式簡易表述:
o = JSON.parse(JSON.stringify(o))複製程式碼
如RegExp的例項就不是可結構化物件。
其次,worker和precaution的通訊是通過master作為橋樑實現的,因此其中的關節點就在於precaution與master的通訊。
最後,precaution與master的通訊採用domain socket機制實現,這兩個程式是隻是兩個node例項而已,因此無法採用node提供的IPC機制,而程式間通訊可以採用其他方法如:命名管道、共享記憶體、訊號量和訊息佇列等,採用這些方法實現固然簡單,但是缺點在於兩個程式耦合度相對較高,如命名管道需要建立具體的管道檔案並且對管道檔案大小有限制。使用domain socket,最大的好處就是靈活制定通訊協議,且易於擴充套件。
node的net模組提供了domain socket的通訊方式,與網路伺服器類似,採用domain通訊的伺服器偵聽的不是埠而是sock檔案,採用這種方式實現全雙工通訊。
業務量計算和資料打點
這裡提到的業務量,指的是監控預警系統所關注的資料業務,如記憶體和cpu利用率、吞吐量(request per minute)和響應時間。其中,記憶體和cpu利用率可以通過linux下的相關命令如top來查詢,響應時間和吞吐量則通過koa中介軟體實現粗略統計。不過為了方便開發者把精力集中到業務上去而非相容底層作業系統,建議使用pidusage模組完成資源利用率的測量,而針對吞吐量筆者並未找到相關的工具進行測量,僅在中介軟體中粗略計算得出。
在precaution程式中,設定了兩個閾值。一個是warning值,當使用記憶體大小超過了該值則進行日誌打點,並開始週期性的node堆記憶體打點;另一個是danger值,超過該值則進行記憶體打點併傳送郵件提醒,根據附件中的近三個快照分析記憶體。
總結
採用上述監控預警架構,可以有效的實現多節點下多程式的監控,在確保程式可靠性的基礎上完成侵入性較小的、安全性較高的、可擴充套件性強的實現。以後不管是臨時擴張主機節點還是更改子程式數量,都可以瞬時在UI介面上直觀體現,如