科普文一則，說說我對Node.js的一些認識，以及我作為前端工程師為什么會向后端工程師推薦Node.js。

“Node.js 是服務器端的 JavaScript 運行環境，它具有無阻塞(non-blocking)和事件驅動(event-driven)等的特色，Node.js 采用V8引擎，同樣，Node.js實現了類似 Apache 和 nginx 的web服務，讓你可以通過它來搭建基于 JavaScript的Web App。”

　　我想不僅僅是Node.js，當我們要引入任何一種新技術前都必須要搞清楚幾個問題:

1. 我們遇到了什么問題？
2. 這項新技術解決什么問題，是否契合我們遇到的問題？
3. 我們遇到問題的多種解決方案中，當前這項新技術的優勢體現在哪兒？
4. 使用新技術，帶來哪些新問題，嚴重么，我們能否解決掉？

　　我們的問題：Server端阻塞

　　Node.js被設計用來解決服務端阻塞問題。下面通過一段簡單的代碼解釋何為阻塞：

　　Js代碼：

　　這段代碼的問題是在上面兩個語句之間，在整個數據查詢的過程中，當前程序進程往往只是在等待結果的返回，這就造成了進程的阻塞。對于高并發，I/O密集行的網絡應用中，一方面進程很長時間處于等待狀態，另一方面為了應付新的請求不斷的增加新的進程。這樣的浪費會導致系統支持QPS遠遠小于后端數據服務能夠支撐的QPS，成為了系統的瓶頸。而且這樣的系統也特別容易被慢鏈接攻擊(客戶端故意不接收或減緩接收數據，加長進程等待時間)。

　　如何解決阻塞問題

　　可以引入事件處理機制解決這個問題。在查詢請求發起之前注冊數據加載事件的響應函數，請求發出之后立即將進程交出，而當數據返回后再觸發這個事件并在預定好的事件響應函數中繼續處理數據：

　　Js代碼：

　　我們看到若按照這個思路解決阻塞問題，首先我們要提供一套高效的異步事件調度機制。而主要用于處理瀏覽器端的各種交互事件的JavaScript，相對于其他語言，至少有兩個關鍵點特別適合完成這個任務。

　　為什么JS適合解決阻塞問題

　　首先JavaScript是一種函數式編程語言，函數編程語言最重要的數學基礎是λ演算(lambda calculus) -- 即函數對象可以作為其他函數對象的輸入(參數)和輸出(返回值)。

　　這個特性使得為事件指定回調函數變得很容易。特別是JavaScript還支持匿名函數。通過匿名函數的輔助，之前的代碼可以進行簡寫如下：

　　Js代碼：

　　還有另一個關鍵問題是，異步回調的運行上下文保持(本文暫稱其為"狀態保持")。我們先來看一段代碼來說明何為狀態保持：

　　Js代碼：

　　前面的寫法在傳統的阻塞是編程中非常常見，但接下來進行異步改寫時會遇到一些困擾：

　　Js代碼：

　　細心的朋友可能已經注意到，當等待了n秒數據查詢結果返回后執行回調時。回調函數中卻仍然使用了main函數的局部變量"id"，而"id"似乎應該在n秒前走出其作用域。為什么此時"id"仍然可以訪問呢，這是因為JavaScript的另外一個重要語言特性：閉包(Closures)。接下來我來詳解閉包的原委。

　　在復雜的應用中，我們一定會遇到這類場景。即在函數運行時需要訪問函數定義時的上下文數據(注意：一定要區分函數定義時和函數運行時兩個不同的時刻)。特別是在異步編程模型中，函數的定義和運行又分處不同的時間段，那么保持上下文的問題變得更加突出了。因為我們在任務執行一半時把資源交出去沒有問題，但當任務需要再次繼續時我們必須還原現場。

　　在這個例子中，db.query作為一個公共的數據庫查詢方法，把"id"這個業務數據傳入給db.query，交由其保存是不太合適的。但我們可以稍作抽象，讓db.query再支持一個需要保持狀態的數據對象傳入，當數據查詢完畢后可以把這些狀態數據原封不動的回傳。如下：

　　Js代碼：

　　記住這種重要的思路，我們再看看是否還能進一步的抽象？可以的，不過接下的動作之前，我們還要了解在JavaScript中一個函數也是一個對象。一個函數實例fn除了函數體的定義之外，我們仍然可以在這個函數對象實例之本身擴展其他屬性，如fn.a=1;受到這個啟發我們嘗試把需要保持的狀態直接綁定到函數實例上：

　　Js代碼

　　我們做了什么？生成了currentState對象，然后在函數onDataLoad定義時，將currentState綁定給onDataLoad這個函數實例。那么在onDataLoad運行時，就可以拿到定義時的state對象了。JavaScript的閉包特性就是內置了這個過程而已。

　　在每個JavaScript函數運行時，都有一個運行時內部對象稱為Execution Context，它包含如下Variable Object(VO, 變量對象)， Scope Chain(作用域鏈)和"this" Value三部分。如圖:

　　其中變量對象VO，包含了所有局部變量的引用。對于main函數，局部變量"id"存儲在VO.id內。看起來用VO來代替我們的currentSate最合適了。但main函數還可能嵌套在其他函數之內，所以我們需要ScopeChain，它是一個包含當前運行函數VO和其所有父函數scope的數組。

　　所以在這個例子中，在onDataLoad函數定義時，就為默認為其綁定了一個[[scope]]屬性指向其父函數的ExecutionContext的ScopeChain。而當函數onDataLoad執行時，就可以通過[[scope]]屬性來訪問父函數的VO對象來找到id，如果父函數的VO中沒有id這個屬性，就再繼續向上查找其祖先的VO對象，直到找到id這個屬性或到達最外層返回undefined。也正是因為這個引用，造成VO的引用計數不為0，在走出作用域時，才不會被垃圾回收。

　　很多朋友覺得閉包較難理解，其實我們只要能明確的區分函數定義和函數運行兩個時機，那么閉包就是讓函數在運行時能夠訪問到函數定義時的所處作用域內的所有變量，或者說函數定義時能訪問到什么變量，那么在函數運行時通過相同的變量名一樣能訪問到。

　　關于狀態保持是本文的重點，在我看到的多數Node.js的介紹文章中并沒有詳解這里，我們只是知道了要解決阻塞問題，但是JavaScript解決阻塞問題的優勢到底在哪里，作為一名前端工程師，我想有必要花一些篇幅詳細解釋一下。

　　而之所以我叫它”狀態保持”因為還有一個非常相似的場景可以類比：

　　用戶從A頁面提交表單到B頁面，如果提交數據校驗不通過，則需要返回A頁面，同時保持用戶在A頁面填寫的內容并提示用戶修改不對的地方。從提交到校驗出錯再返回繼續填寫是一個包含網絡交互的異步過程，這相當于填寫表單這個任務過會兒再繼續。

　　在傳統網頁開發中，用戶的狀態通過請求傳遞到服務端，交由后端狀態保持(類似交給db.query的currentSate)。而使用Ajax的網頁，因為并未離開原頁面，那么服務端只要負責校驗用戶提交的數據是否正確即可，發送錯誤，返回錯誤處相關信息即可，這就是所謂前端狀態保持。可以看到這個場景里邊服務端做的事情變少了，變純粹了。正如我們的例子中db.query不再存儲轉發第三個state參數，變得更在輕量。

　　我們看到通過JavaScript函數式語言特性，匿名函數支持和閉包很漂亮的解決了同步編程到異步編程轉化過程中遇到的一系列最重要的問題。但JavaScript是否就是最好的？這就要回答我們引用新技術時需要考慮的最后一個問題了。

　　使用Node.js是否帶來額外的困擾，如何解決？

　　Node.js性能真的是最好么？不用比較我們也可以得到結論，Node.js做無阻塞編程性能較難做到極致。何為極致？處理一個請求需要占用多少內存，多少cpu資源，多少帶寬，有丁點浪費就不是極致。阻塞式編程浪費了大量進程資源只是在等待，導致大量內存和cpu的浪費。在這方面Node.js好很多，但也正是因為一些閉包等JavaScript內建機制也會導致資源的浪費，看下面的代碼：

　　Js代碼：

　　至少整個數據查詢過程中，變量str所使用的2M內存并不會被釋放，而str保持下去可能并沒有意義。前面已經解釋過閉包的原理，閉包并沒有智能到只包起來今后可能被訪問到的對象。即使不了解閉包的原理，也可以通過一段簡單腳本驗證這點：

　　Js代碼：

　　我們在回調函數當中只設置一個斷點，并不指明我們要訪問哪個變量。然后我們在控制臺監視一下，id和str都是可以拿到的。

　　所以我來猜想一下，性能極端苛刻的場景，無阻塞是未來，但無阻塞發展下去，或者有更輕量的腳本引擎產生，或者JavaScript引擎可能要調整可以disable閉包，或者我們要通過給JS開發靜態編譯器在代碼發布前自動優化我們的代碼。

　　靜態編譯是如今JavaScript技術領域的又一個熱點，我們都知道JavaScript是解釋型腳本語言，在運行時自動編譯。但是運行時編譯只是將代碼轉為機器碼執行，卻并未覆蓋傳統編譯型語言在編譯階段所做的任務。比如，語法檢查，接口校驗，全局性能優化等等。

　　最常見的JavaScript靜態編譯就是腳本壓縮工具，在代碼發布到線上之前，我們通過各種壓縮工具，將代碼壓縮，達到減少網絡傳輸量的問題。而在這個時間點，已經有越來越多的事情可做，比如：Google利用ClouserComplier提供的系列編譯指令，讓JavaScript更好的實現OO編程。也有GWT，CoffeeScript這樣的項目，將其他語言編譯為JavaScript。在淘寶我們在代碼靜態編譯階段來解決因JavaScript細粒度模塊化改造引入各種性能問題，也用來對第三方提供JavaScript代碼進行一定的安全檢查。

　　我們期待前面的代碼經過靜態編譯器編譯后變成如下結果：

　　Js代碼：

　　除了性能方面的擔憂，使用Node.js進行編程增加了代碼編寫的復雜度。因為我們習慣于阻塞式編程的寫法，切換到異步模式編程，往往對于太多多層次的callback函數嵌套弄得不知所措。老趙最近開發了項目JSCEX正是要解決這個問題，它讓大家在遵守一些小的約定后，能夠仍然保持同步編程的寫法進行代碼開發。寫完的代碼同樣通過靜態編譯器編譯成異步回調式模式的代碼再交給JavaScript引擎執行。

　　Node.js還要解決什么問題

　　說了這么多，無阻塞編程要做的還遠不止這些。首先需要一個高效的JS引擎，高效的事件池和線程池。另外幾乎所有和Node.js交互的傳統模塊如文件系統，數據訪問，HTTP解析，DNS解析都是阻塞式的，都需要額外改造。

　　Node.js作者極其團隊，正是認清問題所在以及JS解決這些問題方面的優勢。基于Google開源的高效JavaScript引擎V8，貢獻了大量的智慧和精力解決上述大部分問題后才有Node.js橫空出世。

　　當前Node社區如此火熱，千余開源的Node.js模塊，活躍在WebFramework，WebSocket，RPC，模板引擎，數據抓取服務，圖形圖像幾乎所有工程領域。

　　后記

　　本文主要的信息來自Node.js作者在JSConf09，JSConf10上的分享。 而作為前端開發，著重講了函數式編程，閉包對于無阻塞開發的重要意義。我期待這篇文章能夠給前端和后端工程師都帶來收獲。

　　同樣作為前端開發，不得不再插幾句，說說服務端JS能夠解決的另一個問題：當前的Web開發前后端使用不同的語言，很多相同的業務邏輯要前后端分別用不同語言重復實現。比如越來越多重度依賴JavaScript的胖客戶端應用，當客戶瀏覽器禁用JavaScript時，則需要使用服務端語言將主業務流程再實現一次，這即是前端常說的”漸進增強”。

　　當我們擁有了服務端JavaScript語言，我們自然就會想到能否利用Node.js做到”一次開發，漸進增強”。解決掉這個為小量用戶，浪費大量時間的惱人的問題。這方面的實踐，YAHOO仍然是先驅，早在一年多前開始YAHOO通過nodejs-yui3項目做了很多卓越的貢獻，而淘寶自主開發的前端框架Kissy也有服務端運行的相關嘗試。

　　JavaScript在誕生之時就不僅僅是瀏覽器端工具，如今JavaScript能夠再一次回到服務端展示拳腳，感謝V8，感謝NodeJS作者，團隊和社區的諸多貢獻者，祝Node好運，JavaScript好運。

　　關于作者

　　李穆，前端工程師，就職于淘寶廣告技術部架構組，淘寶花名：李牧，專注淘寶廣告引擎和業務系統前端開發。