node端的服務逐漸成熟,不少公司內部也承擔業務處理或者視圖渲染工作

發布時間:2021年11月13日 閱讀:468 次

node端的服務逐漸成熟,不少公司內部也承擔業務處理或者視圖渲染工作

需求背景

目前node端的服務逐漸成熟,在不少公司內部也開始承擔業務處理或者視圖渲染工作。不同于個人開發的簡單服務器,企業級的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端的服務逐漸成熟,不少公司內部也承擔業務處理或者視圖渲染工作

進程模型

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

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

通信方式

在監控預警系統中,需要實現precaution進程<-->master進程、master進程<-->worker進程、precaution進程<-->worker進程的雙向通信,如打點內存,需要由precaution進程通知對應worker進程,worker進行打點完成后發送消息給precaution進程,precaution進行處理后發送郵件通知。


Tag:node端 服務 逐漸 成熟 公司 內部 承擔 業務 處理 視圖 渲染 工作
相關文章

發表評論:

性中国熟女毛耸耸性视频,办公室沙发口爆12P,在车上玩弄我的美艳搜子