Node.js的應用領域 NodeJS宣稱其目標是“旨在提供一種簡單的構建可伸縮網路程式的方法”； Node.js 是一個基於 Chrome V8 引擎的 JavaScript 運行環境。Node.js 使用了一個事件驅動、非阻塞式 I/O 的模型，使其輕量又高效。Node.js 的包管理器 npm ...
Node.js的應用領域
NodeJS宣稱其目標是“旨在提供一種簡單的構建可伸縮網路程式的方法”；
Node.js 是一個基於 Chrome V8 引擎的 JavaScript 運行環境。Node.js 使用了一個事件驅動、非阻塞式 I/O 的模型，使其輕量又高效。Node.js 的包管理器 npm，是全球最大的開源庫生態系統。
重點在於 事件驅動 以及 非阻塞I/O模型
事件驅動編程（Evnet-driven programming）
是一種編程風格，由事件來決定程式的執行流程，事件由事件處理器（event handler）或事件回調（event callback）來處理，事件回調是當某個特定事件發生時被調用的函數，比如資料庫返回了查詢結果或者用戶單擊了一個按鈕。
非阻塞I/O模型
在操作系統中，程式運行的空間分為內核空間和用戶空間。我們常常提起的非同步I/O，其實質是用戶空間中的程式不用依賴內核空間中的I/O操作實際完成，即可進行後續任務。
與NodeJs非阻塞模型相對應的還有系統線程模型、多線程/線程池模型，舉個慄子，想象一個場景，我們在銀行排隊辦理業務，我們看看下麵兩個模型。
系統線程模型：
這種模型的問題顯而易見，服務端只有一個線程，併發請求（用戶）到達只能處理一個，其餘的要先等待，這就是阻塞，正在享受服務的請求阻塞後面的請求了。
多線程/線程池模型：
這個模型已經比上一個有所進步，它調節服務端線程的數量來提高對併發請求的接收和響應，但併發量高的時候，請求仍然需要等待，它有個更嚴重的問題。到代碼層面上來講，我們看看客戶端請求與服務端通訊的過程:
服務端與客戶端每建立一個連接，都要為這個連接分配一套配套的資源，主要體現為系統記憶體資源，以PHP為例，維護一個連接可能需要20M的記憶體。這就是為什麼一般併發量一大，就需要多開伺服器。
那麼NodeJS是怎麼解決這個問題的呢？我們來看另外一個模型，想象一下我們在快餐店點餐吃飯的場景。
我們同樣是要發起請求，等待伺服器端響應；但是與銀行例子不同的是，這次我們點完餐後拿到了一個號碼，拿到號碼，我們往往會在位置上等待，而在我們後面的請求會繼續得到處理，同樣是拿了一個號碼然後到一旁等待，接待員能一直進行處理。
等到飯菜做號了，會喊號碼，我們拿到了自己的飯菜，進行後續的處理（吃飯）。這個喊號碼的動作在NodeJS中叫做回調（Callback），能在事件（燒菜，I/O）處理完成後繼續執行後面的邏輯（吃飯），這體現了NodeJS的顯著特點，非同步機制、事件驅動整個過程沒有阻塞新用戶的連接（點餐），也不需要維護已經點餐的用戶與廚師的連接。
基於這樣的機制，理論上陸續有用戶請求連接，NodeJS都可以進行響應，因此NodeJS能支持比Java、PHP程式更高的併發量雖然維護事件隊列也需要成本，再由於NodeJS是單線程，事件隊列越長，得到響應的時間就越長，併發量上去還是會力不從心。
總結一下NodeJS是怎麼解決併發連接這個問題的：更改連接到伺服器的方式，每個連接發射（emit）一個在NodeJS引擎進程中運行的事件（Event），放進事件隊列當中，而不是為每個連接生成一個新的OS線程（併為其分配一些配套記憶體）。
最後我們看一下NodeJs適合的應用場景：
RESTful API
統一Web應用的UI層
目前MVC的架構，在某種意義上來說，Web開發有兩個UI層，一個是在瀏覽器裡面我們最終看到的，另一個在server端，負責生成和拼接頁面。不討論這種架構是好是壞，但是有另外一種實踐，面向服務的架構，更好的做前後端的依賴分離。如果所有的關鍵業務邏輯都封裝成REST調用，就意味著在上層只需要考慮如何用這些REST介面構建具體的應用。那些後端程式員們根本不操心具體數據是如何從一個頁面傳遞到另一個頁面的，他們也不用管用戶數據更新是通過Ajax非同步獲取的還是通過刷新頁面。
- 大量Ajax請求的應用
例如個性化應用，每個用戶看到的頁面都不一樣，緩存失效，需要在頁面載入的時候發起Ajax請求，NodeJS能響應大量的併發請求。
總而言之，NodeJS適合運用在高併發、I/O密集、少量業務邏輯的場景。
Node.js 的缺點
大量使用匿名函數，使得拋出的異常不容易閱讀。
try/catch限於同步代碼，使得異常捕獲較為複雜。
單線程：可靠性。
不適合CPU密集型的場景。
回調的代碼習慣影響閱讀。
