一. 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運行環(huán)境

2. 依賴于Chrome V8引擎進行代碼解釋

3. 事件驅動

4. 非阻塞I/O

5. 輕量、可伸縮，適于實時數據交互應用

6. 單進程，單線程

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

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

1. 并發(fā)連接

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

（1）系統線程模型：

系統線程模型

這種模型的問題顯而易見，服務端只有一個線程，并發(fā)請求（用戶）到達只能處理一個，其余的要先等待，這就是阻塞，正在享受服務的請求阻塞后面的請求了。

（2）多線程、線程池模型：

多線程、線程池模型

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

客戶端請求與服務端通訊的過程

服務端與客戶端每建立一個連接，都要為這個連接分配一套配套的資源，主要體現為系統內存資源，以PHP為例，維護一個連接可能需要20M的內存。這就是為什么一般并發(fā)量一大，就需要多開服務器。

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

（3）異步、事件驅動模型

異步、事件驅動模型

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

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

基于這樣的機制，理論上陸續(xù)有用戶請求連接，NodeJS都可以進行響應，因此NodeJS能支持比Java、PHP程序更高的并發(fā)量雖然維護事件隊列也需要成本，再由于NodeJS是單線程，事件隊列越長，得到響應的時間就越長，并發(fā)量上去還是會力不從心。

總結一下NodeJS是怎么解決并發(fā)連接這個問題的：更改連接到服務器的方式，每個連接發(fā)射（emit）一個在NodeJS引擎進程中運行的事件（Event），放進事件隊列當中，而不是為每個連接生成一個新的OS線程（并為其分配一些配套內存）。

2. I/O阻塞

NodeJS解決的另外一個問題是I/O阻塞，看看這樣的業(yè)務場景：需要從多個數據源拉取數據，然后進行處理。

（1）串行獲取數據，這是我們一般的解決方案，以PHP為例I/O阻塞-PHP為例

假如獲取profile和timeline操作各需要1S，那么串行獲取就需要2S。

（2）NodeJS非阻塞I/O，發(fā)射/監(jiān)聽事件來控制執(zhí)行過程

非I/O阻塞-PHP為例

NodeJS遇到I/O事件會創(chuàng)建一個線程去執(zhí)行，然后主線程會繼續(xù)往下執(zhí)行的，因此，拿profile的動作觸發(fā)一個I/O事件，馬上就會執(zhí)行拿timeline的動作，兩個動作并行執(zhí)行，假如各需要1S，那么總的時間也就是1S。它們的I/O操作執(zhí)行完成后，發(fā)射一個事件，profile和timeline，事件代理接收后繼續(xù)往下執(zhí)行后面的邏輯，這就是NodeJS非阻塞I/O的特點。

總結一下：Java、PHP也有辦法實現并行請求（子線程），但NodeJS通過回調函數（Callback）和異步機制會做得很自然。

三. NodeJS的優(yōu)缺點

優(yōu)點：1. 高并發(fā)（最重要的優(yōu)點）

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

缺點：1. 不適合CPU密集型應用；CPU密集型應用給Node帶來的挑戰(zhàn)主要是：由于JavaScript單線程的原因，如果有長時間運行的計算（比如大循環(huán)），將會導致CPU時間片不能釋放，使得后續(xù)I/O無法發(fā)起；

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

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

3. 可靠性低，一旦代碼某個環(huán)節(jié)崩潰，整個系統都崩潰

原因：單進程，單線程

解決方案：（1）Nnigx反向代理，負載均衡，開多個進程，綁定多個端口；

（2）開多個進程監(jiān)聽同一個端口，使用cluster模塊；

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

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

四. 適合NodeJS的場景

1. RESTful API

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

2. 統一Web應用的UI層

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

不討論這種架構是好是壞，但是有另外一種實踐，面向服務的架構，更好的做前后端的依賴分離。如果所有的關鍵業(yè)務邏輯都封裝成REST調用，就意味著在上層只需要考慮如何用這些REST接口構建具體的應用。那些后端程序員們根本不操心具體數據是如何從一個頁面?zhèn)鬟f到另一個頁面的，他們也不用管用戶數據更新是通過Ajax異步獲取的還是通過刷新頁面。

3. 大量Ajax請求的應用

例如個性化應用，每個用戶看到的頁面都不一樣，緩存失效，需要在頁面加載的時候發(fā)起Ajax請求，NodeJS能響應大量的并發(fā)請求?！　】偠灾?，NodeJS適合運用在高并發(fā)、I/O密集、少量業(yè)務邏輯的場景。

五. 結尾

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

NodeJs的優(yōu)勢：現在的很多的服務器端的語言（PHP,JAVA,ASP.net）,有什么問題呢，現在的服務器端的語言在用戶訪問服務器時，為每個用戶鏈接創(chuàng)建了一個線程，但每個線程大約要耗費2M的內存，如果一個8G內存的服務器，也就能鏈接4000個左右的用戶，如果用戶的鏈接數較大，就必須增加服務器的數量，而且現在用戶的鏈接方式有很多（如app，網頁同時訪問），這就又涉及到服務器共享的問題，所以服務器怎么支持最大的同時鏈接用戶量就成了一個問題；NodeJS修改了客戶端到服務器端的鏈接方法，解決了這個問題，他不在為每個客戶端創(chuàng)建一個新的線程，而是為每個客戶端鏈接出發(fā)一個NodeJs內部進行處理的事件，所以NodeJS具備同時處理多達幾萬個用戶的客戶端鏈接的能力；NodeJS適合開發(fā)的應用程序：當應用程序需要處理大量并發(fā)的輸入/輸出，而在向客戶端發(fā)出響應之前，應用程序內部并不需要進行非常復雜的處理的時候，我們應該考慮使用NodeJs來進行應用程序的開發(fā)，例如：1、聊天服務器：如果聊天的人很多，用戶的與服務器之間的并發(fā)鏈接量很大，但是服務器端的數據處理并不復雜；2、綜合類服務網站和電子商務網站的服務器：在這類網站中的服務器端，往往可能每秒存內可以接受多達上千條的數據并且需要將這些數據寫入數據庫中，NodeJs可以通過其隊列機制將這些數據迅速寫入緩存區(qū)中，然后再通過每一個單獨的處理從緩存區(qū)中取出這些數據并將其寫入數據庫中，如果是其他的服務器（如Apache服務器或Tomcat服務器）的話，由于這些服務器采用的是阻塞型I/O機制，因此每條數據寫入到數據庫中都要等待一段時間（等上一條寫完，才能寫下一條），但是NodeJs使用的是非阻塞的I/O機制，因此可以實現這些數據到數據庫中的寫入，而不必再為每條數據的寫入而等待一段時間