关于Node.js语言的讨论（转）

本文是从 Node on nails! 这篇文章翻译而来。

在开始叙述这篇文章之前，我要非常清楚和明确的声明：“我并不是在鼓励你放弃 NodeJS 或转向 Java”。

我一直参与在这种争论中。在我的编程界的朋友中一直存在着一种误解，他们认为 NodeJS 语言是将来的趋势。我对 Javascript 是百分百的喜爱(不是自吹，我有一段时间曾被认为是 Javascript 专家，我写了很多喜欢 js 的文章);关于 Javascript 闭包的优美，原型模式编程风格的优势，我是毫无质疑。但是，如果把 Javascript 放到后台，这就完全是另外一种情况了。

每当我看到有人用一些重要的技术指标对 NodeJS 进行测评并宣称NodeJS 是世界上最快的语言时，我都会觉得好笑。(你只要用谷歌搜一下 NodeJS vs *你能想到的任何东西*，你就会找到像这样, 这样, 和 这样的东西。)

撇开我的质疑，NodeJS 的语言模式还是值得关注的，但我会在我的产品中使用它吗?我的问题就在这。我在使用 NodeJS 的过程中发现了一些非常严重的问题;给人的感觉相当的糟。我必须写一个完整的 HTTP 客户包来支持 Multipart 方式传送(现在这个包就是人们所知的 Reston)，这样我才能把文件发送到 Amazon S3 服务和其它一些 REST 服务里(当时没有任何支持 HTTP Multipart 传送的组件，HTTPS 也有问题，它折腾的我异常痛苦)，总而言之，我需要向读者们说下面几个观点：

◆ 并不是所有的 web 应用程序都需要大量的连接，你并不是每天都在开发一个聊天系统或一个 comet 系统。NodeJS 对处理某些事情很有优势，我们可以用到它。如果你是让我去在一个 IRC 服务器上开发一个基于 websocket 的聊天系统，我会推荐 NodeJS;但，如果你是让我去把邮件从你的帐号中取出然后存到 RDBMS 或 NOSQL 数据库中，那我就需要思量了。

◆ 技术架构选择很重要!接受它!运用它!我看到有些人选择了错误的技术路线(然后就炫耀说使用了 NodeJS)，然后又发现了更好的方法来实现他的任务，于是又放弃了 NodeJS。

◆ 如果谈论起事件为基础的代码实现和其可读性，我相信几乎每个人都会同意：回调式的代码通常比正常流程形式的代码更显得混乱。

◆ 静态类型的语言比动态类型的语言更具有优势。如果你不了解编译器的内部工作原理，就不要理会这一条了。

我的经验已足够用来做一次测评的了。我有一台常见的中等性能的机器(3G 内存，双核处理器)，做为对比，我会直接使用 Java NIO 来处理 HTTP 请求，以“hello world”做为响应;同样的过程用 NodeJS 实现一次。

NodeJS 代码非常的直接。我使用的版本是 Node 0.4.9。请注意，这个操作依赖于’http’模块，因此又依赖于’net’，’stream’等模块。这些都是 NodeJS 的基本功能模块(我没有做任何特别的事情)，它们依赖 V8 的 JIT 来实现高速的运行。

在 Java 上，我使用 Java 的 NIP 和 selector 通道来实现 NodeJS 上的相同效果(单线程事件分发)。代码如预期中的一样，有点长，因为要做循环处理。我尽量把所有的代码都放到同一个文件里，所以，代码没有做模块化等优化。就是这两个文件：Runner.java 和core.SocketSelectorCore.java。我使用了 HashMaps，字符串的 split，indexOf 等方法来实现基本的 HTTP 头信息的分析，以此模拟一个普通的请求流程(读，分析，回应循环)。我使用的方法并不是很高效，但一般的时候这些方法都不是问题。

现在使用“node test.js”来启动 NodeJS，使用 Apache Benchmark (ab -c 1000 -n 100000)，1000的并发量[细节信息]，大概是每秒钟4-5千个请求的压力运行三次。

在拿我写的 Java NIO 的程序测试之前，我需要提醒大家几个事情。Java 是一个野兽，你有一大堆的选择参数来调控 JVM 的垃圾堆栈大小。在我的测试中，我使用 JVM 运行参数是“java -server -XX:+PrintCompilation -XX:+UseConcMarkSweepGC Runner”。请注意，我使用的是 verbose 模式的 JIT 编译，这样我就能知道 JVM 已经初始化完毕，可以开始测试了;我还改变了 GC 的方法(我试了各种方法，但看起来这个方法最好)。当 JVM 完全启动编译后，我运行了相同的 Apache Benchmarks [细节信息]测试，Java 能处理每秒钟8千-8千5百的请求。

我尝试了不同的 JVM 堆的大小和一些其它的参数;结果非常的有趣。在我的机器上，我一直能达到每秒6千的处理能力。降低并发量(-c 100) ，处理能力能达到11000/s。如果你仔细看，你会发现，相对于 NodeJS，我在请求里封装了更多的字节，但这并没有影响 Java 的处理能力。得到了这些数据后，我还使用 JRuby，用它那神奇的语法写了一个很粗燥的代码。对 JRuby 上一些参数的微调，用这个很简单的程序，我仍然能得到每秒4000-4500请求的处理能力。

现在，剩下的问题就是，我为什么要做这些，这些说明了什么?我想答案是相当明白。从个人的角度，我喜欢 Javascript 和 NodeJS，但我不接受人们说的“NodeJS 能做X但Y语言做不到“的言论。我认为把 Java 或 PHP 或其它语言跟 NodeJS 进行比较的行为是愚蠢的。Java 的 JIT 相当的先进，而 Google 也把 V8 发展到了一个新的高度。像 Netty NIO 和 Mina 这样的框架已经存在很久了，只是因为 Java 的古怪的语法，对内存的贪婪，以及学习曲线，才没有引起人们的注意。我只是要破除“NodeJS 因为它的异步特征能处理更多的连接，能让你写回调风格的代码，也就是能写出更好的代码”的谬论。我的答案相当的简单：“使用 Java 写核心代码，用 JRuby 或 Scala 的优美语法封装，你会得到一个更好的处理事件驱动系统的方法”。

原文：http://www.aqee.net/node-on-nails/