為什么向后端工程師推薦Node.js
加入技術(shù)交流群
其中變量對象VO，包含了所有局部變量的引用。對于main函數，局部變量”id”存儲在VO.id內?？雌饋?lái)用VO來(lái)代替我們的 currentSate最合適了。但main函數還可能嵌套在其他函數之內，所以我們需要ScopeChain，它是一個(gè)包含當前運行函數VO和其所有父 函數scope的數組。
所以在這個(gè)例子中，在onDataLoad函數定義時(shí)，就為默認為其綁定了一個(gè)[[scope]]屬性指向其父函數的 ExecutionContext的ScopeChain。而當函數onDataLoad執行時(shí)，就可以通過(guò)[[scope]]屬性來(lái)訪(fǎng)問(wèn)父函數的VO對 象來(lái)找到id，如果父函數的VO中沒(méi)有id這個(gè)屬性，就再繼續向上查找其祖先的VO對象，直到找到id這個(gè)屬性或到達最外層返回undefined。也正 是因為這個(gè)引用，造成VO的引用計數不為0，在走出作用域時(shí)，才不會(huì )被垃圾回收。
很多朋友覺(jué)得閉包較難理解，其實(shí)我們只要能明確的區分函數定義和函數運行兩個(gè)時(shí)機，那么閉包就是讓函數在運行時(shí)能夠訪(fǎng)問(wèn)到函數定義時(shí)的所處作用域內的所有變量，或者說(shuō)函數定義時(shí)能訪(fǎng)問(wèn)到什么變量，那么在函數運行時(shí)通過(guò)相同的變量名一樣能訪(fǎng)問(wèn)到。
關(guān)于狀態(tài)保持是本文的重點(diǎn)，在我看到的多數Node.js的介紹文章中并沒(méi)有詳解這里，我們只是知道了要解決阻塞問(wèn)題，但是JavaScript解決阻塞問(wèn)題的優(yōu)勢到底在哪里，作為一名前端工程師，我想有必要花一些篇幅詳細解釋一下。
而之所以我叫它”狀態(tài)保持”因為還有一個(gè)非常相似的場(chǎng)景可以類(lèi)比：
用戶(hù)從A頁(yè)面提交表單到B頁(yè)面，如果提交數據校驗不通過(guò)，則需要返回A頁(yè)面，同時(shí)保持用戶(hù)在A(yíng)頁(yè)面填寫(xiě)的內容并提示用戶(hù)修改不對的地方。從提交到校驗出錯再返回繼續填寫(xiě)是一個(gè)包含網(wǎng)絡(luò )交互的異步過(guò)程，這相當于填寫(xiě)表單這個(gè)任務(wù)過(guò)會(huì )兒再繼續。
在傳統網(wǎng)頁(yè)開(kāi)發(fā)中，用戶(hù)的狀態(tài)通過(guò)請求傳遞到服務(wù)端，交由后端狀態(tài)保持(類(lèi)似交給db.query的currentSate)。而使用Ajax的網(wǎng) 頁(yè)，因為并未離開(kāi)原頁(yè)面，那么服務(wù)端只要負責校驗用戶(hù)提交的數據是否正確即可，發(fā)送錯誤，返回錯誤處相關(guān)信息即可，這就是所謂前端狀態(tài)保持?？梢钥吹竭@個(gè) 場(chǎng)景里邊服務(wù)端做的事情變少了，變純粹了。正如我們的例子中db.query不再存儲轉發(fā)第三個(gè)state參數，變得更在輕量。
我們看到通過(guò)JavaScript函數式語(yǔ)言特性，匿名函數支持和閉包很漂亮的解決了同步編程到異步編程轉化過(guò)程中遇到的一系列最重要的問(wèn)題。但JavaScript是否就是最好的？這就要回答我們引用新技術(shù)時(shí)需要考慮的最后一個(gè)問(wèn)題了。
使用Node.js是否帶來(lái)額外的困擾，如何解決？
Node.js性能真的是最好么？不用比較我們也可以得到結論，Node.js做無(wú)阻塞編程性能較難做到極致。何為極致？處理一個(gè)請求需要占用多少 內存，多少cpu資源，多少帶寬，有丁點(diǎn)浪費就不是極致。阻塞式編程浪費了大量進(jìn)程資源只是在等待，導致大量?jì)却婧蚦pu的浪費。在這方面Node.js 好很多，但也正是因為一些閉包等JavaScript內建機制也會(huì )導致資源的浪費，看下面的代碼：
| 1 2 3 4 5 6 7 8 | function main(){ var id = 1; var str = ...; //這里局部變量str存儲一個(gè)2M的字符串 db.query(select name from persons where id= + id,function(name){ output(person id: + id + , name: + name);//n秒后數據返回后執行回調 }); } main(); |
至少整個(gè)數據查詢(xún)過(guò)程中，變量str所使用的2M內存并不會(huì )被釋放，而str保持下去可能并沒(méi)有意義。前面已經(jīng)解釋過(guò)閉包的原理，閉包并沒(méi)有智能到只包起來(lái)今后可能被訪(fǎng)問(wèn)到的對象。即使不了解閉包的原理，也可以通過(guò)一段簡(jiǎn)單腳本驗證這點(diǎn)：
| 1 2 3 4 5 6 7 8 | function main(){ var id = 1; var str = ...; //這里存儲一個(gè)2M的字符串 window.setTimeout(function(){ debugger; //我們在這里設置斷點(diǎn) },10000) } main(); |
我們在回調函數當中只設置一個(gè)斷點(diǎn)，并不指明我們要訪(fǎng)問(wèn)哪個(gè)變量。然后我們在控制臺監視一下，id和str都是可以拿到的。
所以我來(lái)猜想一下，性能極端苛刻的場(chǎng)景，無(wú)阻塞是未來(lái)，但無(wú)阻塞發(fā)展下去，或者有更輕量的腳本引擎產(chǎn)生，或者JavaScript引擎可能要調整可以disable閉包，或者我們要通過(guò)給JS開(kāi)發(fā)靜態(tài)編譯器在代碼發(fā)布前自動(dòng)優(yōu)化我們的代碼。
靜態(tài)編譯是如今JavaScript技術(shù)領(lǐng)域的又一個(gè)熱點(diǎn)，我們都知道JavaScript是解釋型腳本語(yǔ)言，在運行時(shí)自動(dòng)編譯。但是運行時(shí)編譯只是將代碼轉為機器碼執行，卻并未覆蓋傳統編譯型語(yǔ)言在編譯階段所做的任務(wù)。比如，語(yǔ)法檢查，接口校驗，全局性能優(yōu)化等等。
最常見(jiàn)的JavaScript靜態(tài)編譯就是腳本壓縮工具，在代碼發(fā)布到線(xiàn)上之前，我們通過(guò)各種壓縮工具，將代碼壓縮，達到減少網(wǎng)絡(luò )傳輸量的問(wèn)題。而 在這個(gè)時(shí)間點(diǎn)，已經(jīng)有越來(lái)越多的事情可做，比如：Google利用ClouserComplier提供的系列編譯指令，讓JavaScript更好的實(shí)現 OO編程。也有GWT，CoffeeScript這樣的項目，將其他語(yǔ)言編譯為JavaScript。在淘寶我們在代碼靜態(tài)編譯階段來(lái)解決因 JavaScript細粒度模塊化改造引入各種性能問(wèn)題，也用來(lái)對第三方提供JavaScript代碼進(jìn)行一定的安全檢查。
我們期待前面的代碼經(jīng)過(guò)靜態(tài)編譯器編譯后變成如下結果：
| 1 2 3 4 5 6 7 8 9 | function main(){ var id = 1; var str = ...; //這里局部變量str存儲一個(gè)2M的字符串 db.query(select name from persons where id= + id,function(name){ output(person id: + id + , name: + name); }); str = ; //通過(guò)這一行，及時(shí)釋放不必要的內存占用。 } main(); |
除了性能方面的擔憂(yōu)，使用Node.js進(jìn)行編程增加了代碼編寫(xiě)的復雜度。因為我們習慣于阻塞式編程的寫(xiě)法，切換到異步模式編程，往往對于太多多層次的callback函數嵌套弄得不知所措。老趙最近開(kāi)發(fā)了項目JSCEX正是要解決這個(gè)問(wèn)題，它讓大家在遵守一些小的約定后，能夠仍然保持同步編程的寫(xiě)法進(jìn)行代碼開(kāi)發(fā)。寫(xiě)完的代碼同樣通過(guò)靜態(tài)編譯器編譯成異步回調式模式的代碼再交給JavaScript引擎執行。
Node.js還要解決什么問(wèn)題
說(shuō)了這么多，無(wú)阻塞編程要做的還遠不止這些。首先需要一個(gè)高效的JS引擎，高效的事件池和線(xiàn)程池。另外幾乎所有和Node.js交互的傳統模塊如文件系統，數據訪(fǎng)問(wèn)，HTTP解析，DNS解析都是阻塞式的，都需要額外改造。
Node.js作者極其團隊，正是認清問(wèn)題所在以及JS解決這些問(wèn)題方面的優(yōu)勢?；贕oogle開(kāi)源的高效JavaScript引擎V8，貢獻了大量的智慧和精力解決上述大部分問(wèn)題后才有Node.js橫空出世。
當前Node社區如此火熱，千余開(kāi)源的Node.js模塊，活躍在WebFramework，WebSocket，RPC，模板引擎，數據抓取服務(wù)，圖形圖像幾乎所有工程領(lǐng)域。
后記
本文主要的信息來(lái)自Node.js作者在JSConf09，JSConf10上的分享。 而作為前端開(kāi)發(fā)，著(zhù)重講了函數式編程，閉包對于無(wú)阻塞開(kāi)發(fā)的重要意義。我期待這篇文章能夠給前端和后端工程師都帶來(lái)收獲。
同樣作為前端開(kāi)發(fā)，不得不再插幾句，說(shuō)說(shuō)服務(wù)端JS能夠解決的另一個(gè)問(wèn)題：當前的Web開(kāi)發(fā)前后端使用不同的語(yǔ)言，很多相同的業(yè)務(wù)邏輯要前后端分別 用不同語(yǔ)言重復實(shí)現。比如越來(lái)越多重度依賴(lài)JavaScript的胖客戶(hù)端應用，當客戶(hù)瀏覽器禁用JavaScript時(shí)，則需要使用服務(wù)端語(yǔ)言將主業(yè)務(wù) 流程再實(shí)現一次，這即是前端常說(shuō)的”漸進(jìn)增強”。
當我們擁有了服務(wù)端JavaScript語(yǔ)言，我們自然就會(huì )想到能否利用Node.js做到”一次開(kāi)發(fā)，漸進(jìn)增強”。解決掉這個(gè)為小量用戶(hù)，浪費大量時(shí)間的惱人的問(wèn)題。這方面的實(shí)踐，YAHOO仍然是先驅?zhuān)缭谝荒甓嗲伴_(kāi)始YAHOO通過(guò)nodejs-yui3項目做了很多卓越的貢獻，而淘寶自主開(kāi)發(fā)的前端框架Kissy也有服務(wù)端運行的相關(guān)嘗試。
JavaScript在誕生之時(shí)就不僅僅是瀏覽器端工具，如今JavaScript能夠再一次回到服務(wù)端展示拳腳，感謝V8，感謝NodeJS作者，團隊和社區的諸多貢獻者，祝Node好運，JavaScript好運。本文引用地址：http://dyxdggzs.com/article/185521.htm
評論