NodeJS優缺點及適用場景討論

前端開發

程序猿

2013年12月12日

/159.html概述：NodeJS宣稱其目標是“旨在提供一種簡單的構建可伸縮網絡程序的方法”，那么它的出現是為了解決什么問題呢，它有什么優缺點以及它適用于什么場景呢？本文就個人使用經驗對這些問題進行探討。一.NodeJS的特點我們先來看看NodeJS官網上的介紹：Node.jsisaplatformbuiltonChrome’sJavaScriptruntimeforeasilybuildingfast,scalablenetworkapplications.Node.jsusesanevent-driven,non-blockingI/Omodelthatmakesitlightweightandefficient,perfectfordata-intensivereal-timeapplicationsthatrunacrossdistributeddevices.其特點為：

1.它是一個Javascript運行環境2.依賴于ChromeV8引擎進行代碼解釋3.事件驅動4.非阻塞I/O5.輕量、可伸縮，適于實時數據交互應用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，不能充分利用CPU3.可靠性低，一旦代碼某個環節崩潰，整個系統都崩潰原因：單進程，單線程解決方案：（1）Nnigx反向代理，負載均衡，開多個進程，綁定多個端口；（2）開多個進程監聽同一個端口，使用cluster模塊；4.開源組件庫質量參差不齊，更新快，向下不兼容5.Debug不方便，錯誤沒有stacktrace四.適合NodeJS的場景1.RESTfulAPI這是NodeJS最理想的應用場景，可以處理數萬條連接，本身沒有太多的邏輯，只需要請求API，組織數據進行返回即可。它本質上只是從某個數據庫中查找一些值并將它們組成一個響應。由于響應是少量文本，入站請求也是少量的文本，因此流量不高，一臺機器甚至也可以處理最繁忙的公司的API需求。2.統一Web應用的UI層目前MVC的架構，在某種意義上來說，Web開發有兩個UI層，一個是在瀏覽器里面我們最終看到的，另一個在server端，負責生成和拼接頁面。不討論這種架構是好是壞，但是有另外一種實踐，面向服務的架構，更好的做前后端的依賴分離。如果所有的關鍵業務邏輯都封裝成REST調用，就意味著在上層只需要考慮如何用這些REST接口構建具體的應用。那些后端程序員們根本不操心具體數據是如何從一個頁面傳遞到另一個頁面的，他們也不用管用戶數據更新是通過Ajax異步獲取的還是通過刷新頁面。3.大量Ajax請求的應用例如個性化應用，每個用戶看到的頁面都不一樣，緩存失效，需要在頁面加載的時候發起Ajax請求，NodeJS能響應大量的并發請求。總而言之，NodeJS適合運用在高并發、I/O密集、少量業務邏輯的場景。五.結尾其實NodeJS能實現幾乎一切的應用，我們考慮的點只是適不適合用它來做。\o"Permalinkto關于Node.js不得不說的事兒"關于Node.js不得不說的事兒發表于:

\o"查看Web前端中的全部文章"Web前端

|作者:

\o"由ryan發布"ryan

|目前已閱讀:8,031次標簽:Node.js自從誕生之后就引起了廣大web前端開發同學的關注，且很快成為開源分享站點最熱門的話題之一。同時國內越來越多的技術沙龍里出現Node.js的身影，也有越來越多的團隊開始在生產系統上使用Node.js。但正如《人月神話》作者所說的一樣”NoSilverBullet”，軟件開發沒有銀彈，適當的技術適當做適當的事情。下面我們來看下Node.js于我們來說應該持怎樣的態度。

Node.js到底是什么？

Node.js不是一個新的開發語言，而是開發語言（JavaScript）的一個運行環境。通俗的說就是原來只是跑在瀏覽器里的JavaScript可以跑在你的PC，你的Mac，甚至你的Web服務器上了。

Node.js官網（/）對其介紹足夠簡單明了：

Node.js是基于Chrome的JS運行環境，用來方便地構建高效的、可擴展的網絡應用。由于采用事件驅動和無阻塞模型，使得Node.js對跨平臺的資源密集型實時應用有更輕量、高效和完美的支持。

但是如果單單是把JavaScript運行環境（ChromeV8引擎）放到Windows或Linux平臺其實是沒有太大意義的，因為JavaScript在瀏覽器里的部分魅力在于DOM，BOM操作。同時Javascript在瀏覽器上的發揮嚴重受限于跨域，安全，本地限制等各種約束。Node.js提供的環境剛剛相反，減掉DOM和BOM等支持，增加了文件系統、進程管理、事件驅動（類似DOM上的）、util工具集和HTTP服務等各種強大的功能。于是，Node.js具備了其他開發語言所具備的能力。被困在瀏覽器里的這頭野獸，被放養了。

哪些人在用Node.js？

一類是生產系統，直接或間接的面向互聯網用戶的，舉例如下：

朋友網長鏈接聊天服務花瓣網整站Node.js開發+Express框架新浪網Node.js做MySQL中間層阿里淘寶指數、數據魔方等及中間層搜狐小紙條等Linkedin移動服務Stackvm虛擬機服務雅虎郵箱開發微軟win8相關joyent云服務一類是工具集，提升研發效率和方法：這個就不勝枚舉了。可以毫不夸張的說，幾乎所有的稱得上名字的互聯網公司都有在使用。

Node.js優勢和劣勢

下面主要從語言的特點，開發的成本，功能特點的一些角度來簡單做一個劃分：

優勢原因1異步的I/O模型這個應該是Node.js做生產系統最大的優勢，也是官方主打的特性。在實時聊天、IO密集、服務（數據庫）調用阻塞等問題上，JS的異步模式有天然優勢。舉例：

C++代碼

JavaScript代碼2語言優勢JavaScript本身語言入門門檻低，且在互聯網時代下有大量的web前端開發同學（熟練使用JavaScript、熟悉其語言特性，同時這批同學對HTTP協議有著深入的理解），他們不需要學習新的語言即可以涉獵server開發。這使得新興創業公司及一些前端相對強勢的大公司，在生產系統上都有了不俗的表現。3活躍的社區、群體和模塊化能力Node.js社區在以瘋狂的速度發展，github上的項目也層出不窮。使用Node.js的都是具備一定產品意識和外向性格的群里，這使得基于Node.js的新的idea在媒體上屢屢曝光。Node.js提供了非常便利的模塊管理模式（npm工具），大大降低了模塊耦合的成本。同時，基于node.js的工具模塊在跨平臺web前端開發過程中，體現出了絕大的價值。比如：grunt代碼整合，前端代碼預編譯等。

當然我們也要看到Node.js的劣勢和問題所在：

缺點原因1穩定性上有所欠缺畢竟，Node.js是新生產物，在它趕超其他熱門語言的過程需要時間和成長。目前最讓人頭痛的一個問題是，Node.js在升級過程中，經常會導致開發者基于老版本開發的代碼無法直接使用。這個是在pomleo（網易游戲開發框架）和朋友網長鏈接聊天server研發過程中都遇到過的問題。（當然可以通過不升級和適配的方式解決）

2不太適合敏捷web開發或大型復雜web開發如果你或你的團隊熟悉php,java等web開發語言，那么不建議使用Node.js作為項目開發首選。比如我們內部的管理系統，敏捷開發調試會選擇php；海量的生產系統會選擇C++。這里舉一個很簡單的例子。php和node.js的helloworld。

php代碼

Node.js代碼

這個看上去還好，但是當你需要對一個靜態資源進行cache的時候，php或java等依賴webserver的可以默認實現且簡單配置可以處理，但是對于node.js就慘了。你需要逐條編寫代碼實現HTTP協議上的功能，重復造輪子。Node.js的開發成本除了語言特性上的便捷以外，其他邏輯開發和C/C++幾乎是一樣的。代碼如下：

這搞起來是不是很蛋疼。當然也有一些解決方案，比如使用express等框架，但是這里問題還是會存在。畢竟Node.js還在成長，對于很多問題可能都還沒有人解決，那么就需要使用Node.js對基礎應用和網絡知識有較深入的理解，且對研發效率有所影響。好了，上面兩個劣勢已經使得我們在選型過程中需要足夠的慎重，但是也不能因噎廢食嘛。

我們如何看待Node.js

我個人的理解是：在大工具時代下，Node.js為前端開發同學插上了創造力的翅膀。

首先是在輕邏輯，長鏈接場景下，我們對Node.js可以更為開放，基于socket.io可以在半天內，實現一個10w+級別同時在線的聊天系統（其性能不低于C/C++，且擴展性遠高于C/C++）。

其次，在web研發流程中，Node.js扮演這重要的工具化、自動化的角色。比如：less.js，grunt.js，mocha，zombie.js。Node.js在全球的互聯網行業工具化過程中，已經扮演了潮流的引導者的角色。我們在保持學習的同時，需要不斷的思考和實踐，日常的研發過程中那些手工行為、人為檢查甚至是效率不高的開發模式是可以用Node.js來工具化和自動化的。

這個也是為什么要寫這篇文章的目的，希望在工具化和自動化的道路上，再給大家打一針強心劑。

關于Node.js不得不說的

編號名字簡述1npmNode.js的模塊管理器，有了它你就可以一行命令下載所有node.js的模塊或基于node.js的工具。Eg:npminstallexpress，一下幫你搞定。

2nNode.js的多版本管理器。之前提到了Node.js版本更新很快，且是版本升級不兼容舊的API，那么同一臺機器不同項目可能存在多個Node.js版本。那么這個神奇可以幫你一條命令解決問題。

使用npminstalln-g就可以（可惜暫時不支持windows=。=！，不過微軟已經官方支持node.js了，相信支持的日子不遠了）。用法：nuse0.10.53調試首先是nodedebug

這個跟gdb的單步調試模式差不多。

其次是通過webstorm等工具進行遠程調試，但本地需要保存代碼且服務器開端口

然后是node-inspector調試，這貨跟我們weire的模式是一樣的，在頁面里模擬chromedebug工具。

4CommonJSNode.js不是第一個嘗試將JavaScript放在瀏覽器之外的地方運行。早在JS誕生的時候網景公司就這么干過，可是后來沒有流行。直到近幾年JS引擎的強大導致JS又重新流行起來。群空間用過的rhino工具支持的RingoJS也是類似的思路。如果當年統一JS而誕生的ECMAScript規范一樣，CommonJS為瀏覽器外的JS標準而誕生。這塊大家可以百度了解下~Node.js真的無所不能？那些不適用的應用領域分析(1)2014-03-1123:02沈嶸51

我要評論(0)

字號：T

|

T其實到今天為止，很少有哪些大的互聯網公司是和Node.js無關的。LinkedIn，Yahho，Paypal,eBay,Walmart都在將既有的系統向Node.js遷移（/Node-js/What-companies-are-using-Node-js-in-production翻墻看）。國內的淘寶、網易、百度等也都有很多項目運行在Node.js之上。AD：Node.js是一個服務器端JavaScript解釋器，底層采用的還是libevent；它的目標是幫助程序員構建高度可伸縮的應用程序，目前對Node.js的采用狀況，Node.js官方站點有一些羅列，但是相當不完整。如果你自己公司用到，也可以在github上提交自己的pull-request來更新這個文檔。/industry//joyent/node/wiki/Projects,-Applications,-and-Companies-Using-Node其實到今天為止，很少有哪些大的互聯網公司是和Node.js無關的。LinkedIn，Yahho，Paypal,eBay,Walmart都在將既有的系統向Node.js遷移（/Node-js/What-companies-are-using-Node-js-in-production翻墻看）。國內的淘寶、網易、百度等也都有很多項目運行在Node.js之上。2011年我開始接觸Node.js的時候，上只有不到3,000個Node.js的packages，今天(2014-3-2)則有61,897個，這個數字還在快速增長中。下面有兩個鏈接，第一個是在講Walmart這幾年為什么以及如何遷移到Node.js上；第二個則為eBay是如何從Node.js的懷疑者轉變為采用者。Node.jsatWalmarteBay'sNode.jsAdoptionJourney《Announcingql.io》

這篇文章的最后一段，列出了eBay為什么選擇Node.js。每天都有幾百個新的packages被發布到

npm

上，小到幾行代碼，大到萬行代碼的Framework。一天有7百萬次的包下載（安裝到某臺電腦上），對于單一開發框架的社區來說，用沸騰的海洋來形容并不過分。

以下應用領域和程序員不適合選擇Node.js：計算密集型應用。Javascript的計算性能是很難和C語言代碼相比的。當然，也有反例：http://onlinevillage.blogspot.jp/2011/03/is-javascript-is-faster-than-c.html，只不過不具有典型性。需要精密控制內存的分配和釋放的場景，如果用Node.js實現Redis數據庫，雖然程序會簡單不少，但是JVM對內存數據結構的精密控制能力是比不了用C語言純手工打造的。大量且需要頻繁通過CBinding調用Clibrary的情況。這種場景下，往返參數的Marshal/Unmarshal的成本可能會大于CLibrary帶來的性能提升。實時性要求很高的場景，例如：交換機或者工控機器人。這是因為所有通過垃圾回收機制來管理內存的系統都有可能在GC過程中產生停頓，從而影響響應速度，而且很難優化。需要單一進程控制大內存的場景：v8引擎的設計限制，在32-bit下有1GB最大堆尺寸的限制，在64-bit下是1.7GB。當然，由于node.jsbuffer的分配不是在v8的堆上，因此可以超過此限制。這個限制可以通過向v8引擎傳遞max_old_space_size

參數來超越，但是也會帶來GC的性能退化。這一問題在幾乎所有GCBased的系統下都存在。不關心系統吞吐率或者不需要異步調用的場景：例如，自動化腳本，這些腳本不需要關心多用戶并發訪問的性能消耗。用Python這樣的“膠水”語言寫起來會更簡單。某些非通用場景：例如nginx對于靜態webserver或者反向代理的場景是特別設計的，這些場景中nginx的性能比Node.js要好。強類型強迫癥：有些Java或者.NET過來的程序員會認為只有強類型語言和嚴格定義的類型系統是專業化的象征，構造這樣的系統是架構師的使命，而動態語言只是玩具，只能用來做Demo或者前端開發。團隊成員難以理解或者接受函數式編程：Javascript本質上更像函數式語言，有些程序員在理解和使用閉包、高階函數等概念時總是不能習慣，這個問題在國內的開發團隊中還挺普遍的。回調式編程的不習慣：Node.js的異步IO大量依賴回調。回調讓程序的執行出現了兩條路徑，出現故障時調用棧也很難理解。這對習慣了同步編程的程序員來說一開始確實是個坎。async,

Qpromise

等package可以緩解這個問題（在ES6的Generator普及之前），不過這也帶來了更陡峭的學習曲線。一般情況下，需要半年到一年的習慣過程，當然前提是多看，多寫。隨著越來越多的經驗分享，這個過程也在不斷地縮短。除此之外的領域，或者沒有上述問題的，都都可以享受到Node.js帶來的生產力提升和穩定的性能保障。性能的爭議不同開發環境間的性能對比從來都是有爭議的話題。我只能說，當開發Web或網絡環境下的應用時，Node.js靠以下幾個方面來避免出現不必要的性能問題：ChromeV8，一個可靠的優秀的虛擬機(hiddenclasses和inlinecaching)，讓Javascript的運行速度進入了第一陣營(C++,Java,.NET)。異步IO大大降低了線程數量，莫名其妙的死鎖和等待的概率被降低了很多。大部分場景不用去考慮并發和同步鎖，犯錯誤的機會少。而在Python中，異步IO并不是標準，并沒有被貫穿到所有Package中，因此應用程序也就很難獲得一致的性能保障。非常輕巧的“內核”。Node.js的模塊分為CoreModules和Userland兩部分。CoreModules非常精簡，只包括TCP,HTTP,DNS,FileSystem,childprocesses和其他一些模塊，這些網絡庫還只有異步版本。相對地，在Userland中卻有著海量的Packages。開發應用的時候，我們根據應用的需求來組合Userland的Packages，使得我們的應用程序有機會在一個很低的資源消耗水平下運行（在《Announcingql.io》中指出，一臺開發服務器就可以支持12萬活躍連接，平均每個連接消耗2k內存）。事實上，我開發的WebSockte應用在RaspberryPi下都可以支持幾百并發長連接（WebSocket）。和那些動輒上萬個類的企業開發框架相比，這是一個巨大的優勢。這種方式降低了出現問題的概率、查找問題的成本以及減少部署成本。對Javascript的絕對性能的追求一直沒有停頓（例如，Mozilla的

asm.js

）。而Node.js則在絕對性能的基礎上，確保應用程序可以獲得穩定和可預測的性能保障（Benchmark和實際的應用運行往往是兩回事）。Node.js繼承了JavaScript的靈活性，優秀的JS庫應當如何選擇可以在或者google上搜索關鍵詞。如果類似的返回很多，則看其被其他package依賴的數量有多少。上github上查看starred和forks的數量，讀issues。如果是“名人”（substack,visionmedia(TJHolowaychuk),dominictarr,rvagg等）寫的Packages自然會被加分。最后是把GitRepo.Clone或者Fork下來,閱讀且注釋他們的源代碼。這個過程也可以發現很多他們依賴的其他Packages。這是一個蠻享受的過程，可以學到很多新知識和新的用法。還有一些亂槍打鳥的方法：在Tweeter上關注@nodenpm，所有在npm上發布或者更新的packages都會在該handle上發布出來。在你的碎片時間沒事可以刷刷這個，當然你需要APN翻墻。關注一些推薦和評論賬號：@dailyjs，@echojs等。Changelog

會提供不錯的開源信息匯總，其中包括Node.js、Javascript和npm欄目。HackerNews

則不會讓你忽略軟件行業的一些“大事”或者新概念。一個項目開始前的研究階段，我大約會瀏覽幾十個Packages，精讀其中的5~10個。開發過程中則根據需要還會不斷地發現和精讀一些，這些都被我計入了項目的成本。"自由選擇，自己負責"，在這個龐大的開發社區了不要指望有人能告訴你“標準答案”。每個人面臨的問題域和知識背景都不一樣，堅持多看，多試，多思考，享受獲得新知識的過程比獲得“標準答案”更重要。在眾多的成熟開發框架下為什么需要Node.js在每一個特定的問題域，大家總是在嘗試找到最優解。這個過程是沒有終結的，就想最終也會有其他框架代替Node.js一樣。今天的Web，是無數相互連接的WebServices組成的，這些連接的本質是異步的。Node.js天生異步的特性和這個場景的匹配度相對其他開發框架要更高，因此實現起來也更自然。除此之外，Node.js的設計基本原則遵循了《Unix的編程藝術》，參見IsaacZ.Schlueter(前任Node.js的Gatekeeper，目前負責npm的商業化)的Blog：

UnixPhilosophyandNode.js。npm和stream就是上述哲學的產物。npmnpm是Node.js的包管理系統。包管理系統不是新東西，但是和npm的那些前輩和表兄弟不同的是：npm直接集成在Node.js中，無需單獨安裝，發布，安裝packages非常簡單。提供一個統一的入口，你可以看到每個package被哪些packages所依賴，你也可以一目了然地看到它依賴了誰，以及最近的下載次數。結合到github上的更新情況，基本上對一個package的基本情況你都能了解到。約定俗成的發布規范：一個gitrepo.讓你可以直接找到源代碼；README.md提供簡要的說明讓消費者能盡快用起來。對于開發者來說，每一個package就是一個"microservice"，是最小重用單元。大部分的package只有幾百行代碼，甚至有些只有幾行代碼。這樣的重用粒度是在其他社區難以想象的。在Node.js的應用的開發過程中，編寫“一口尺寸”（bite-size）的module是推薦的編程方式。這也很方便你把這些小module封裝為package分享到社區當中，而不用擔心泄露“企業機密”。npm是每一個Noder的"home"，也是每一個Node.js應用的系統架構的一部分。Stream如果說，npm提供了“開發時重用”的機制，那么stream的則提供了“運行時”不同組件之間的“重用”機制。stream概念和unix中的stream對應，應用中的每一個component則對應unix的filter。下面舉一個實際的例子：在某個應用中，我需要一個APIServer，它的客戶端包括WebBrowser，iOSApp.,以及網絡中的其他Server。WebBrowser和我們的APIServer的通信基于

SockJS(當然你也可以選擇SocketIO，或者Faye等)，它為瀏覽器兼容提供了適當的“Fallback”方案；對于iOSApp.來說，由于不需要考慮瀏覽器兼容，則采用基于標準的RFC6455的純WebSocket通信協議，這樣實現起來更簡單；而對于其他Server來說，局域網內則用TCP，互聯網上則用TLS來保證傳輸安全。我在Node.js上是這么實現的：利用

donde

構建一個通信無關的RPCServer來提供API服務。用Node.jsCoreModules中的tcp,tls創建TCP/TLSServer并監聽，用第三方的

SockJS

和

websocket-stream

分別創建SockJS和WebSocket的Server并監聽。當Client連接到不同的端口，在Server上就會創建基于該協議的CommnucationStream，然后創建一個新的dnode實例，得到一個dnode的Stream。最后將CommnucationStream和dnodeStream像接水管一樣接到一起即可。net.createServer(function(connStream){

dnodeStream

=

dnode({

func1:

function(){}

});

connStream.pipe(dnodeStream).pipe

connStream;

});

考慮到在不穩定的網絡環境下的自動重連需求，也可以添加

reconnect。不算你自己RPCAPI的實現邏輯，支持這么多的通信協議的Server框架只需要百十行代碼，還加上了一定程度的異常處理。tcp,tls,SockJS，或者reconnect的開發者并不能確定“消費者”是如何使用這些Package的，但是大家都支持Stream的接口，則讓自己的Package能夠被運用到更多的場景。進一步，我們也可以多路復用一個底層的Stream。我們把上面的例子再擴展一下：在既有的通信連接上（connStream），除了提供RPCAPI之外，還需要添加分布式的狀態同步功能，例如：通過

Scuttlebutt，完成Client與Server或Server與Server之間的常量數據自動同步，而不用為這些功能設計新的RPCAPI。通過

mux-demux

，可以復用既有的網絡通信Stream（tcp,SockJS,WebSocket...），避免建立不必要的網絡連接。Stream是Node.js的核心概念之一，其接口和工作方式被廣泛地采用，為不同組件在運行時相互通信提供了最基本的支持。在Node.js中，如何使用Stream可以用一本書的容量來描述，不是因為Stream的概念有多復雜，而是因為其組合方式非常豐富。小結三年前接觸Node.js，并且學習和采用，主要原因是因為Node.js在解決當今網絡應用的問題時，提供了高性能、高可靠和低功耗的方法。高性能、高可靠和低功耗，不是在于Node.js做了什么，而是在于Node.js不做什么。Node.js和Javascript的概念，在Java或者其他開發框架中都能找到對應的概念。但是Node.js僅保留了它認為最重要的部分作為CoreModules，其他都讓給了UserLand，這才是高性能、高可靠和低功耗的最本質的保障。隨著Node.js這三年的發展，今天使我浸淫其中的理由已經不是之前的那些特點了。npm建立了一個“人人為我，我為人人”社區，無論你是一個入門級的Noder,還是一個多年的老兵，都在自覺或不自覺地從這個社區吸取營養，也在不斷地回饋社區。在使用npm的過程中，你會很自然地發現，將自己的應用切割為盡量小的Modules，發布為公有的Packages，配上一個簡單扼要的README.md，反而是最有效率的系統架構方式。Node.js所遵循的Unix設計哲學，又提供了最簡單有效的復用規范。簡單有效，才會被大家自覺采用，采用得越多，重用的可能性就更大。以Express4.0

(MEAN架構中的那個'E')為例，這么一個流行的MVCWebFramework的核心代碼只有2,600多行（不算測試，中間件和例子，但是包括注釋）。npm和github一起，為今天的軟件生產提供了新的生產關系，這也是當前Node.js超越其他社區的根本原因。不是單純的性能，也不僅僅是因為動態語言，甚至不是因為大量熟悉Javascript的前端程序員（和后端程序員相比，由于缺少系統性的思維，前端Javascript程序員掌握Node.js未必有多少優勢），而是以更加便捷的分享式開發為基礎的生產關系實實在在地提升了軟件生產力。

Node.js的駕馭能力如果“復雜的后端程序”等于“龐大的繼承樹”，“強類型安全”，“精細的異常定義和處理”，那么Node.js當然無法駕馭。因為Node.js和Java,.NET相比，是一顆獨立的“科技樹”。原型繼承、函數式編程、模塊系統、回調...，這些概念和編程方式對習慣了Java以及.NET的程序員來說不僅僅是不熟悉，甚至一開始會產生“不舒服的”感覺。從我的體驗來看（Basic->C->VB->Delphi->.NET->Node.js），這種不舒服更多地來自于之前對嚴謹的類型系統的信仰。原本所謂的“架構師”，承擔著整個應用或項目的類型系統的建設任務，對任何破壞類型一致性的行為都會自然而然的產生抵觸情緒。要想掌握Node.js，最好的方法是先從Java,.NET這顆“科技樹”上爬下來，清空自己，然后重新爬Node.js這棵樹。程序員從Java,.NET可以學到面向對象和泛型這些重用手段，而在Node.js的世界中，當你接觸到大量來自于完全不同背景的程序員所編寫的Packages的時候，你也會意識到，不是每樣東西都是“類”，重用也不一定都基于繼承。雖然有人試圖在Node.js中克隆之前自己熟悉的類型系統，但是更多的程序員則在不斷嘗試更優雅、簡單的編寫方式。在Node.js的開發過程中，沒有所謂的“最佳實踐”，類似的問題總會有人嘗試不同的解決方法。對于一個勤于思考和反思的程序員，這是一個充滿樂趣的過程。反之，如果你的團隊是由缺少獨立思考或者獨立解決問題的程序員組成的，那么Node.js確實不適合。你需要用強類型語言搭好一個受限的框架，然后讓體力型的隊友去填空。我們公司只有兩個程序員，一個負責iOS開發，而我負責“復雜”后端程序和WebBrowser開發。如果用Java或者.NET來開發，完成同樣的功能需要至少三倍以上的人力。Node.js能否統一前后端完全統一既