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