實例說明爲何應使用 Node.js

JavaScript 高漲的人氣帶來了不少變化，以致於現在使用其進行網絡開發的形式也變得大相徑庭了。就如同在瀏覽器中同樣，如今咱們也能夠在服務器上運行 JavaScript ，從前端跨越到後端，這樣巨大的反差讓人不可思議，由於僅僅在幾年前 Javascript 還如同 Flash 或者 Java applet 那樣嵌入網頁在沙箱環境中運行。

在深刻Node.js以前，你可能須要閱讀和了解使用跨棧式 JavaScript（JavaScript across the stack）帶來的好處，它統一了編程語言和數據格式（JSON），讓你能最佳地重用開發人員資源。因爲這更多的是關於 JavaScript 的特色，這裏就不過多討論它。但它確實是一個讓人在開發環節中使用 Node 的關鍵的優勢。

正如 維基百科 所說：「Node.js 是谷歌 V8 引擎、libuv平臺抽象層 以及主體使用 Javscript 編寫的核心庫三者集合的一個包裝外殼。」 除此以外，值得注意的是，Node.js 的做者瑞恩·達爾 (Ryan Dahl) 的目標是建立具備實時推送能力的網站。在 Node.js 中，他給了開發者一個使用事件驅動來實現異步開發的優秀解決方案。（注：V8是谷歌開發的，目前公認最快的 Javascript 解析引擎，libuv 是一個開源的、爲 Node 定製而生的跨平臺的異步 IO 庫。）

簡而言之：Node.js 在實時的 Web應用上採用了基於 WebSocket 的推送技術。這意味着什麼樣的革命性？Well，在通過了20多年的基於無狀態的請求-返機制的無狀態交互以後，咱們終於有了實時的，雙向鏈接的web應用，客戶端和服務器端均可以發起通訊，可以自由地交換數據。與此造成鮮明對比的是傳統的 web響應模式，客戶端老是主動發起通訊而服務端被動返回。此外，這些都是基於運行在標準80端口上的開放Web組件（HTML、CSS和JS）。

可能有人會說，咱們已經使用 Flash 和 Java Applet 的形式不少年了——但實際上，這些方式只是使用網絡將數據傳遞到客戶端上的沙箱環境。他們都是隔離運行的，並且常常操做到須要額外的權限之類的非標準端口。

憑藉其獨特的優點，Node.js的如今已經在許多著名公司的產品中起到了關鍵做用。

在這篇文章中，咱們不只將討論這些優點是如何實現的，並且也會討論爲何你使用 Node.js 來替代一些經典的Web應用程序模型。

Node.js 是如何工做的？

Node.js 的主要思路是：使用非阻塞的，事件驅動的 I/O 操做來保持在處理跨平臺 (across distributed devices) 數據密集型實時應用時的輕巧高效。這聽起來有點繞口。

它的真正含義是，Node.js 不是一個即將主導Web開發的世界的銀彈級的平臺。相反，它是一個知足特別需求的平臺。你確定不會但願使用 Node.js 去作 CPU密集型操做。事實上，使用它進行繁重的計算等於摒棄 Node 幾乎全部的優勢。Node 真正的亮點在於建設高性能，高擴展性的互聯網應用——由於它可以處理龐大的而且高吞吐量的併發鏈接。

它的工做原理是至關有趣的。傳統的網絡服務技術，是每一個新增一個鏈接（請求）便生成一個新的線程，這個新的線程會佔用系統內存，最終會佔掉全部的可用內存。而 Node.js 僅僅只運行在一個單線程中，使用非阻塞的異步 I/O 調用，全部鏈接都由該線程處理，在 libuv 的加分下，能夠容許其支持數萬併發鏈接（所有掛在該線程的事件循環中）。

作一個簡單的計算: 假設是普通的Web程序，新接入一個鏈接會佔用 2M 的內存，在有 8GB RAM的系統上運行時, 算上線程之間上下文切換的成本，併發鏈接的最大理論值則爲 4000 個。這是在傳統 Web服務端技術下的處理狀況。而 Node.js 則達到了約 1M 一個併發鏈接的拓展級別 (相關證實).

固然，在全部客戶端的請求共享單一線程時也會有問題, 這也是一個編寫 Node.js 應用的潛在缺陷. 首先, 大量的計算可能會使得 Node 的單線程暫時失去反應, 並致使全部的其餘客戶端的請求一直阻塞, 直到計算結束才恢復正常。 其次，開發人員須要很是當心，不要讓一個 Exception 阻塞核心的事件循環，由於這將致使 Node.js 實例的終止（實際上就是程序崩潰）。（ 筆者注：如 PHP 中某個頁面掛掉是不會影響網站運行的，可是 Nodejs 是一個線程一個線程來處理全部的連接，因此不管是計算卡了或者是被異常阻塞了均可能會影響到其餘全部的連接。解決方案在稍後討論。）

用來避免異常拋出時中斷進程的方法是將異常使用回調傳遞出去（而不是拋出他們，就像在其餘環境中同樣）。即便一些未處理的異常阻塞了程序，依舊有多種應對的解決方案，並且也有不少可用於監視 Node 進程來執行必要的崩潰後恢復工做的策略和工具（雖然你將沒法恢復用戶的 Session ），最多見的是使用 Forever 模塊，或者採用其餘的外部系統工具如 upstart and monit。

NPM: The Node Package Manager

當咱們討論 Node.js 的時候，一個絕對不該該忽略地方就是默認內置的模塊管理工具 —— NPM。 其靈感來源與 Ruby Gems（具備版本和依賴管理功能，能夠經過在線資料庫便捷安裝可重用的組件的管理工具）。

一個完整的公用模塊列表能夠在 NPM 的網站上找到，或者經過使用與 Node.js 一同安裝的 NPM CLI 工具放問到。該模塊的生態系統向全部人開放，任何人均可以發佈本身的模塊，全部的模塊均可以在 NPM 資料庫中找到。你能夠在 頁面找到 NPM 的一個簡要介紹（有點舊，但依舊能看）。

目前很是流行的一些 NPM 模塊有：

• express – Express.js,是一個簡潔而靈活的 node.js Web應用框架, 而且已是如今大多數 Node.js 應用的標準框架，你已經能夠在不少 Node.js 的書籍中看到它了。
• connect – Connect 是一個 Node.js 的 HTTP 服務拓展框架，提供一個高性能的「插件」集合，以中間件聞名，是 Express 的基礎部分之一。
• socket.io 和 sockjs – 目前服務端最流行的兩個 websocket 組件。
• Jade – 流行的模板引擎之一，而且是 Express.js 的默認模板引擎。其靈感來源於 HAML。
• mongo 和 mongojs – 封裝了 MongoDB 的的各類 API，不過筆者日常工做用的是 mongoose 也很推薦。
• redis – Redis 的客戶端函數庫.
• coffee-script – CoffeeScript 編譯器，容許開發者使用 Coffee 來編寫他們的 Node.js 程序。
• underscore (lodash, lazy) – 最流行的 JavaScript 工具庫 , 用於 Node.js 的封裝包，以及兩個採起略有不一樣的實現方法來得到更好性能的副本（counterparts）。
• forever – 多是用來確保 node 腳本持續運行的最流行的工具。

還有不少好的模塊，這裏就不一一列舉了（但願沒有冒犯到沒列舉的）。

Node.js 應該用在什麼地方

聊天

聊天是最典型的多用戶實時交互的應用。從 IRC 開始，有許多開源或者不開源的協議都運行在非標準端口上，而如今，使用 Node.js 則能夠解決這些問題——在標準的80端口運行 WebSockets。

聊天應用程序是最能體現 Node.js 優勢的例子：輕量級、高流量而且能良好的應對跨平臺設備上運行密集型數據（雖然計算能力低）。同時，聊天也是一個很是值得學習的用例，由於它很簡單，而且涵蓋了目前爲止一個典型的 Node.js 會用到的大部分解決方案。

讓咱們試着來描繪它如何工做。

在最簡單的狀況下，咱們佈置了一個聊天室在咱們的網站上，用戶能夠在上面發消息，固然是一對多的形式。例如，假設總共有三我的鏈接到咱們的網站上。

在服務端這邊， 咱們有一個使用 Express.js 搭建的簡單站點，該站點實現了兩件事 1) 處理路徑爲 ‘/’ 的GET請求時，下發包括一個留言板以及一個發送信息的 ‘發送’ 按鈕的頁面 2) 一個監聽客戶端發送新消息的 websockets 服務。

在客戶端這邊，咱們有一個 HTML 頁面，上面有個兩個 js 方法，一個是用於觸發事件的 「發送」 按鈕，這會把把輸入的消息經過 webscoket 發送，另外一個方法是用 webscoket 在客戶端上監聽服務端來的推送（例如，其餘用戶發送的消息）。

當有一個客戶端發送消息的時候，發生的事情是：

1. 瀏覽器上，點擊發送按鈕觸發了 js 函數，將輸入框中的文字經過 websocket 消息發送到服務器的 websocket 客戶端（頁面初始化加載的時候鏈接的）。
2. 服務端的 websocket 組件收到 消息，而後經過廣播方法轉發到其餘全部鏈接的客戶端。
3. 經過頁面上運行的 websocket 客戶端組件，全部的客戶端都能收到這條推送的新消息。接着 js 處理函數能夠把這個消息添加到文字框內。

這是一個最簡單的例子。若是要更好的解決方案，你可使用 Redis 數據庫作一個簡單的緩存。在一個更高級的解決方案中，你可能須要一個消息路由來專門處理消息隊列，而且須要一個更強健的發送機制，好比發送的時候覆蓋上暫時離線的用戶或者爲離線的註冊用戶存儲還沒有接收的消息等等。可是不論你作了怎麼樣的改進，Node.js 都將遵循一個基本原則：響應事件，處理多個併發鏈接，並保持流動性的用戶體驗。

對象數據庫接口（API ON TOP OF AN OBJECT DB）

儘管，Node.js 確實很是擅長實時交互的應用，同時它也十分適合經過對象數據庫（object DB）來查詢數據（如 MongoDB）。以 JSON 格式存儲的數據容許 Node.js 直接處理，不須要糾結數據轉換和匹配的問題。

舉個例子，若是你正在使用 Rails，你會將 JSON 數據轉成 二進制的 model，當數據再被 Backbone.js, Angular.js 或者 jQuery AJAX 之類的調用又要轉回 JSON。若是是 Nodejs 的話，你能夠經過一個 REST API 簡單的導出 JSON 對象以供客戶端使用。另外，從數據庫讀寫時候若是使用的是 MongoDB 的話，你也不用擔憂的 JSON 與任何數據之間的格式問題。總之，你能夠避免多元的數據轉換問題，不管是在客戶端、服務端仍是數據庫。

隊列輸入

若是你正在接收一個高量併發的數據，你的數據庫可能會成爲你處理的瓶頸。正如上面的描述，Node.js 能夠輕鬆的處理併發鏈接。 可是，因爲數據庫操做是一個阻塞的操做（在這種狀況下），這就是麻煩的地方。Node.js的解決方案是，在數據真正的寫入以前就認可客戶端的數據是真實的。

用這種方法，在高負載的時候系統繼續維持它的響應，這在當客戶端不須要嚴格確認一個數據是否成功的被寫入時特別有用。典型的例子包括：日誌記錄或者用戶跟蹤數據（user-tracking data）的記錄，這會被分批處理而且在稍後才使用；同時也包括最終一致性（so, 經常使用於 NoSQL）能夠接受，不須要當即反應的操做（例如 Facebook 上更新點讚的數目）。

數據經過某些緩存或者消息隊列的基礎組件（例如 RabbitMQ, ZeroMQ）進入隊列，而且經過一個獨立的數據庫批量寫入進程來一一消化，或者經過一個更高性能的計算密集型後端服務來進行處理。其餘的語言/框架也能夠實現類似的操做，但在相同的配置下是達不到 nodejs 的高吞吐量與高併發。

簡單的說：使用 Node，你能夠把數據庫操做扔到一邊並在稍後處理它們，假設他們成功了同樣繼續執行下去。（筆者注：在開發中一般的狀況一般是，種耗時的操做經過回調函數來異步處理，主線程繼續往下執行）

數據流

在較爲傳統的網絡平臺上，HTTP 的請求和響應更像是孤立的事件；然而事實上，他們都是數據流。這一觀察結果在 Nodejs 上能夠用來創建一些很酷的功能。由於數據通以流的形式接收，而咱們能夠在網站上在線處理正在上傳中的文件。這樣的話，就能夠實現實時的音頻和視頻編碼，以及在不一樣數據源之間進行代碼（代理見下一段）。

（筆者注：Node 有代替如 apache 這樣的 webserver 處理數據，因此開發者能夠直接收到客戶端一份一份上傳的數據，並實時處理。上面這段話聽起來有點抽象，不過各位能夠簡單的想象一下不須要開 YY 或者 QQ，打開網頁就能進行語音視頻的功能。）

代理

Node.js 能夠經過異步的方式處理大量的併發鏈接，因此很容易做爲服務端的代理來使用。這在與不一樣響應時間的不一樣服務之間進行代理，或者是收集來自多個來源的數據時尤爲有用。

舉個例子：考慮一個服務器端的應用程序和第三方資源進行通訊以更新自不一樣來源的數據，或者將服務端上的一些圖像和視頻資源存儲到第三方雲服務。

雖然專用代理服務器確實存在，可是若是你尚未專用的代理服務器，或者你須要一個本地開發的解決方案，那麼使用 Node 來作代理多是更好的選擇。關於這個解決方案，個人意思是指當你在開發的時候，你可使用Node.js的開發環境搭建一個服務來處理對資源和代理的請求，而在生產環境下，你可使用專用的代理服務（好比nginx，HAProxy等）來處理這些交互。

股票操盤手的儀表盤

讓咱們繼續討論應用程序這塊。實時網絡的解決方案能夠很輕鬆的實現證券交易軟件——用於跟蹤股票的價格，執行計算、作技術分析，同時生成報表。

使用一個實時的的基於網頁的解決方案，將會容許操盤手輕鬆的切換工做軟件以及工做地點。相信不久，咱們或許會在 佛羅里達州、伊維薩島又或者是巴厘島的海灘上看到他們。

應用監聽儀盤表

另外一種常見的用例中，使用 Node+Web+Socket 很是適合：跟蹤網站訪問者而且可視化實時它們之間的實時交互。 （若是你有興趣，能夠去看看 Hummingbird）

你可能須要採集用戶的實時狀態, 或者甚至當他們到達渠道中某個特定的點時, 打開一個交流頻道， 經過有針對性的互動介紹移動到下一個階段. （若是你感興趣的話，推薦你看看 CANDDi）

想象一下，若是你知道你的訪客的實時操做，並可以形象化地看到他們的交互，這將對你的業務帶來多大的提高。隨着實時的、雙向 socket 通訊的 Node.js ，如今你能夠作到了。

系統監控儀表

如今，讓咱們看看事情的基礎設施方面。想象一下，好比，但願爲其用戶提供服務監控頁面（例如，GitHub上的狀態頁）的 SaaS 運營商 。經過 Node.js 的事件循環，咱們能夠建立一個基於 Web 的功能強大的儀表板，以異步方式檢查服務狀態而且使用的 WebSockets 將數據推送到客戶端。

內部（公司內部）和公共服務的狀態均可以使用該項技術實現實時的上報。讓咱們把這一想法延伸的遠一點，試着想象一個電信運營商中網絡運營中心（NOC）的監控應用，雲/網絡/服務器運營商，或者一些金融機構，全都運行在這個由 Node.js 和 WebSocket 組成的應用上，而不是 Java 和/或 Java Applet。

注意：不要嘗試使用 Node 打造硬實時系統（即，響應時間要求一致的系統）。 Erlang是多是該類應用程序的更好的選擇。

什麼地方可使用 Node.js

服務端 WEB 應用

經過 Node.js 使用 Express.js 也能夠用來建立服務端上的典型的網頁應用。然而，雖然有可能，使用 Node.js 來進行請求+響應的形式來呈現 HTML 並非最典型的用例。有人同意也有人反對這一作法。這裏有一些見解以供參考:

優勢：

• 若是你不須要進行 CPU密集型計算，你能夠從頭至尾甚至是數據庫（好比 MongoDB）都使用 Javascript 來開發。這顯著地減輕了開發工序（包括成本）。
• 對於一個使用 Node.js 做爲服務端的單頁應用或者 websocket 應用，爬蟲能夠收到一個徹底 HTML 呈現的響應，這是更爲SEO友好的。

缺點：

• 任何CPU密集型的計算都將阻礙 Node.js 的反應，因此使用多線程的平臺是一個更好的方法。或者，您也能夠嘗試向外擴展的計算1。

• Node.js 使用關係型數據庫依舊十分痛苦（詳細見下方）。拜託了，若是你想執行關係型數據操做，請考慮別的環境：Rails， Django 甚至 ASP.NET MVC ...

• 1另外一種解決方案是，爲這些CPU密集型的計算創建一個高度可擴展的MQ支持的環境與後端處理，以保持 Node 做爲一個前臺專員來異步處理客戶端請求。*

Node.js 不該該在什麼地方使用

使用關係型數據庫的服務端 WEB 應用

對比 Node.js 上的 Express.js 和 Ruby on Rails，當你使用關係型數據庫的時候請絕不猶豫的選擇後者。

Node.js 的關係數據庫工具仍處於早期階段，目前尚未成熟到讓人可以愉快地使用它。而與此同時，Rails天生自帶了數據訪問組件，連同DB schema遷移的支持工具和一些Gems（一語雙關，一指這些如同珍寶的工具，二指ruby的gems程序包）。Rails和它的搭檔框架們擁有很是成熟且被證實了的活動記錄（Active Record）或數據映射（Data Mapper）的數據訪問層的實現，而這些是當你在使用純JavaScript來複制這些應用的時候會很是想要使用的東西。

不過，若是你真的傾向於所有使用 JS（而且作好可能抓狂的準備），那麼請繼續關注 Sequelize 和 Node ORM2 ，雖然這二者仍然不成熟的，但他們最終會迎頭遇上。

注：使用 Node 光是做爲前端而 Rails 作後端來鏈接關係型數據庫，這是徹底有可能也並很多見的。（筆者注：國外有種說法，PHP這一類程序員也能夠算做是前端）

繁重的服務端的計算和處理

當涉及到大量的計算，Node.js 就不是最佳的解決方案。你確定不但願使用 Node.js 創建一個斐波那契數的計算服務。通常狀況下，任何 CPU密集型操做 會削弱掉 Node經過事件驅動， 異步 I/O 模型等等帶來的在吞吐量上的優點，由於當線程被非異步的高計算量佔用時任何傳入的請求將被阻塞。

正如前面所說，Node.js 是單線程的，只使用一個單一的CPU核心。至於，涉及到服務器上多核併發處理，Node 的核心團隊已經使用 cluster 模塊的形式在這一方面作了一些工做 (參考：http://nodejs.org/api/cluster.html )。固然，您也能夠很容易的經過 nginx 的反向代理運行多個 Node.js 的服務器實例來避免單一線程阻塞的問題。

關於集羣(clustering) ，你應該將全部繁重的計算轉移到更合適的語言寫的後臺進程來處理，同時讓他們經過像 RabbitMQ 那樣經過消息隊列服務器來進行通訊。

即便你的後臺處理可能最初運行在同一臺服務器上時看不出什麼優勢，可是這樣的作法具備很是高的可擴展性的潛力。這些後臺處理服務能夠容易地分割出去，做爲單獨的 worker 服務器，而不須要配置入口 web服務器的負載。

固然，你也能夠在其餘語言平臺上用一樣的方法，但使用 Node.js 你能夠獲得很高的吞吐量，每一個請求都做爲一個小任務很是迅速和高效地處理，這一點咱們已經討論過了。

結論

咱們已經從理論到實踐討論過 Node.js 了，從它的目標和野心，到其優勢和缺點。在 Node.js 的開發中99%的問題是由誤用阻塞操做而形成的。

請記住：Node.js 歷來不是用於解決大規模計算問題而建立的。它的出現是爲了解決大規模I/O 的問題，而且在這一點上作的很是好。

綜上，若是你項目需求中不包含CPU密集型操做，也不須要訪問任何阻塞的資源，那麼你就能夠利用的 Node.js 的優勢，盡情的享受快速、可擴展的網絡應用。

---

原文：Why The Hell Would I Use Node.js? A Case-by-Case Introduction
轉載自：伯樂在線 - Lellansin