深刻淺出Node.js學習筆記（十一）

產品化

1. 項目工程化

所謂的工程化，能夠理解爲項目的組織能力。體如今文件的

1.1 目錄結構

主要的兩類項目爲Web應用和模塊應用。普通的模塊應用遵循CommonJS的模塊和包規範。對於Web應用，組織方式各類各樣，可是隻要遵循單一原則便可。

1.2 構建工具

要想真正能用上源代碼，還須要必定的操做，操做包括合併靜態文件、壓縮文件大小、打包應用、編譯模塊。每次都手動完成這些操做，效率會比較低下。爲了節省資源，使用構建工具完成這些工做。

Node上的構建工具：

1. Makefile

   只能在*nix操做系統上有效；

2. Grunt

   能夠跨平臺；

1.3 編碼規範

編碼規範的實現方式：

1. 文檔式的約定；(依靠自覺)
2. 代碼提交時的強制檢查；(依靠工具)

1.4 代碼審查

代碼審查創建在具體的代碼提交過程當中。

對於使用GitHub或Gitlab開源工具搭建的代碼託管平臺，能夠利用git的分支特色，很好地實現代碼審查。

2. 部署流程

代碼在完成開發、審查、合併以後進入部署流程。

2.1 部署環境

在實際項目需求中，有兩點須要驗證，一是功能的正確性，二是與數據相關的檢查。

普通測試環境稱爲stage環境；

預發佈環境稱爲pre-release環境；

實際的生產環境稱爲product環境；

2.2 部署操做

就普通的實例代碼而言，一般直接在命令行執行node file.js以啓動應用。

對於長時間執行的服務進程而言，存在兩個問題：

1. 佔住一個命令行窗口；
2. 隨着窗口的退出會致使打開的進程一併退出；

爲了能讓進程持續執行，用nohup和&以不掛斷進程的方式執行：

$ nohup node app.js &
複製代碼

3. 性能

Node產品的性能與許多因素相關，對於Web應用而言，最直接有效的莫過於動靜分離、多進程架構、分佈式。

拆分原則：

• 作專注的事
• 讓擅長的工具作擅長的事情
• 讓模型簡化
• 將風險分離
• 緩存

3.1 動靜分離

在普通的Web應用中，Node儘管能夠經過中間件實現靜態文件服務，可是Node處理靜態文件的能力不夠退出。將圖片、腳本、樣式表和多媒體等靜態文件都引導到專業的靜態文件服務器上，讓Node只處理動態請求便可。這個過程能夠用Nginx或者專業的CDN來處理。

將動態請求和靜態請求分離後，服務器能夠專一於動態服務方面，專業的CDN會將靜態文件與用戶儘量靠近，同時可以有更精確和高效的緩存機制。靜態文件請求分離後，對靜態請求使用不一樣的域名或多個域名還能消除掉沒必要要的Cookie傳輸和瀏覽器對下載線程數的限制。

3.2 啓用緩存

提高性能的兩個途徑：

1. 提高服務的速度；
2. 避免沒必要要的計算；

前者提高的性能在海量流量面前終有瓶頸，但後者卻可以在訪問量越大時收益越多。避免沒必要要的計算，應用場景最多的就是緩存。

Redis和Memcached幾乎是Web應用的標準配置。

若是你的產品須要應對巨大的流量，啓動緩存並應用好它，是系統性能瓶頸的關鍵。

3.3 多進程架構

經過多進程架構，不只能夠充分利用多核CPU，更是能夠創建機制讓Node進程更加健壯，以保障Web應用持續服務。

3.4 讀寫分離

針對數據庫而言，讀取的速度遠遠高於寫入的速度。兒某些數據庫在寫入時爲了保證數據一致性，會進行鎖表的操做，這同時會影響到讀取的速度。某些系統爲了提高性能，一般會進行數據庫的讀寫分離，將數據進行主從設計，這樣讀數據再也不受到寫入的影響，下降了性能的影響。

4. 日誌

在健全的系統中，完善的日誌最可以還原問題現場。經過記錄日誌來定位問題是一種成本較小的方式。

4.1 訪問日誌

訪問日誌通常用來記錄每一個客戶端應用的訪問。在Web應用中，主要記錄HTTP請求中的關鍵數據。通常的Web服務器都實現了記錄訪問日誌的功能。只要簡單的配置便可啓用。在用Nginx或Apache進行反向代理時，能夠利用這些已有的設施完成訪問日誌的記錄。

4.2 異常日誌

異常日誌一般用來記錄那些意外產生的異常錯誤。經過日誌的記錄，開發者能夠根據異常信息定位Bug出現的具體位置，以快速修復問題。

異常日誌的分級：

• console.log：普通日誌
• console.info：普通訊息
• console.warn：警告信息
• console.error：錯誤信息

4.3 日誌與數據庫

對日誌不瞭解的開發者會選擇將日誌寫入數據庫中。數據庫比日誌文件好的地方在於它是結構化數據，能夠直接編寫SQL語句進行分析，日誌文件則須要再加工以後才能分析。

4.4 分割日誌

線上業務可能訪問量巨大，產生的日誌也多是大量的，將產生的日誌按日期分割是個不錯的主意。

5. 監控報警

應用的監控主要分兩類：

1. 業務邏輯型的監控；
2. 硬件型的監控；

監控主要經過定時採樣來進行記錄。

5.1 監控

監控的主要目的是爲了將一些重要指標採樣記錄下來，一旦這些指標發生較大變化，能夠配合報警系統將問題反饋到負責人那。

1. 日誌監控
2. 響應時間
3. 進程監控
4. 磁盤監控
5. 內存監控
6. CPU佔用監控
7. CPU load監控
8. I/O負載
9. 網絡監控
10. 應用狀態監控
11. DNS監控

5.2 報警的實現

• 郵件報警
• 短信或電話報警

5.3 監控系統的穩定性

爲了保證應用的穩定性，引入了一個龐大的監控系統，監控系統自身的穩定性對應用也很是重要。

6. 穩定性

爲了更好的穩定性，典型的水平擴展方式就是多進程、多機器、對機房。

7.異構共存

站在技術的產品化的角度來看，選擇一門新技術應用在生產環境就得考慮與已有的系統或者服務可否異構共存。