一種基于Node.js 的校園高并發(fā)Web 應(yīng)用架構(gòu)

袁文光

（長(zhǎng)沙商貿(mào)旅游職業(yè)技術(shù)學(xué)院 網(wǎng)絡(luò)中心， 長(zhǎng)沙 410116）

高校校園Web 應(yīng)用服務(wù)平臺(tái)承載了學(xué)校眾多業(yè)務(wù)系統(tǒng)，日常承擔(dān)著師生海量在線并發(fā)訪問請(qǐng)求。師生線上業(yè)務(wù)辦理、信息查詢、文件上傳下載等均屬網(wǎng)絡(luò)、磁盤I/O 密集型操作。師生線上活躍程度越高，平臺(tái)的網(wǎng)絡(luò)和磁盤I/O 承載壓力越大，給Web 系統(tǒng)帶來的負(fù)擔(dān)越重[1]，往往導(dǎo)致訪問速度下降、響應(yīng)時(shí)間過長(zhǎng)、請(qǐng)求失敗，甚至出現(xiàn)系統(tǒng)崩潰等問題。隨著高校的辦學(xué)規(guī)模的擴(kuò)大和教育資源的豐富，Web 應(yīng)用平臺(tái)的服務(wù)能力逐漸不能滿足學(xué)校發(fā)展需求。傳統(tǒng)的解決方法大多是通過橫向擴(kuò)展提升平臺(tái)的并發(fā)和數(shù)據(jù)處理能力，然而單純的軟硬件數(shù)量的擴(kuò)充并不能從根本上解決問題，因此，需通過縱向擴(kuò)展法提升服務(wù)器單機(jī)系統(tǒng)的I/O 能力。本文擬提出一種基于Node.js 的Web 應(yīng)用架構(gòu)，為解決校園Web 高并發(fā)性能問題提供一種新方法。

1 Node.js 及其核心技術(shù)

Node.js 最早衍生于RyanDahl 的一個(gè)Web 項(xiàng)目，其將V8 引擎從Chrome 瀏覽器中剝離出來，并做二次封裝[2]，使V8 引擎在服務(wù)器端狀態(tài)更佳，突破了JavaScript 只能在瀏覽器環(huán)境中運(yùn)行的局限。在后端Web 應(yīng)用的開發(fā)中，JavaScript 不再依賴瀏覽器的解析，可隨意訪問本地文件，直接操作數(shù)據(jù)庫[3]。由于JavaScript 異步、非阻塞I/O的特性，Node.js 不斷完善的功能及豐富的第三方庫，使其在高并發(fā)的應(yīng)用場(chǎng)景中優(yōu)勢(shì)凸顯。Node.js擁有兩項(xiàng)核心技術(shù)：一是事件驅(qū)動(dòng)、單線程；二是異步、非阻塞I/O。

1.1 事件驅(qū)動(dòng)、單線程

Node.js 可將用戶請(qǐng)求抽象成事件，按照事件機(jī)制處理用戶的并發(fā)請(qǐng)求，并用線程循環(huán)監(jiān)測(cè)事件。當(dāng)監(jiān)測(cè)到事件發(fā)生時(shí)，將該事件添加到事件隊(duì)列中，線程不必等待事件處理完成，即可持續(xù)監(jiān)測(cè)和觸發(fā)新事件。在單線程模式下，可以同時(shí)處理海量請(qǐng)求，避開了多線程模式下系統(tǒng)需要不斷創(chuàng)建、銷毀線程及在線程間切換管理所需的開銷和復(fù)雜性，使Node.js 對(duì)系統(tǒng)內(nèi)存的依賴程度更低，消耗的系統(tǒng)I/O 資源更少。

1.2 異步、非阻塞I/O

Web 系統(tǒng)是典型的I/O 密集型應(yīng)用系統(tǒng)，Web 應(yīng)用性能瓶頸主要在于I/O 操作，包括磁盤I/O（連接數(shù)、機(jī)器性能等）、緩存服務(wù)、網(wǎng)絡(luò)I/O等。在異步I/O 方式下，遇到I/O（磁盤/網(wǎng)絡(luò)）操作時(shí)，線程不會(huì)被阻塞掛起，也無須等待操作結(jié)果，可另行處理其他請(qǐng)求，大大提高事務(wù)處理效率。在同步I/O 方式下，要同時(shí)處理多個(gè)請(qǐng)求，必須開啟多個(gè)線程，需耗費(fèi)大量的系統(tǒng)內(nèi)存資源。

2 高校Web 應(yīng)用架構(gòu)現(xiàn)狀

2.1 多線程框架

當(dāng)前，各高校主流的Web 服務(wù)器如IIS、Apache、Tomcat 等，都是以多線程機(jī)制應(yīng)對(duì)高并發(fā)請(qǐng)求[4]。譬如Apache+PHP，雖然PHP 是單線程語言，但Apache 為多線程機(jī)制，一個(gè)外部請(qǐng)求觸發(fā)一個(gè)Apache 線程，同時(shí)開啟一個(gè)PHP 線程。以創(chuàng)建一個(gè)線程消耗2 M 內(nèi)存計(jì)算，標(biāo)配16 G 內(nèi)存的服務(wù)器，理論上也只能創(chuàng)建8 000 個(gè)線程。當(dāng)線程數(shù)超過線程池上限時(shí)，服務(wù)器響應(yīng)請(qǐng)求的數(shù)量會(huì)驟減。因此，多線程框架可以處理的用戶請(qǐng)求數(shù)量，受限于服務(wù)器物理內(nèi)存的大小。同時(shí)，系統(tǒng)在多線程模式下，進(jìn)行線程頻繁開啟、銷毀、上下文切換、狀態(tài)同步等操作時(shí)，需額外消耗CPU、I/O 資源，使系統(tǒng)資源緊張加劇。

2.2 同步、阻塞I/O

校園 Web 系統(tǒng)的編程語言（JAVA，ASP.net等）基本是多線程、同步、阻塞I/O 機(jī)制[5]，在與用戶建立連接時(shí)，每個(gè)連接都創(chuàng)建一個(gè)線程。N 個(gè)連接，服務(wù)器上就有N 個(gè)線程。線程在執(zhí)行I/O 操作時(shí)，經(jīng)常會(huì)被阻塞，需在整個(gè)I/O 操作完成后才能繼續(xù)執(zhí)行。譬如：傳統(tǒng)服務(wù)器（Apache、Tomcat）采用了I/O 阻塞機(jī)制，每條數(shù)據(jù)寫入數(shù)據(jù)庫都要等待一段時(shí)間（等上一條寫完再寫下一條），導(dǎo)致I/O占用的資源無法及時(shí)釋放，后續(xù)任務(wù)需持續(xù)等待，降低了系統(tǒng)資源利用率。

2.3 橫向擴(kuò)展

針對(duì)高校Web 系統(tǒng)的性能問題，傳統(tǒng)的解決方法主要是增加服務(wù)器數(shù)量，搭建服務(wù)器集群及數(shù)據(jù)庫集群等。增加服務(wù)器數(shù)量的橫向擴(kuò)展法，雖能暫時(shí)提高并發(fā)能力，但多線程架構(gòu)易導(dǎo)致平臺(tái)硬件資源緊張，同步、阻塞I/O 會(huì)導(dǎo)致服務(wù)器資源利用率降低，建設(shè)成本高昂等問題。因此，從單機(jī)系統(tǒng)出發(fā)，修改、優(yōu)化、強(qiáng)化系統(tǒng)架構(gòu)，實(shí)施縱向擴(kuò)展法，提升服務(wù)器并發(fā)能力，非常必要。

3 基于Node.js 的高并發(fā)架構(gòu)

3.1 應(yīng)用架構(gòu)設(shè)計(jì)

Node.js 具有事件驅(qū)動(dòng)、異步I/O 等特性，能滿足高校高并發(fā)Web 應(yīng)用需求。結(jié)合Node.js 技術(shù)特性，通過構(gòu)建新架構(gòu)、多服務(wù)器技術(shù)集成等可提升服務(wù)器單機(jī)性能。架構(gòu)設(shè)計(jì)的重點(diǎn)是提升系統(tǒng)應(yīng)對(duì)密集型磁盤I/O 操作的能力，其分層架構(gòu)如圖1 所示。

圖1 Web 應(yīng)用架構(gòu)設(shè)計(jì)

架構(gòu)縱向分為服務(wù)、緩存、數(shù)據(jù)、消息隊(duì)列4層。每一層承擔(dān)相應(yīng)職責(zé)，分工又合作，共同構(gòu)建高效系統(tǒng)。

（1）服務(wù)層縱向分割為負(fù)載均衡層、業(yè)務(wù)邏輯層、基礎(chǔ)服務(wù)層。負(fù)載均衡層實(shí)現(xiàn)負(fù)載均衡功能，接收HTTP 請(qǐng)求，將靜態(tài)、動(dòng)態(tài)請(qǐng)求分別分發(fā)至靜態(tài)資源服務(wù)器和Node.js 服務(wù)器。業(yè)務(wù)邏輯層主要處理業(yè)務(wù)邏輯，調(diào)用基礎(chǔ)服務(wù)層處理用戶請(qǐng)求，并將結(jié)果返回用戶瀏覽器；使用局域NPM（Node Package Manage）包服務(wù)，將業(yè)務(wù)邏輯層的各功能縱向拆分；實(shí)施分布式部署，且各功能獨(dú)立成模塊并分別部署為一個(gè)微服務(wù)，使用消息隊(duì)列、Rest 請(qǐng)求等，保持各微服務(wù)間的通信，可充分調(diào)用高速緩存，將高頻數(shù)據(jù)的讀寫從數(shù)據(jù)庫遷移至內(nèi)存，降低磁盤I/O 頻次。基礎(chǔ)服務(wù)層實(shí)現(xiàn)文件存儲(chǔ)、權(quán)限管理、日志記錄、異常處理等功能，為業(yè)務(wù)邏輯層提供基礎(chǔ)支撐。

（2）緩存層縱向分割為緩存訪問層和緩存更新層。緩存訪問層為上層提供緩存服務(wù)，訪問和更新緩存；緩存更新層實(shí)現(xiàn)系統(tǒng)緩存更新，接收隊(duì)列信息更新RabbitmQ 的消息。

（3）數(shù)據(jù)層縱向分割為數(shù)據(jù)訪問層和數(shù)據(jù)存儲(chǔ)層。數(shù)據(jù)層調(diào)用Node.js 的數(shù)據(jù)接口，訪問和更新數(shù)據(jù)庫，數(shù)據(jù)存儲(chǔ)層可以是關(guān)系數(shù)據(jù)庫（MySQL、SQLserver） 或者 NoSQL 數(shù)據(jù)庫（HBase、MongoDB）。

（4）消息隊(duì)列層可降低系統(tǒng)耦合度，增加系統(tǒng)內(nèi)聚性，構(gòu)成異構(gòu)系統(tǒng)，實(shí)現(xiàn)服務(wù)器間或業(yè)務(wù)間的消息接收和發(fā)送（如數(shù)據(jù)庫更新、用戶注銷、緩存更新等）延緩耗時(shí)的I/O 操作，使系統(tǒng)具備更好的擴(kuò)展性和維護(hù)性。

3.2 基于Node.js 的高并發(fā)架構(gòu)的實(shí)現(xiàn)技術(shù)

如圖2 所示，基于Node.js 的Web 應(yīng)用架構(gòu)實(shí)現(xiàn)技術(shù)主要包括負(fù)載均衡、Cluster 多核、功能模塊化、高速緩存、數(shù)據(jù)庫、RabbitmQ 消息隊(duì)列等技術(shù)。

圖2 高并發(fā)架構(gòu)的實(shí)現(xiàn)技術(shù)

（1）負(fù)載均衡技術(shù)

負(fù)載均衡層處于架構(gòu)的第一層，是網(wǎng)絡(luò)用戶請(qǐng)求的開始。使用HAProxy 編制路由規(guī)則，通過負(fù)載均衡算法，將請(qǐng)求分為動(dòng)態(tài)和靜態(tài)兩類，將靜態(tài)請(qǐng)求直接路由至靜態(tài)資源服務(wù)器，將動(dòng)態(tài)請(qǐng)求分發(fā)至不同的業(yè)務(wù)服務(wù)器，以平衡各服務(wù)器的負(fù)載。HAProxy 適合負(fù)載較大的Web 應(yīng)用，能支持海量并發(fā)連接，同時(shí)，HAProxy 具備可視化的管理端，實(shí)時(shí)監(jiān)控服務(wù)器負(fù)荷，配合人工調(diào)控，可達(dá)到最佳效果。

（2）Cluster 多核技術(shù)

Node.js 默認(rèn)單進(jìn)程單線程模式，默認(rèn)模式下的Node.js 只能使用服務(wù)器多核CPU 中的一核，造成資源浪費(fèi)。為了充分利用多核CPU 的計(jì)算資源，Node.js 內(nèi)置Cluster 模塊，以創(chuàng)建多個(gè)進(jìn)程，由多個(gè)進(jìn)程共同提供服務(wù)。Cluster 多核技術(shù)發(fā)揮了多核CPU 的優(yōu)勢(shì)，可以很好地用于集群式部署。

（3）功能模塊化技術(shù)

作為主流前端開發(fā)語言，JavaScript 的顯著缺點(diǎn)是缺乏完善的模塊機(jī)制，必須使用＜Script＞＃標(biāo)簽來引用文件。Node.js 制訂了CommonJS 規(guī)范，完善了JavaScript 語言，使其在前后端都能運(yùn)行。Node.js 的包管理器 NPM 是基于 CommonJS 的Package 規(guī)范實(shí)現(xiàn)的。

局域NPM 倉庫實(shí)現(xiàn)業(yè)務(wù)功能模塊化，如圖3所示，局域NPM 倉庫系統(tǒng)按照業(yè)務(wù)邏輯進(jìn)行功能拆分，分解成相互獨(dú)立的模塊，模塊之間通過接口調(diào)用。

圖3 局域NPM 倉庫設(shè)計(jì)

（4）高速緩存技術(shù)

在高并發(fā)環(huán)境下，Web 系統(tǒng)性能瓶頸集中于磁盤I/O。因此，在Web 服務(wù)器與數(shù)據(jù)庫間設(shè)計(jì)加入Redis 緩存數(shù)據(jù)庫，以降低磁盤I/O 頻次。Redis是內(nèi)存數(shù)據(jù)庫，數(shù)據(jù)直接寫在內(nèi)存，也直接從內(nèi)存中讀取，避免直接讀寫磁盤。具體而言，對(duì)于實(shí)時(shí)性高的數(shù)據(jù)杜絕用戶直接訪問磁盤數(shù)據(jù)庫（DB），而是訪問緩存數(shù)據(jù)庫，降低磁盤I/O 頻次。如圖4所示，Redis 實(shí)現(xiàn)緩存中數(shù)據(jù)的讀取和更新，同時(shí)監(jiān)聽消息隊(duì)列并更新緩存，保證數(shù)據(jù)的一致性。

圖4 高速緩存實(shí)現(xiàn)技術(shù)

（5）數(shù)據(jù)庫技術(shù)

在Web 系統(tǒng)中，數(shù)據(jù)的讀操作遠(yuǎn)多于數(shù)據(jù)的寫操作，一個(gè)寫操作尚未完成，讀操作將無法進(jìn)行。在高并發(fā)背景下，為解決用戶的讀和寫操作的沖突，設(shè)計(jì)主從數(shù)據(jù)庫，以實(shí)現(xiàn)讀寫分離，即主數(shù)據(jù)庫進(jìn)行寫操作，從數(shù)據(jù)庫進(jìn)行讀操作。采用Keepalive 雙機(jī)熱備技術(shù)保證主從數(shù)據(jù)庫中內(nèi)容的一致性和安全性，可有效減少數(shù)據(jù)讀寫的時(shí)間，其設(shè)計(jì)如圖5 所示。

圖5 Keepalive 雙機(jī)熱備

圖 5 中，Master 數(shù)據(jù)庫、Slave 數(shù)據(jù)庫互為主從，但master 只進(jìn)行寫操作，slave 只進(jìn)行讀操作。主從數(shù)據(jù)庫通過keepalive 做成高可用，當(dāng)master出問題，由slave 接替master 工作，即讀寫都在slave 操作。當(dāng)master 恢復(fù)正常，master 自動(dòng)同步故障時(shí)間段數(shù)據(jù)，接替slave 的寫操作。

（6）RabbitmQ 消息隊(duì)列技術(shù)

RabbitmQ 消息隊(duì)列技術(shù)優(yōu)點(diǎn)有：延緩業(yè)務(wù)邏輯執(zhí)行，緩解應(yīng)用的負(fù)載壓力；解耦應(yīng)用，各模塊間更加獨(dú)立，提高了開發(fā)效率；構(gòu)筑異構(gòu)應(yīng)用，可使用不同技術(shù)實(shí)現(xiàn)內(nèi)部應(yīng)用。

4 架構(gòu)的高并發(fā)性能測(cè)試及分析

4.1 測(cè)試指標(biāo)

對(duì)所構(gòu)建的基于Node.js 的Web 應(yīng)用架構(gòu)進(jìn)行壓力測(cè)試，主要測(cè)試響應(yīng)時(shí)間、響應(yīng)率和吞吐量等并發(fā)性能指標(biāo)。響應(yīng)時(shí)間指用戶從開始發(fā)起請(qǐng)求到接收返回信息所耗用的時(shí)間，一般取平均值；響應(yīng)率代表系統(tǒng)在規(guī)定時(shí)間內(nèi)，成功處理的請(qǐng)求占總請(qǐng)求的百分比；吞吐量則表示系統(tǒng)在1 s 內(nèi)最大能處理請(qǐng)求的數(shù)量。

4.2 測(cè)試方法

上述并發(fā)性能指標(biāo)需通過系統(tǒng)關(guān)鍵路徑進(jìn)行測(cè)試驗(yàn)證。系統(tǒng)關(guān)鍵路徑由系統(tǒng)外部響應(yīng)、CPU計(jì)算、I/O 操作等構(gòu)成。Web 系統(tǒng)用戶的注冊(cè)過程包含外部響應(yīng)、CPU 校驗(yàn)、數(shù)據(jù)庫I/O 讀寫等環(huán)節(jié)，因此，選擇Web 用戶注冊(cè)這條關(guān)鍵路徑進(jìn)行架構(gòu)指標(biāo)壓力測(cè)試。

4.3 測(cè)試環(huán)境

基于控制變量的方法，分別搭建多核+Node.js和Apache+J2ee 兩種不同架構(gòu)的Web 應(yīng)用，編制相同的業(yè)務(wù)邏輯和數(shù)據(jù)庫，并部署于硬件完全相同的2 臺(tái)服務(wù)器上，配置為操作系統(tǒng)CentOS，CPU型號(hào)為Intel（R）Xeon（R）CPU E5-2430@2.20 GHz，物理核數(shù)為6，線程數(shù)量為12，內(nèi)存16 G，安置在同一局域網(wǎng)內(nèi)，以降低網(wǎng)絡(luò)傳輸?shù)牟环€(wěn)定可能帶來的偏差。使用Apache 自帶工具，對(duì)兩種不同架構(gòu)搭建的Web 應(yīng)用進(jìn)行性能測(cè)試并加以比較。兩種架構(gòu)實(shí)驗(yàn)條件配置如表1 所示。

表1 Node.js 和Apache 實(shí)驗(yàn)條件配置

4.4 測(cè)試實(shí)施

對(duì)兩種架構(gòu)搭建的Web 應(yīng)用的關(guān)鍵路徑（用戶注冊(cè)模塊接口）進(jìn)行壓力測(cè)試，在模擬高并發(fā)場(chǎng)景下分別向這兩臺(tái)服務(wù)器發(fā)送測(cè)試請(qǐng)求（10 次到20 萬次不等），比較兩種不同架構(gòu)的服務(wù)器響應(yīng)時(shí)間、響應(yīng)率和吞吐量的變化，結(jié)果如圖6、7、8。

從圖6 可以看出，當(dāng)并發(fā)數(shù)小于1 500 時(shí)，Node.js 和Apache 的平均響應(yīng)時(shí)間差距很小。隨著并發(fā)數(shù)的增大，Node.js 與Apache 的平均響應(yīng)時(shí)間差距拉大，Node.js 的響應(yīng)時(shí)間顯著低于Apache，表明在面對(duì)高并發(fā)問題時(shí)，Node.js 的處理更高效。

圖6 平均響應(yīng)時(shí)間比較

由圖7 可知，當(dāng)每秒并發(fā)數(shù)小于4 500 時(shí)，Node.js 和Apache 請(qǐng)求響應(yīng)率基本持平，隨著并發(fā)量的增大，Node.js 請(qǐng)求響應(yīng)優(yōu)勢(shì)明顯。

圖7 請(qǐng)求響應(yīng)率比較

由圖8 可見，隨著并發(fā)數(shù)增大，Node.js 和Apache 的吞吐量均有所降低，Apache 不斷創(chuàng)建和銷毀線程的開銷，線程間頻繁切換的開銷，制約了其高并發(fā)處理能力，而Node.js 則具有更高的吞吐量。

圖8 吞吐量對(duì)比

5 結(jié) 語

本文提出了一種基于Node.js 的高并發(fā)Web應(yīng)用架構(gòu)，通過縱向擴(kuò)展法提升服務(wù)器單機(jī)并發(fā)性能。與傳統(tǒng)的多線程、同步阻塞I/O 架構(gòu)相比，面對(duì)海量用戶請(qǐng)求，使用Node.js 和多服務(wù)器技術(shù)集成構(gòu)建的Web 服務(wù)器，處理更高效，優(yōu)勢(shì)更明顯，可大幅提升Web 應(yīng)用服務(wù)平臺(tái)的處理效率，改善用戶體驗(yàn)，能為高校校園網(wǎng)業(yè)務(wù)提供更優(yōu)質(zhì)的服務(wù)平臺(tái)。