Node.js事件与服务器端的线程编程

我们打算开始一个相当复杂的网站，预计会吸引很好的本地stream量，而我的老板已经告诉我要考虑/分析node.js作为服务端。 我认为可伸缩性和多核心支持可以用前面的Nginx或Cherokee来处理。

1）这个node.js准备好了吗？

2）服务器端的这种“事件/asynchronous”范例是否有可能支持繁忙的stream量和数据操作？ 考虑到“一切”正在一个单一的线程中处理的事实，所有的实时连接如果崩溃（虽然它很容易重新启动）将会丢失。

3）与基于线程的风格相比，基于事件的编程有什么优势？ 或相反亦然。 （我知道与线程切换相关的成本较高，但硬件可以用事件模型来压缩。）

以下是有趣但相互矛盾的（某种程度上）论文：

1） http://www.usenix.org/events/hotos03/tech/full_papers/vonbehren/vonbehren_html

2） http://pdos.csail.mit.edu/~rtm/papers/dabek:event.pdf

Answer 1

1. Node.js发展非常迅速，其大部分function都非常坚固，并且已经准备就绪。 然而，它有很多地方缺乏，如数据库驱动程序，jQuery和DOM，多个http头等。有很多模块来处理每个方面，但对于生产环境，你必须要小心挑选稳定的。

2. 实际上，从操作系统的angular度来看，使用单个线程的效率远高于一千（甚至是五十），而且我读过的基准testing（对不起，手边没有 – 会尝试find并链接它们后来）表明，它能够支持大stream量 – 不知道文件系统的访问。

3. 基于事件的编程是：

   1. 比线程代码更清洁的代码（在JavaScript中是这样）

   2. JavaScript引擎在处理事件和处理callback方面非常高效，而且它的轻松语言之一现在可以看到大多数运行时优化。

   3. 从控制stream程的angular度来看，难以适应。 随着事件，你永远不能确定的stream量。 不过，你也可以把它看作更dynamic的编程。 您可以将每个被触发的事件视为独立的。

   4. 由于上述原因，它在编程时强制您更加注重安全性。 从这个意义上说，它比线性系统更好，有时候你把消毒input当成是理所当然的。

两篇论文都比较陈旧。 对此的第一个基准，正如你所看到的，有一个关于这些研究的更新近的说明：

http://www.eecs.harvard.edu/~mdw/proj/seda/

它还引用了你关于他们做了什么的第二篇论文，但是拒绝评论它与基于事件的系统和基于线程的系统之间的比较的相关性:)

Answer 2

试着去发现真相

Answer 3

看什么是Node.js？ 我们在那里覆盖：

生产节点绝对是可能的，但远不如文档所承诺的那样“交钥匙”部署。 使用Node v0.6.x，“集群”已经集成到平台中，提供了一个基本的构build块，但是我的“production.js”脚本仍然有150行逻辑来处理像创build日志目录，回收死亡的工作人员等。对于“严重”的生产服务，您还需要做好准备，遏制传入的连接，并完成Apache为PHP所做的所有工作。 公平地说，Rails有这个确切的问题。 它是通过两个互补的机制来解决的：1）把Rails / Node放在一个专门的networking服务器（用C语言编写，并且testing到底和后面），比如Nginx（或者Apache / Lighttd）。 Web服务器可以有效地提供静态内容，访问日志logging，重写URL，终止SSL，强制执行访问规则以及pipe理多个子服务。 对于碰到实际节点服务的请求，Web服务器通过代理请求。 2）使用像“独angular兽”这样的框架来pipe理工作进程，定期回收它们等。我还没有find一个似乎完全被烘焙的节点服务框架; 它可能存在，但我还没有find它，仍然在我的手卷“production.js”中使用150行。