關(guān)于Node.js語言的討論
本文是從 Node on nails! 這篇文章翻譯而來。
在開始敘述這篇文章之前，我要非常清楚和明確的聲明：“我并不是在鼓勵你放棄 NodeJS 或轉(zhuǎn)向 Java”。
我一直參與在這種爭論中。在我的編程界的朋友中一直存在著一種誤解，他們認(rèn)為 NodeJS 語言是將來的趨勢。我對 Javascript 是百分百的喜愛(不是自吹，我有一段時間曾被認(rèn)為是 Javascript 專家，我寫了很多喜歡 js 的文章);關(guān)于 Javascript 閉包的優(yōu)美，原型模式編程風(fēng)格的優(yōu)勢，我是毫無質(zhì)疑。但是，如果把 Javascript 放到后臺，這就完全是另外一種情況了。
每當(dāng)我看到有人用一些重要的技術(shù)指標(biāo)對 NodeJS 進(jìn)行測評并宣稱NodeJS 是世界上最快的語言時，我都會覺得好笑。(你只要用谷歌搜一下 NodeJS vs *你能想到的任何東西*，你就會找到像這樣, 這樣, 和 這樣的東西。)
撇開我的質(zhì)疑，NodeJS 的語言模式還是值得關(guān)注的，但我會在我的產(chǎn)品中使用它嗎?我的問題就在這。我在使用 NodeJS 的過程中發(fā)現(xiàn)了一些非常嚴(yán)重的問題;給人的感覺相當(dāng)?shù)脑?。我必須寫一個完整的 HTTP 客戶包來支持 Multipart 方式傳送(現(xiàn)在這個包就是人們所知的 Reston)，這樣我才能把文件發(fā)送到 Amazon S3 服務(wù)和其它一些 REST 服務(wù)里(當(dāng)時沒有任何支持 HTTP Multipart 傳送的組件，HTTPS 也有問題，它折騰的我異常痛苦)，總而言之，我需要向讀者們說下面幾個觀點：
◆ 并不是所有的 web 應(yīng)用程序都需要大量的連接，你并不是每天都在開發(fā)一個聊天系統(tǒng)或一個 comet 系統(tǒng)。NodeJS 對處理某些事情很有優(yōu)勢，我們可以用到它。如果你是讓我去在一個 IRC 服務(wù)器上開發(fā)一個基于 websocket 的聊天系統(tǒng)，我會推薦 NodeJS;但，如果你是讓我去把郵件從你的帳號中取出然后存到 RDBMS 或 NOSQL 數(shù)據(jù)庫中，那我就需要思量了。
◆ 技術(shù)架構(gòu)選擇很重要!接受它!運用它!我看到有些人選擇了錯誤的技術(shù)路線(然后就炫耀說使用了 NodeJS)，然后又發(fā)現(xiàn)了更好的方法來實現(xiàn)他的任務(wù)，于是又放棄了 NodeJS。
◆ 如果談?wù)撈鹗录榛A(chǔ)的代碼實現(xiàn)和其可讀性，我相信幾乎每個人都會同意：回調(diào)式的代碼通常比正常流程形式的代碼更顯得混亂。
◆ 靜態(tài)類型的語言比動態(tài)類型的語言更具有優(yōu)勢。如果你不了解編譯器的內(nèi)部工作原理，就不要理會這一條了。
我的經(jīng)驗已足夠用來做一次測評的了。我有一臺常見的中等性能的機(jī)器(3G 內(nèi)存，雙核處理器)，做為對比，我會直接使用 Java NIO 來處理 HTTP 請求，以“hello world”做為響應(yīng);同樣的過程用 NodeJS 實現(xiàn)一次。
NodeJS 代碼非常的直接。我使用的版本是 Node 0.4.9。請注意，這個操作依賴于’http’模塊，因此又依賴于’net’，’stream’等模塊。這些都是 NodeJS 的基本功能模塊(我沒有做任何特別的事情)，它們依賴 V8 的 JIT 來實現(xiàn)高速的運行。
在 Java 上，我使用 Java 的 NIP 和 selector 通道來實現(xiàn) NodeJS 上的相同效果(單線程事件分發(fā))。代碼如預(yù)期中的一樣，有點長，因為要做循環(huán)處理。我盡量把所有的代碼都放到同一個文件里，所以，代碼沒有做模塊化等優(yōu)化。就是這兩個文件：Runner.java 和core.SocketSelectorCore.java。我使用了 HashMaps，字符串的 split，indexOf 等方法來實現(xiàn)基本的 HTTP 頭信息的分析，以此模擬一個普通的請求流程(讀，分析，回應(yīng)循環(huán))。我使用的方法并不是很高效，但一般的時候這些方法都不是問題。
現(xiàn)在使用“node test.js”來啟動 NodeJS，使用 Apache Benchmark (ab -c 1000 -n 100000)，1000的并發(fā)量[細(xì)節(jié)信息]，大概是每秒鐘4-5千個請求的壓力運行三次。
在拿我寫的 Java NIO 的程序測試之前，我需要提醒大家?guī)讉€事情。Java 是一個野獸，你有一大堆的選擇參數(shù)來調(diào)控 JVM 的垃圾堆棧大小。在我的測試中，我使用 JVM 運行參數(shù)是“java -server -XX:+PrintCompilation -XX:+UseConcMarkSweepGC Runner”。請注意，我使用的是 verbose 模式的 JIT 編譯，這樣我就能知道 JVM 已經(jīng)初始化完畢，可以開始測試了;我還改變了 GC 的方法(我試了各種方法，但看起來這個方法***)。當(dāng) JVM 完全啟動編譯后，我運行了相同的 Apache Benchmarks [細(xì)節(jié)信息]測試，Java 能處理每秒鐘8千-8千5百的請求。
我嘗試了不同的 JVM 堆的大小和一些其它的參數(shù);結(jié)果非常的有趣。在我的機(jī)器上，我一直能達(dá)到每秒6千的處理能力。降低并發(fā)量(-c 100) ，處理能力能達(dá)到11000/s。如果你仔細(xì)看，你會發(fā)現(xiàn)，相對于 NodeJS，我在請求里封裝了更多的字節(jié)，但這并沒有影響 Java 的處理能力。得到了這些數(shù)據(jù)后，我還使用 JRuby，用它那神奇的語法寫了一個很粗燥的代碼。對 JRuby 上一些參數(shù)的微調(diào)，用這個很簡單的程序，我仍然能得到每秒4000-4500請求的處理能力。
現(xiàn)在，剩下的問題就是，我為什么要做這些，這些說明了什么?我想答案是相當(dāng)明白。從個人的角度，我喜歡 Javascript 和 NodeJS，但我不接受人們說的“NodeJS 能做X但Y語言做不到“的言論。我認(rèn)為把 Java 或 PHP 或其它語言跟 NodeJS 進(jìn)行比較的行為是愚蠢的。Java 的 JIT 相當(dāng)?shù)南冗M(jìn)，而 Google 也把 V8 發(fā)展到了一個新的高度。像 Netty NIO 和 Mina 這樣的框架已經(jīng)存在很久了，只是因為 Java 的古怪的語法，對內(nèi)存的貪婪，以及學(xué)習(xí)曲線，才沒有引起人們的注意。我只是要破除“NodeJS 因為它的異步特征能處理更多的連接，能讓你寫回調(diào)風(fēng)格的代碼，也就是能寫出更好的代碼”的謬論。我的答案相當(dāng)?shù)暮唵危?ldquo;使用 Java 寫核心代碼，用 JRuby 或 Scala 的優(yōu)美語法封裝，你會得到一個更好的處理事件驅(qū)動系統(tǒng)的方法”。
原文：http://www.aqee.net/node-on-nails/
【編輯推薦】
