一. NodeJS的特點(diǎn)

我們先來(lái)看看NodeJS官網(wǎng)上的介紹：

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.

其特點(diǎn)為：

1. 它是一個(gè)Javascript運(yùn)行環(huán)境

2. 依賴于Chrome V8引擎進(jìn)行代碼解釋

3. 事件驅(qū)動(dòng)

4. 非阻塞I/O

5. 輕量、可伸縮，適于實(shí)時(shí)數(shù)據(jù)交互應(yīng)用

6. 單進(jìn)程，單線程

二. NodeJS帶來(lái)的對(duì)系統(tǒng)瓶頸的解決方案

它的出現(xiàn)確實(shí)能為我們解決現(xiàn)實(shí)當(dāng)中系統(tǒng)瓶頸提供了新的思路和方案，下面我們看看它能解決什么問(wèn)題。

1. 并發(fā)連接

舉個(gè)例子，想象一個(gè)場(chǎng)景，我們?cè)阢y行排隊(duì)辦理業(yè)務(wù)，我們看看下面兩個(gè)模型。

（1）系統(tǒng)線程模型：

系統(tǒng)線程模型

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

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

多線程、線程池模型

這個(gè)模型已經(jīng)比上一個(gè)有所進(jìn)步，它調(diào)節(jié)服務(wù)端線程的數(shù)量來(lái)提高對(duì)并發(fā)請(qǐng)求的接收和響應(yīng)，但并發(fā)量高的時(shí)候，請(qǐng)求仍然需要等待，它有個(gè)更嚴(yán)重的問(wèn)題。到代碼層面上來(lái)講，我們看看客戶端請(qǐng)求與服務(wù)端通訊的過(guò)程：

客戶端請(qǐng)求與服務(wù)端通訊的過(guò)程

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

那么NodeJS是怎么解決這個(gè)問(wèn)題的呢？我們來(lái)看另外一個(gè)模型，想象一下我們?cè)诳觳偷挈c(diǎn)餐吃飯的場(chǎng)景。

（3）異步、事件驅(qū)動(dòng)模型

異步、事件驅(qū)動(dòng)模型

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

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

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

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

2. I/O阻塞

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

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

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

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

非I/O阻塞-PHP為例

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

總結(jié)一下：Java、PHP也有辦法實(shí)現(xiàn)并行請(qǐng)求（子線程），但NodeJS通過(guò)回調(diào)函數(shù)（Callback）和異步機(jī)制會(huì)做得很自然。

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

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

2. 適合I/O密集型應(yīng)用

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

解決方案：分解大型運(yùn)算任務(wù)為多個(gè)小任務(wù)，使得運(yùn)算能夠適時(shí)釋放，不阻塞I/O調(diào)用的發(fā)起；

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

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

原因：?jiǎn)芜M(jìn)程，單線程

解決方案：（1）Nnigx反向代理，負(fù)載均衡，開(kāi)多個(gè)進(jìn)程，綁定多個(gè)端口；

（2）開(kāi)多個(gè)進(jìn)程監(jiān)聽(tīng)同一個(gè)端口，使用cluster模塊；

4. 開(kāi)源組件庫(kù)質(zhì)量參差不齊，更新快，向下不兼容

5. Debug不方便，錯(cuò)誤沒(méi)有stack trace

四. 適合NodeJS的場(chǎng)景

1. RESTful API

這是NodeJS最理想的應(yīng)用場(chǎng)景，可以處理數(shù)萬(wàn)條連接，本身沒(méi)有太多的邏輯，只需要請(qǐng)求API，組織數(shù)據(jù)進(jìn)行返回即可。它本質(zhì)上只是從某個(gè)數(shù)據(jù)庫(kù)中查找一些值并將它們組成一個(gè)響應(yīng)。由于響應(yīng)是少量文本，入站請(qǐng)求也是少量的文本，因此流量不高，一臺(tái)機(jī)器甚至也可以處理最繁忙的公司的API需求。

2. 統(tǒng)一Web應(yīng)用的UI層

目前MVC的架構(gòu)，在某種意義上來(lái)說(shuō)，Web開(kāi)發(fā)有兩個(gè)UI層，一個(gè)是在瀏覽器里面我們最終看到的，另一個(gè)在server端，負(fù)責(zé)生成和拼接頁(yè)面。

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

3. 大量Ajax請(qǐng)求的應(yīng)用

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

五. 結(jié)尾

其實(shí)NodeJS能實(shí)現(xiàn)幾乎一切的應(yīng)用，我們考慮的點(diǎn)只是適不適合用它來(lái)做。

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