一个Node.JS 的进程只会运行在单个的物理核心上，就是因为这一点，在开发可扩展的服务器的时候就需要格外的注意。
因为有一系列稳定的API，加上原生扩展的开发来管理进程，所以有很多不同的方法来设计一个可以并行的Node.JS运用。在这篇博文里，我们就来比较下这些可能的架构。
这篇文章同时也介绍compute-cluster 模块：一个小型的Node.JS库，可以用来很方便的管理进程，从来二线分布式计算。
遇到的问题
我们在Mozilla Persona的项目中需要可以处理大量不同特征的请求，所以我们尝试用使用Node.JS。
为了不影响用户体验，我们设计的‘Interactive' 请求只需要轻量级的计算消耗，但是提供更快地反映时间使得UI没有卡壳的感觉。相比之下，‘Batch'操作大概需要半秒的处理时间，而且有可能由于其他的原因，会有更长的延迟。
为了更好的设计，我们找了很多符合我们当前需求的方法去解决。
考虑到扩展性和成本，我们列出以下关键需求：
效率：能有效的使用所有空闲的处理器
响应：我们的“应用”能实时快速的响应
优雅：当请求量过多到不能处理的时候，我们处理我们能处理的。不能处理的要清晰的把错误反馈
简单：我们的解决方案使用起来必须简单方便
通过以上几点我们可以清楚、有目标的去筛选
方案一：直接在主线程中处理.
当主线程直接处理数据的时候，结果很不好:
你不能充分利用多核CPU的优势，在交互式的请求/响应中，必须等待当前请求（或响应）处理完毕，毫无优雅可言。
这个方案唯一的优点是：够简单
function myRequestHandler(request, response) [ // Let's bring everything to a grinding halt for half a second. var results = doComputationWorkSync(request.somesuch); }
在 Node.JS 程序中，希望同时处理多个请求，又想同步进行处理，那你准备弄个焦头烂额吧。
方法 2: 是否使用异步处理.
如果在后台使用异步的方法来执行是否一定会有很大的性能改善呢?
答案是不一定.它取决于后台运行是否有意义
例如下面这种情况：如果在主线程上使用javascript或者本地代码进行计算时,性能并不比同步处理更好时,就不一定需要在后台用异步方法去处理
请阅读以下代码
function doComputationWork(input, callback) { // Because the internal implementation of this asynchronous // function is itself synchronously run on the main thread, // you still starve the entire process. var output = doComputationWorkSync(input); process.nextTick(function() { callback(null, output); }); } function myRequestHandler(request, response) [ // Even though this *looks* better, we're still bringing everything // to a grinding halt. doComputationWork(request.somesuch, function(err, results) { // ... do something with results ... });
}
关键点就在于NodeJS异步API的使用并不依赖于多进程的应用
方案三：用线程库来实现异步处理。
只要实现得当，使用本地代码实现的库，在 NodeJS 调用的时候是可以突破限制从而实现多线程功能的。
有很多这样的例子， Nick Campbell 编写的 bcrypt library 就是其中优秀的一个。
如果你在4核机器上拿这个库来作一个测试，你将看到神奇的一幕：4倍于平时的吞吐量，并且耗尽了几乎所有的资源！但是如果你在24核机器上测试，结果将不会有太大变化：有4个核心的使用率基本达到100%，但其他的核心基本上都处于空闲状态。
问题出在这个库使用了NodeJS内部的线程池，而这个线程池并不适合用来进行此类的计算。另外，这个线程池上限写死了，最多只能运行4个线程。
除了写死了上限，这个问题更深层的原因是：
使用NodeJS内部线程池进行大量运算的话，会妨碍其文件或网络操作，使程序看起来响应缓慢。
很难找到合适的方法来处理等待队列：试想一下，如果你队列里面已经积压了5分钟计算量的线程，你还希望继续往里面添加线程吗?
内建线程机制的组件库在这种情况下并不能有效地利用多核的优势，这降低了程序的响应能力，并且随着负载的加大，程序表现越来越差。
方案四：使用 NodeJS 的 cluster 模块
NodeJS 0.6.x 以上的版本提供了一个 ，允许创建“共享同一个socket”的一组进程，用来分担负载压力。
假如你采用了上面的方案，又同时使用 cluster 模块，情况会怎样呢？
这样得出的方案将同样具有同步处理或者内建线程池一样的缺点：响应缓慢，毫无优雅可言。
有时候，仅仅添加新运行实例并不能解决问题。
方案五：引入 compute-cluster 模块
在 Persona 中，我们的解决方案是，维护一组功能单一（但各不相同）的计算进程。
在这个过程中，我们编写了 compute-cluster 库。
这个库会自动按需启动和管理子进程，这样你就可以通过代码的方式来使用一个本地子进程的集群来处理数据。
使用例子: