以下文章来自于：http://www.infoq.com/cn/articles/nodejs-in-front-end-engineer-view

?

? ? ? 在我接触JavaScript（无论浏览器还是NodeJS）的时间里，总是遇到有朋友有多线程的需求。而在NodeJS方面，有朋友甚至直接说到，NodeJS是单线程的，无法很好的利用多核CPU。

但是，我们可以用Ajax和Web Worker回应这个误解。当Ajax请求发送之后，除非是同步请求，否则其余的JavaScript代码会很快被执行到。在Ajax发送完成，直到接收到响应的这段时间里，这个网络请求并不会阻塞JavaScript的执行，而网络请求已经发生，这是必然的事。那么，答案就很明显了，JavaScript确实是执行在单线程上的，但是，整个Web应用执行的宿主（浏览器）并非以单线程的方式在执行。而Web Worker的产生，就是直接为了解决JavaScript与UI占用同一线程造成的UI响应问题的，它能新开一条线程去执行JavaScript。诚然，在前端的浏览器中，由于前端的JavaScript与UI占据同一线程，执行JavaScript确实为UI响应造成了一定程度上的麻烦。但是，除非用到超大的循环语句执行JavaScript，或是用阻塞式的Ajax，或是太过频繁的定时器执行外，JavaScript并没有给前端应用带来明显的问题，所以也很少有朋友抱怨JavaScript是单线程而不能很好利用多核CPU的问题，因为没有因此出现性能瓶颈。

同理，NodeJS中的JavaScript也确实是在单线程上执行，但是作为宿主的NodeJS，它本身并非是单线程的，NodeJS在I/O方面有动用到一小部分额外的线程协助实现异步。程序员没有机会直接创建线程，这也是有的同学想当然的认为NodeJS的单线程无法很好的利用多核CPU的原因，他们甚至会说，难以想象由多人一起协作开发一个单线程的程序。

NodeJS 封装了内部的异步实现后，导致程序员无法直接操作线程，也就造成所有的业务逻辑运算都会丢到JavaScript的执行线程上，这也就意味着，在高并发请求的时候，I/O的问题是很好的解决了，但是所有的业务逻辑运算积少成多地都运行在JavaScript线程上，形成了一条拥挤的JavaScript运算线程。NodeJS的弱点在这个时候会暴露出来，单线程执行运算形成的瓶颈，拖慢了I/O的效率。这大概可以算得上是密集运算情况下无法很好利用多核 CPU的缺点。这条拥挤的JavaScript线程，给I/O形成了性能上限。

但是，事情又并非绝对的。回到前端浏览器中，为了解决线程拥挤的情况，Web Worker应运而生。而同样，Node也提供了child_process.fork来创建Node的子进程。在一个Node进程就能很好的解决密集 I/O的情况下，fork出来的其余Node子进程可以当作常驻服务来解决运算阻塞的问题（将运算分发到多个Node子进程中上去，与Apache创建多个子进程类似）。当然child_process/Web Worker的机制永远只能解决单台机器的问题，大的Web应用是不可能一台服务器就能完成所有的请求服务的。拜NodeJS在I/O上的优势，跨OS的多Node之间通信的是不算什么问题的。解决NodeJS的运算密集问题的答案其实也是非常简单的，就是将运算分发到多个CPU上。请参考文章后的multi-node的性能测试，可以看到在多Node进程的情景下，响应请求的速度被大幅度提高（感谢CNode社区的snoopy友情测试）。

在文章的写作过程中，Node最新发布的0.6.0版本，新增了cluster模块。该模块的作用是可以通过fork的方式创建出多个子进程实例，这些实例会自动共享相同的侦听端口。你可以根据当前计算机上的CPU数量来创建相应的实例数，以此达到分发请求，充分利用CPU的目的。详情请参阅官方文档。在之前的解决运算密集问题中，工程师需要multi-node这样的库或者其他方案去手动分发请求，在cluster模块的支持下，可以释放掉工程师在解决此问题上的大部分精力。

事件式编程

延续上一节的讨论。我们知道NodeJS/JavaScript具有异步的特性，从NodeJS的API设计中可以看出来，任何涉及I/O的操作，几乎都被设计成事件回调的形式，且大多数的类都继承自EventEmitter。这么做的好处有两个，一个是充分利用无阻塞I/O的特性，提高性能；另一个好处则是封装了底层的线程细节，通过事件消息留出业务的关注点给编程者，从而不用关注多线程编程里牵扯到的诸多技术细节。

从现实的角度而言，事件式编程也更贴合现实。举一个业务场景为例：家庭主妇在家中准备中餐，她需要完成两道菜，一道拌黄瓜，一道西红柿蛋汤。以PHP为例，家庭主妇会先做完拌黄瓜，接着完成西红柿蛋汤，是以顺序/串行执行的。但是现在突然出了一点意外，凉拌黄瓜需要的酱油用光了，需要她儿子出门帮她买酱油回来。那么PHP家庭主妇在叫她儿子出门打酱油的这段时间都是属于等待状态的，直到酱油买回来，才会继续下一道菜的制作。那么，在NodeJS的家庭主妇又会是怎样一个场景呢，很明显，在等待儿子打酱油回来的时间里，她可以暂停凉拌黄瓜的制作，而直接进行西红柿蛋汤的过程，儿子打完酱油回来，继续完成她的凉拌黄瓜。没有浪费掉等待的时间。实例伪代码如下：

var mother = new People();
var child = new People();
child.buySoy(function (soy) {
    mother.cook("cucumber", soy);
});
mother.cook("tomato");

接下来，将上面这段代码转换为基于事件/任务异步模式的代码：

var proxy = new EventProxy();
var mother = new People();
proxy.bind("cook_cucumber", function (soy) {
    mother.cook("cucumber", soy);
});
proxy.bind("cook_tomato", function () {
    mother.cook("tomato");
});
var child = new People();
child.buySoy(function (soy) {
    proxy.trigger("cucumber", soy);
});
proxy.trigger("tomato");

代码量多了很多，但是业务逻辑点都是很清楚的：通过bind方法预定义了cook_cucumber和cook_tomato两个任务。这里的bind方法可以认为是await的消息式实现，需要第一个参数来标识该任务的名字，流程在执行的过程中产生的消息会触发这些任务执行。可以看出，事件式编程中，用户只需要关注它所需要的几个业务事件点就可以，中间的等待都由底层为你调配好了。这里的代码只是举例事件/任务异步模式而用，在简单的场景中，第一段代码即可。做NodeJS的编程，会更感觉是在做现实的业务场景设计和任务调度，没有顺序保证，程序结构更像是一个状态机。

个人觉得在事件式编程中，程序员需要转换一下思维，才能接受和发挥好这种异步/无阻塞的优势。同样，这种事件式编程带来的一个问题就在于业务逻辑是松散和碎片式的。这对习惯了顺序式，Promise式编程的同学而言，接受它是比较痛苦的事情，而且这种散布的业务逻辑对于非一开始就清楚设计的人而言，阅读存在相当大的问题。

我提到事件式编