NodeJS優缺點及適用場景討論

概述：NodeJS宣稱其目標是“旨在提供一種簡單的構建可伸縮網路程式的方法”，那麼它的出現是為了解決什麼問題呢，它有什麼優缺點以及它適用於什麼場景呢？

本文就個人使用經驗對這些問題進行探討。

一. NodeJS的特點

我們先來看看NodeJS官網上的介紹：

Node.js is a platform built on Chrome’s JavaScript runtime for easily building fast, scalable network applications. Node.js uses an event-driven, non-blocking I/O model that makes it lightweight and efficient, perfect for data-intensive real-time applications that run across distributed devices.

其特點為：
1. 它是一個Javascript執行環境

2. 依賴於Chrome V8引擎進行程式碼解釋

3. 事件驅動

4. 非阻塞I/O

5. 輕量、可伸縮，適於實時資料互動應用

6. 單程式，單執行緒

二. NodeJS帶來的對系統瓶頸的解決方案

它的出現確實能為我們解決現實當中系統瓶頸提供了新的思路和方案，下面我們看看它能解決什麼問題。

1. 併發連線

舉個例子，想象一個場景，我們在銀行排隊辦理業務，我們看看下面兩個模型。

（1）系統執行緒模型：

這種模型的問題顯而易見，服務端只有一個執行緒，併發請求（使用者）到達只能處理一個，其餘的要先等待，這就是阻塞，正在享受服務的請求阻塞後面的請求了。

（2）多執行緒、執行緒池模型：

這個模型已經比上一個有所進步，它調節服務端執行緒的數量來提高對併發請求的接收和響應，但併發量高的時候，請求仍然需要等待，它有個更嚴重的問題。到程式碼層面上來講，我們看看客戶端請求與服務端通訊的過程：

服務端與客戶端每建立一個連線，都要為這個連線分配一套配套的資源，主要體現為系統記憶體資源，以PHP為例，維護一個連線可能需要20M的記憶體。這就是為什麼一般併發量一大，就需要多開伺服器。

那麼NodeJS是怎麼解決這個問題的呢？我們來看另外一個模型，想象一下我們在快餐店點餐吃飯的場景。

（3）非同步、事件驅動模型

我們同樣是要發起請求，等待伺服器端響應；但是與銀行例子不同的是，這次我們點完餐後拿到了一個號碼，拿到號碼，我們往往會在位置上等待，而在我們後面的請求會繼續得到處理，同樣是拿了一個號碼然後到一旁等待，接待員能一直進行處理。

等到飯菜做號了，會喊號碼，我們拿到了自己的飯菜，進行後續的處理（吃飯）。這個喊號碼的動作在NodeJS中叫做回撥（Callback），能在事件（燒菜，I/O）處理完成後繼續執行後面的邏輯（吃飯），這體現了NodeJS的顯著特點，非同步機制、事件驅動整個過程沒有阻塞新使用者的連線（點餐），也不需要維護已經點餐的使用者與廚師的連線。

基於這樣的機制，理論上陸續有使用者請求連線，NodeJS都可以進行響應，因此NodeJS能支援比Java、PHP程式更高的併發量雖然維護事件佇列也需要成本，再由於NodeJS是單執行緒，事件佇列越長，得到響應的時間就越長，併發量上去還是會力不從心。

總結一下NodeJS是怎麼解決併發連線這個問題的：更改連線到伺服器的方式，每個連線發射（emit）一個在NodeJS引擎程式中執行的事件（Event），放進事件佇列當中，而不是為每個連線生成一個新的OS執行緒（併為其分配一些配套記憶體）。

2. I/O阻塞

NodeJS解決的另外一個問題是I/O阻塞，看看這樣的業務場景：需要從多個資料來源拉取資料，然後進行處理。

（1）序列獲取資料，這是我們一般的解決方案，以PHP為例

假如獲取profile和timeline操作各需要1S，那麼序列獲取就需要2S。

（2）NodeJS非阻塞I/O，發射/監聽事件來控制執行過程

NodeJS遇到I/O事件會建立一個執行緒去執行，然後主執行緒會繼續往下執行的，因此，拿profile的動作觸發一個I/O事件，馬上就會執行拿timeline的動作，兩個動作並行執行，假如各需要1S，那麼總的時間也就是1S。它們的I/O操作執行完成後，發射一個事件，profile和timeline，事件代理接收後繼續往下執行後面的邏輯，這就是NodeJS非阻塞I/O的特點。

總結一下：Java、PHP也有辦法實現並行請求（子執行緒），但NodeJS通過回撥函式（Callback）和非同步機制會做得很自然。

三. NodeJS的優缺點

優點：1. 高併發（最重要的優點）

2. 適合I/O密集型應用

缺點：1. 不適合CPU密集型應用；CPU密集型應用給Node帶來的挑戰主要是：由於JavaScript單執行緒的原因，如果有長時間執行的計算（比如大迴圈），將會導致CPU時間片不能釋放，使得後續I/O無法發起；

解決方案：分解大型運算任務為多個小任務，使得運算能夠適時釋放，不阻塞I/O呼叫的發起；

2. 只支援單核CPU，不能充分利用CPU

3. 可靠性低，一旦程式碼某個環節崩潰，整個系統都崩潰

原因：單程式，單執行緒

解決方案：（1）Nnigx反向代理，負載均衡，開多個程式，繫結多個埠；

（2）開多個程式監聽同一個埠，使用cluster模組；

4. 開源元件庫質量參差不齊，更新快，向下不相容

5. Debug不方便，錯誤沒有stack trace

四. 適合NodeJS的場景

1. RESTful API

這是NodeJS最理想的應用場景，可以處理數萬條連線，本身沒有太多的邏輯，只需要請求API，組織資料進行返回即可。它本質上只是從某個資料庫中查詢一些值並將它們組成一個響應。由於響應是少量文字，入站請求也是少量的文字，因此流量不高，一臺機器甚至也可以處理最繁忙的公司的API需求。

2. 統一Web應用的UI層

目前MVC的架構，在某種意義上來說，Web開發有兩個UI層，一個是在瀏覽器裡面我們最終看到的，另一個在server端，負責生成和拼接頁面。

不討論這種架構是好是壞，但是有另外一種實踐，面向服務的架構，更好的做前後端的依賴分離。如果所有的關鍵業務邏輯都封裝成REST呼叫，就意味著在上層只需要考慮如何用這些REST介面構建具體的應用。那些後端程式設計師們根本不操心具體資料是如何從一個頁面傳遞到另一個頁面的，他們也不用管使用者資料更新是通過Ajax非同步獲取的還是通過重新整理頁面。

3. 大量Ajax請求的應用

例如個性化應用，每個使用者看到的頁面都不一樣，快取失效，需要在頁面載入的時候發起Ajax請求，NodeJS能響應大量的併發請求。　　總而言之，NodeJS適合運用在高併發、I/O密集、少量業務邏輯的場景。

五. 結尾

其實NodeJS能實現幾乎一切的應用，我們考慮的點只是適不適合用它來做。

轉載請註明：程式猿 » NodeJS優缺點及適用場景討論