[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能實作幾乎一切的應用
我們考慮的點隻是适不适合用它來做
六. 參考文獻
[1] Node.js能建構支援并發和高負載的大型應用嗎?
[2] 了解Node.js事件驅動程式設計
[3] 是否不擅長CPU密集型業務
[4] 使用 Node.js 的優勢和劣勢都有哪些？有大公司用嗎？
[5] Node.js給前端帶來了什麼