本文主要工作如下： 1）通過對 Node.js 的相關技術進行分析，在此基礎上結合實際開發場景，完成了框架的需求分析和結構設計。以模塊化機制為基礎，設計並實現了框架的核心模塊，包括請求管理、參數處理、過濾、路由、會話管理和靜態資源管理等功能模塊，為開發者提供請求處理與響應的各個環節的豐富基礎功能。
1 緒論
1.1 研究背景及意義
隨著網際網路的發展以及 Web 應用數量的快速增加，人們日常生活中方方面面的需求，包括網上銀行、網絡直播、在線醫療、協同辦公等都可以通過 Web 應用實現。而服務端是 Web 應用開發的基石，是 Web 應用質量和性能的重要保障。隨著用戶需求的增長，服務端開發的工作量和複雜度也在日漸上升。在此背景下，使用服務端框架進行開發成為提高 Web 應用開發效率以及改善用戶體驗最為有效的解決方案。
Node.js[1]作為一項誕生於 2009 年的新興技術，於 2011 年正式發布 Windows 版本。由於其高效的 Chrome V8 引擎[2]和異步 I/O 的特性，使得基於 Node.js 開發的 Web 應用程式具有高性能與可擴展的特性[3]。使用 Node.js 進行 Web 應用開發的優勢主要有以下幾個方面：
1）與傳統服務端開發語言相比，Node.js 的異步 I/O 模型對大部分 I/O 請求的響應更快[4]。
2）Node.js 將數據解析與前端分離，實現了視圖層（User Interface，UI）與數據模型的解耦。
3）Node.js 為前端開發語言 JavaScript 提供了服務端的執行環境，實現了前後端開發語言的統一，大大降低了應用的開發成本[5]。
與 Node.js 的高速發展相比，Node.js 在服務端開發領域的成熟度與傳統服務端開發語言相比仍有較大差距，這給 Node.js 在服務端的發展帶來了機遇與挑戰。目前，Node.js 的穩定版本已更新到 14.16 以上，其高效的異步 I/O 模型、新的語法特性、良好的社區生態與全面的 npm 包管理平台，都是 Node.js 持續發展的有效保障[6]。與此同時，現有的基於 Node.js 的 Web 服務端框架數量較少，尚未存在一款具有壟斷地位的Node.js 服務端框架。種種跡象都表明研究並實現一款基於 Node.js 的 Web 服務端框架是可行的。
.........................
1.2 研究現狀
近年來，尤其是網際網路進入到以前後端分離為主導的開發模式後，Node.js 在服務端開發領域的重要性得到了重視，誕生了幾款較為流行的 Web 服務端框架。
Express[7]和 Koa 是兩款基於 Node.js 的 Web 基礎框架。這兩款框架採用中間件的開發模式，框架本身只提供少量的功能用於請求處理，對請求的處理主要通過第三方中間件來實現，具有對請求處理流程的切分能力強、可擴展性高的特點。在這種開發模式下，開發者通過在請求處理流程中的任意位置添加中間件來滿足開發需求。由於中間件模式帶來的高靈活性，使 Express 和 Koa 有著較好的社區生態和插件生態。在實際開發過程中，第三方中間件具有各自的代碼邏輯，並且在使用時需要手動引入和創建，會導致項目重構和維護上的困難。因此，這兩款框架更多是作為其他 Web 服務端框架的底層框架。
Nest 和 Hapi 是目前兩款較為流行的 Web 服務端的開發框架。Nest 是在 Express 的基礎上進行二次開發的框架。Nest 採用了 MVC[8]的結構設計，將功能劃分為控制層（Controller）、提供層（Provider）和模型層（Model）。其中 Controller 負責以注入的方式傳入請求，並返回對客戶端的響應；Provider 負責提供請求的各項處理；Model負責將對應的 Controller 和 Provider 聯繫起來。這種分層結構使得 Nest 具有較強的功能解耦能力。
Hapi 在早期也是基於 Express 進行的開發，但是在後來的疊代中將 Express 從框架底層移除，但是在結構上仍然保留了 Express 基於擴展的設計思想。Hapi 採用基於插件的擴展結構，與基於中間件的擴展結構的主要區別在於 Hapi 中一個插件代表一個獨立服務，而 Express 中一個中間件代表一個函數。Hapi 提供了認證、日誌、路由等功能模塊用於請求的識別、記錄與轉發，同時結合 joi、vision 等插件完成請求解析與視圖管理。但 Hapi 的插件系統兼容性較差，只能使用框架官方指定的插件，不兼容第三方插件，並且由於 Hapi 的中文文檔和社區較少，對國內開發者來說學習起來有一定的門檻。
.....................
2 基於 Node.js 的服務端框架相關技術
2.1 Node.js 相關技術
2.1.1 模塊化機制
從編程的角度來說，模塊是指能夠提供一定功能或數據的程序語句集合，並且具備和外部聯繫的接口。Node.js 採用 CommonJS 標準實現了模塊化機制[9]，每個文件都是一個模塊，並且有自己的作用域，在作用域中定義的一切內容都是獨有的。在CommonJS 模塊規範下，項目在首次運行時會依照模塊在引用文件中出現的順序依次加載所有模塊，並且將運行結果進行緩存，後續多次調用模塊時直接從緩存中獲取而不會再次執行該模塊。CommonJS 規範中包含三個部分：模塊定義（exports）、標識（module）和引用（require）。
其中，模塊定義是用來暴露出當前模塊所提供的方法和屬性。使用 module.exports來導出某個模塊對象的基本語法如下所示：
模塊化機制
......................
2.2 Web 緩存技術
Web 緩存技術是一種在 Web 的關鍵節點上存儲頻繁訪問的數據的技術。它將已訪問的資源存儲在 Web 應用中的某些位置，資源被再次訪問時，不需要請求服務端，而是直接返回緩存中的資源。根據 Web 應用中緩存的存儲位置，可以將其分為客戶端緩存[19]與服務端緩存[20]。
2.2.1 客戶端緩存
客戶端緩存是指資源的接收方（通常為瀏覽器）建立一個緩存區，對 Web 請求返回的資源進行緩存。客戶端與服務端通過應答的模式進行通信。客戶端發起 HTTP 請求，服務端處理和響應 HTTP 請求。在這個過程中，客戶端緩存主要是通過 HTTP 緩存機制[21]來實現的，通過在 HTTP 協議頭中定義不同的緩存規則來決定客戶端是直接使用緩存中的副本還是要向服務端重新請求更新的資源。
客戶端在沒有緩存的時候向服務端發起請求，服務端會將資源和緩存規則一併返回，客戶端根據響應頭中不同的緩存標識信息來確定使用何種緩存規則。根據在獲取資源時是否需要重新向伺服器發起請求可以將其分為兩大類：強制緩存和協商緩存[22]。 在強制緩存規則下，如果緩存生效則直接使用緩存，無需向服務端重新發起請求。強制緩存主要有以下兩個規則參數：
1）Expires：用來指定資源過期的時間。Expires=max-age+請求發出的時間。當請求的資源尚未過期時，可以直接從客戶端緩存中取出資源。
2）Cache-Control：用來對客戶端緩存方式進行控制。Cache-Control 在請求頭或者響應頭中設置，可以組合使用多種指令來對客戶端緩存方式進行控制。Cache-Control 的指令如表 2-2 所示，以下為每組指令的說明：
（1）no-store 和 no-cache：決定緩存方式。no-store 表示資源不會被緩存；no-cache表示不允許客戶端緩存資源與服務端資源不一致，即每次請求時需要向服務端確認資源是否發生變更。
（2）public 和 private：決定緩存位置。public 表示資源可以在客戶端和服務端緩存；private 表示資源只能在服務端緩存。
（3）max-age 和 must-revalidation：決定緩存過期時間。max-age 表示緩存資源的最大可用時間，當緩存過期後，向服務端驗證資源有效後仍可使用原來的資源；must-revalidation 表示緩存過期後，客戶端必須向服務端重新請求資源
..........................
3 基於高斯混合模型的緩存替換算法.................30
3.1 高斯混合模型概述..................30
3.2 算法執行流程.................30
4 基於 Node.js 的 Web 服務端框架設計.................40
4.1 需求分析.................40
4.1.1 功能性需求.................40
4.1.2 非功能性需求.................40
5 基於 Node.js 的 Web 服務端框架實現.................50
5.1 請求管理模塊實現.................50
5.1.1 框架初始化加載.................50
5.1.2 請求處理與調度.................50
6 基於 Node.js 的 Web 服務端框架測試
6.1 測試環境
框架測試過程中需要 2 台計算機用於搭建 Node.js 伺服器和客戶端，通過將 Node.js伺服器以及客戶端電腦部署在同一區域網中，通過 100Mbps 乙太網通信，測試使用的軟硬體環境配置如表 6-1 所示。
表 6-1 測試環境配置
本次測試所需的工具介紹如下：
Chai 斷言庫：Chai.js 是一款支持測試驅動開發（Test-Driven Development，TDD）[44]和行為驅動開發（Behavior-Driven Development，BDD）[45]的斷言庫。其擁有 3 個斷言庫，包括 Expect 斷言庫、Should 斷言庫和 Assert 斷言庫，可以用於與 JavaScript 類型的測試框架進行組合使用。
Mocha：Mocha 是基於 JavaScript 的一款自動化測試框架，能有效的對異步方法進行測試，在 Node.js 的控制端和客戶端中都可以運行。本文採用 Chai 的 Expect 斷言庫與 Mocha 進行組合使用，在 Node.js 環境中編寫的功能單點測試用例，捕獲異常輸出的測試用例。
Jmeter：Apache Jmeter 是一款由 Apache 組織開發的壓力測試工具，用於對軟體做壓力測試[46]。在設計階段，Jmeter 能夠充當 HTTP 代理來記錄 Web 請求，隨後通過設置請求樣本的發送數量和重複次數來產生請求流量。
......................
7 總結與展望
7.1 論文總結
隨著 Node.js 的發展，由於其異步 I/O 的特性，在高並發的 I/O 場景下實現了比傳統服務端開發語言更為高效的處理效率。本文通過對 Node.js 相關技術進行調研和分析，設計並實現了一款基於 Node.js 的 Web 服務端框架。該框架通過對請求處理和響應的具體流程進行劃分，為開發者提供了更為高效的請求處理能力。本文主要工作如下：
1）通過對 Node.js 的相關技術進行分析，在此基礎上結合實際開發場景，完成了框架的需求分析和結構設計。以模塊化機制為基礎，設計並實現了框架的核心模塊，包括請求管理、參數處理、過濾、路由、會話管理和靜態資源管理等功能模塊，為開發者提供請求處理與響應的各個環節的豐富基礎功能。
2）通過對主流 Node.js 的 Web 服務端框架進行分析，針對主流框架存在的不足，結合框架的功能模塊給出了相應的優化方案。在功能屬性配置方面，框架採用基於配置文件的功能屬性定義方式，將功能屬性的配置信息從業務代碼中分離，提高代碼的可維護性。在框架初始化時，通過對配置文件進行解析，實現功能模塊的自定義加載。在請求調度方面，基於緩存隊列設計了延遲調度方案。框架使用緩存隊列存儲請求，同時對 CPU 進行監控，在高並發場景下通過延遲調度完成請求的錯峰處理，降低了請求錯誤率。在靜態資源加載方面，框架使用客戶端與服務端緩存相結合的雙緩存方案對靜態資源進行緩存，減少請求次數和文件 I/O 操作，提高了靜態資源加載效率。
3）在緩存替換方面，本文提出了一種基於高斯混合模型的緩存替換算法。使用滑動窗口進行特徵提取和計算，通過高斯混合模型對窗口時間內會被再次訪問的資源進行預測，並根據預測結果進行緩存替換，實現了較高的緩存命中率和位元組命中率。
4）對框架進行全面測試，包括自動化功能測試、靜態資源加載耗時測試、請求錯誤率測試以及請求處理效率測試。從四個方面驗證了框架的可用性和良好的性能，也進一步驗證框架設計的合理性。
參考文獻（略）
1 緒論
1.1 研究背景及意義
隨著網際網路的發展以及 Web 應用數量的快速增加，人們日常生活中方方面面的需求，包括網上銀行、網絡直播、在線醫療、協同辦公等都可以通過 Web 應用實現。而服務端是 Web 應用開發的基石，是 Web 應用質量和性能的重要保障。隨著用戶需求的增長，服務端開發的工作量和複雜度也在日漸上升。在此背景下，使用服務端框架進行開發成為提高 Web 應用開發效率以及改善用戶體驗最為有效的解決方案。
Node.js[1]作為一項誕生於 2009 年的新興技術，於 2011 年正式發布 Windows 版本。由於其高效的 Chrome V8 引擎[2]和異步 I/O 的特性，使得基於 Node.js 開發的 Web 應用程式具有高性能與可擴展的特性[3]。使用 Node.js 進行 Web 應用開發的優勢主要有以下幾個方面：
1）與傳統服務端開發語言相比，Node.js 的異步 I/O 模型對大部分 I/O 請求的響應更快[4]。
2）Node.js 將數據解析與前端分離，實現了視圖層（User Interface，UI）與數據模型的解耦。
3）Node.js 為前端開發語言 JavaScript 提供了服務端的執行環境，實現了前後端開發語言的統一，大大降低了應用的開發成本[5]。
與 Node.js 的高速發展相比，Node.js 在服務端開發領域的成熟度與傳統服務端開發語言相比仍有較大差距，這給 Node.js 在服務端的發展帶來了機遇與挑戰。目前，Node.js 的穩定版本已更新到 14.16 以上，其高效的異步 I/O 模型、新的語法特性、良好的社區生態與全面的 npm 包管理平台，都是 Node.js 持續發展的有效保障[6]。與此同時，現有的基於 Node.js 的 Web 服務端框架數量較少，尚未存在一款具有壟斷地位的Node.js 服務端框架。種種跡象都表明研究並實現一款基於 Node.js 的 Web 服務端框架是可行的。
.........................
1.2 研究現狀
近年來，尤其是網際網路進入到以前後端分離為主導的開發模式後，Node.js 在服務端開發領域的重要性得到了重視，誕生了幾款較為流行的 Web 服務端框架。
Express[7]和 Koa 是兩款基於 Node.js 的 Web 基礎框架。這兩款框架採用中間件的開發模式，框架本身只提供少量的功能用於請求處理，對請求的處理主要通過第三方中間件來實現，具有對請求處理流程的切分能力強、可擴展性高的特點。在這種開發模式下，開發者通過在請求處理流程中的任意位置添加中間件來滿足開發需求。由於中間件模式帶來的高靈活性，使 Express 和 Koa 有著較好的社區生態和插件生態。在實際開發過程中，第三方中間件具有各自的代碼邏輯，並且在使用時需要手動引入和創建，會導致項目重構和維護上的困難。因此，這兩款框架更多是作為其他 Web 服務端框架的底層框架。
Nest 和 Hapi 是目前兩款較為流行的 Web 服務端的開發框架。Nest 是在 Express 的基礎上進行二次開發的框架。Nest 採用了 MVC[8]的結構設計，將功能劃分為控制層（Controller）、提供層（Provider）和模型層（Model）。其中 Controller 負責以注入的方式傳入請求，並返回對客戶端的響應；Provider 負責提供請求的各項處理；Model負責將對應的 Controller 和 Provider 聯繫起來。這種分層結構使得 Nest 具有較強的功能解耦能力。
Hapi 在早期也是基於 Express 進行的開發，但是在後來的疊代中將 Express 從框架底層移除，但是在結構上仍然保留了 Express 基於擴展的設計思想。Hapi 採用基於插件的擴展結構，與基於中間件的擴展結構的主要區別在於 Hapi 中一個插件代表一個獨立服務，而 Express 中一個中間件代表一個函數。Hapi 提供了認證、日誌、路由等功能模塊用於請求的識別、記錄與轉發，同時結合 joi、vision 等插件完成請求解析與視圖管理。但 Hapi 的插件系統兼容性較差，只能使用框架官方指定的插件，不兼容第三方插件，並且由於 Hapi 的中文文檔和社區較少，對國內開發者來說學習起來有一定的門檻。
.....................
2 基於 Node.js 的服務端框架相關技術
2.1 Node.js 相關技術
2.1.1 模塊化機制
從編程的角度來說，模塊是指能夠提供一定功能或數據的程序語句集合，並且具備和外部聯繫的接口。Node.js 採用 CommonJS 標準實現了模塊化機制[9]，每個文件都是一個模塊，並且有自己的作用域，在作用域中定義的一切內容都是獨有的。在CommonJS 模塊規範下，項目在首次運行時會依照模塊在引用文件中出現的順序依次加載所有模塊，並且將運行結果進行緩存，後續多次調用模塊時直接從緩存中獲取而不會再次執行該模塊。CommonJS 規範中包含三個部分：模塊定義（exports）、標識（module）和引用（require）。
其中，模塊定義是用來暴露出當前模塊所提供的方法和屬性。使用 module.exports來導出某個模塊對象的基本語法如下所示：
模塊化機制
......................
2.2 Web 緩存技術
Web 緩存技術是一種在 Web 的關鍵節點上存儲頻繁訪問的數據的技術。它將已訪問的資源存儲在 Web 應用中的某些位置，資源被再次訪問時，不需要請求服務端，而是直接返回緩存中的資源。根據 Web 應用中緩存的存儲位置，可以將其分為客戶端緩存[19]與服務端緩存[20]。
2.2.1 客戶端緩存
客戶端緩存是指資源的接收方（通常為瀏覽器）建立一個緩存區，對 Web 請求返回的資源進行緩存。客戶端與服務端通過應答的模式進行通信。客戶端發起 HTTP 請求，服務端處理和響應 HTTP 請求。在這個過程中，客戶端緩存主要是通過 HTTP 緩存機制[21]來實現的，通過在 HTTP 協議頭中定義不同的緩存規則來決定客戶端是直接使用緩存中的副本還是要向服務端重新請求更新的資源。
客戶端在沒有緩存的時候向服務端發起請求，服務端會將資源和緩存規則一併返回，客戶端根據響應頭中不同的緩存標識信息來確定使用何種緩存規則。根據在獲取資源時是否需要重新向伺服器發起請求可以將其分為兩大類：強制緩存和協商緩存[22]。 在強制緩存規則下，如果緩存生效則直接使用緩存，無需向服務端重新發起請求。強制緩存主要有以下兩個規則參數：
1）Expires：用來指定資源過期的時間。Expires=max-age+請求發出的時間。當請求的資源尚未過期時，可以直接從客戶端緩存中取出資源。
2）Cache-Control：用來對客戶端緩存方式進行控制。Cache-Control 在請求頭或者響應頭中設置，可以組合使用多種指令來對客戶端緩存方式進行控制。Cache-Control 的指令如表 2-2 所示，以下為每組指令的說明：
（1）no-store 和 no-cache：決定緩存方式。no-store 表示資源不會被緩存；no-cache表示不允許客戶端緩存資源與服務端資源不一致，即每次請求時需要向服務端確認資源是否發生變更。
（2）public 和 private：決定緩存位置。public 表示資源可以在客戶端和服務端緩存；private 表示資源只能在服務端緩存。
（3）max-age 和 must-revalidation：決定緩存過期時間。max-age 表示緩存資源的最大可用時間，當緩存過期後，向服務端驗證資源有效後仍可使用原來的資源；must-revalidation 表示緩存過期後，客戶端必須向服務端重新請求資源
..........................
3 基於高斯混合模型的緩存替換算法.................30
3.1 高斯混合模型概述..................30
3.2 算法執行流程.................30
4 基於 Node.js 的 Web 服務端框架設計.................40
4.1 需求分析.................40
4.1.1 功能性需求.................40
4.1.2 非功能性需求.................40
5 基於 Node.js 的 Web 服務端框架實現.................50
5.1 請求管理模塊實現.................50
5.1.1 框架初始化加載.................50
5.1.2 請求處理與調度.................50
6 基於 Node.js 的 Web 服務端框架測試
6.1 測試環境
框架測試過程中需要 2 台計算機用於搭建 Node.js 伺服器和客戶端，通過將 Node.js伺服器以及客戶端電腦部署在同一區域網中，通過 100Mbps 乙太網通信，測試使用的軟硬體環境配置如表 6-1 所示。
表 6-1 測試環境配置
本次測試所需的工具介紹如下：
Chai 斷言庫：Chai.js 是一款支持測試驅動開發（Test-Driven Development，TDD）[44]和行為驅動開發（Behavior-Driven Development，BDD）[45]的斷言庫。其擁有 3 個斷言庫，包括 Expect 斷言庫、Should 斷言庫和 Assert 斷言庫，可以用於與 JavaScript 類型的測試框架進行組合使用。
Mocha：Mocha 是基於 JavaScript 的一款自動化測試框架，能有效的對異步方法進行測試，在 Node.js 的控制端和客戶端中都可以運行。本文採用 Chai 的 Expect 斷言庫與 Mocha 進行組合使用，在 Node.js 環境中編寫的功能單點測試用例，捕獲異常輸出的測試用例。
Jmeter：Apache Jmeter 是一款由 Apache 組織開發的壓力測試工具，用於對軟體做壓力測試[46]。在設計階段，Jmeter 能夠充當 HTTP 代理來記錄 Web 請求，隨後通過設置請求樣本的發送數量和重複次數來產生請求流量。
......................
7 總結與展望
7.1 論文總結
隨著 Node.js 的發展，由於其異步 I/O 的特性，在高並發的 I/O 場景下實現了比傳統服務端開發語言更為高效的處理效率。本文通過對 Node.js 相關技術進行調研和分析，設計並實現了一款基於 Node.js 的 Web 服務端框架。該框架通過對請求處理和響應的具體流程進行劃分，為開發者提供了更為高效的請求處理能力。本文主要工作如下：
1）通過對 Node.js 的相關技術進行分析，在此基礎上結合實際開發場景，完成了框架的需求分析和結構設計。以模塊化機制為基礎，設計並實現了框架的核心模塊，包括請求管理、參數處理、過濾、路由、會話管理和靜態資源管理等功能模塊，為開發者提供請求處理與響應的各個環節的豐富基礎功能。
2）通過對主流 Node.js 的 Web 服務端框架進行分析，針對主流框架存在的不足，結合框架的功能模塊給出了相應的優化方案。在功能屬性配置方面，框架採用基於配置文件的功能屬性定義方式，將功能屬性的配置信息從業務代碼中分離，提高代碼的可維護性。在框架初始化時，通過對配置文件進行解析，實現功能模塊的自定義加載。在請求調度方面，基於緩存隊列設計了延遲調度方案。框架使用緩存隊列存儲請求，同時對 CPU 進行監控，在高並發場景下通過延遲調度完成請求的錯峰處理，降低了請求錯誤率。在靜態資源加載方面，框架使用客戶端與服務端緩存相結合的雙緩存方案對靜態資源進行緩存，減少請求次數和文件 I/O 操作，提高了靜態資源加載效率。
3）在緩存替換方面，本文提出了一種基於高斯混合模型的緩存替換算法。使用滑動窗口進行特徵提取和計算，通過高斯混合模型對窗口時間內會被再次訪問的資源進行預測，並根據預測結果進行緩存替換，實現了較高的緩存命中率和位元組命中率。
4）對框架進行全面測試，包括自動化功能測試、靜態資源加載耗時測試、請求錯誤率測試以及請求處理效率測試。從四個方面驗證了框架的可用性和良好的性能，也進一步驗證框架設計的合理性。
參考文獻（略）
收藏