传统意义上的 JavaScript 运行在浏览器上，这是由于浏览器内核实际上分为两个部分:渲染引擎和 JavaScript 引擎。前者卖力渲染 HTML + CSS，后者则卖力运行 JavaScript。Chrome 利用的 JavaScript 引擎是 V8，它的速率非常快。
Node.js 是一个运行在做事真个框架，它的底层就利用了 V8 引擎。我们知道 Apache + PHP 以及 Java 的 Servlet 都可以用来开拓动态网页，Node.js 的浸染与他们类似，只不过是利用 JavaScript 来开拓。
从定义上先容完后，举一个大略的例子，新建一个 app.js 文件并输入以下内容:
var http = require('http');http.createServer(function (request, response) {response.writeHead(200, {'Content-Type': 'text/plain'}); // HTTP Response 头部response.end('Hello World\n'); // 返回数据 “Hello World”}).listen(8888); // 监听 8888 端口// 终端打印如下信息console.log('Server running at http://127.0.0.1:8888/');
这样，一个大略的 HTTP Server 就算是写完了，输入 node app.js 即可运行，随后访问 <localhost:8888> 便会看到输出结果。
为什么要用 Node.js
面对一个新技能，多问几个为什么总是好的。既然 PHP、Python、Java 都可以用来进行后端开拓，为什么还要去学习 Node.js？至少我们该当知道在什么场景下，选择 Node.js 更得当。
总的来说，Node.js 适宜以了局景:
实时性运用，比如在线多人协尴尬刁难象，网页谈天运用等。
以 I/O 为主的高并发运用，比如为客户端供应 API，读取数据库。
流式运用，比如客户端常常上传文件。
前后端分离。
实际上前两者可以归结为一种，即客户端广泛利用长连接，虽然并发数较高，但个中大部分是空闲连接。
Node.js 也有它的局限性，它并不适宜 CPU 密集型的任务，比如人工智能方面的打算，视频、图片的处理等。
当然，以上缺陷不是天花乱坠，或者去世记硬背，更不是人云亦云，须要我们对 Node.js 的事理有一定的理解，才能做出精确的判断。
根本观点
在先容 Node.js 之前，理清楚一些基本观点有助于更深入的理解 Node.js 。
并发
与客户端不同，做事端开拓者非常关心的一项数据是并发数，也便是这台做事器最多能支持多少个客户真个并发要求。从前的 C10K 问题便是谈论如何利用单台做事器支持 10K 并发数。当然随着软硬件性能的提高，目前 C10K 已经不再是问题，我们开始考试测验办理 C10M 问题，即单台做事器如何处理百万级的并发。
在 C10K 提出时，我们还在利用 Apache 做事器，它的事情事理是每当有一个网络要求到达，就 fork 出一个子进程并在子进程中运行 PHP 脚本。实行完脚本后再把结果发回客户端。
这样可以确保不同进程之间互不滋扰，纵然一个进程出问题也不影响全体做事器，但是缺陷也很明显:进程是一个比较重的观点，拥有自己的堆和栈，占用内存较多，一台做事器能运行的进程数量有上限，大约也就在几千旁边。
虽然 Apache 后来利用了 FastCGI，但实质上只是一个进程池，它减少了创建进程的开销，但无法有效提高并发数。
Java 的 Servlet 利用了线程池，即每个 Servlet 运行在一个线程上。线程虽然比进程轻量，但也是相对的。每个线程独享的栈的大小是 1M，依然不足高效。除此以外，多线程编程会带来各种麻烦，这一点想必程序员们都深有体会。
如果不该用线程，还有两种办理方案，分别是利用协程(coroutine)和非壅塞 I/O。协程比线程更加轻量，多个协程可以运行在同一个线程中，并由程序员自己卖力调度，这种技能在 Go 措辞中被广泛利用。而非壅塞 I/O 则被 Node.js 用来处理高并发的场景。
非壅塞 I/O
这里所说的 I/O 可以分为两种: 网络 I/O 和文件 I/O，实际上两者高度类似。 I/O 可以分为两个步骤，首先把文件(网络)中的内容拷贝到缓冲区，这个缓冲区位于操作系统独占的内存区域中。随后再把缓冲区中的内容拷贝到用户程序的内存区域中。
对付壅塞 I/O 来说，从发起读要求，到缓冲区就绪，再到用户进程获取数据，这两个步骤都是壅塞的。
非壅塞 I/O 实际上是向内核轮询，缓冲区是否就绪，如果没有则连续实行其他操作。当缓冲区就绪时，讲缓冲区内容拷贝到用户进程，这一步实际上还是壅塞的。
I/O 多路复用技能是指利用单个线程处理多个网络 I/O，我们常说的 select、epoll 便是用来轮询所有 socket 的函数。比如 Apache 采取了前者，而 Nginx 和 Node.js 利用了后者，差异在于后者效率更高。由于 I/O 多路复用实际上还是单线程的轮询，因此它也是一种非壅塞 I/O 的方案。
异步 I/O 是最空想的 I/O 模型，然而可惜的是真正的异步 I/O 并不存在。 Linux 上的 AIO 通过旗子暗记和回调来通报数据，但是存在毛病。现有的 libeio 以及 Windows 上的 IOCP，实质上都是利用线程池与壅塞 I/O 来仿照异步 I/O。
Node.js 线程模型
很多文章都提到 Node.js 是单线程的，然而这样的说法并不严谨，乃至可以说很不卖力，由于我们至少会想到以下几个问题:
Node.js 在一个线程中如何处理并发要求？
Node.js 在一个线程中如何进行文件的异步 I/O？
Node.js 如何重复利用做事器上的多个 CPU 的处理能力？
网络 I/O
Node.js 确实可以在单线程中处理大量的并发要求，但这须要一定的编程技巧。我们回顾一下文章开头的代码，实行了 app.js 文件后掌握台急速就会有输出，而在我们访问网页时才会看到 “Hello，World”。
这是由于 Node.js 是事宜驱动的，也便是说只有网络要求这一事宜发生时，它的回调函数才会实行。当有多个要求到来时，他们会排成一个行列步队，依次等待实行。
这看上去天经地义，然而如果没有深刻认识到 Node.js 运行在单线程上，而且回调函数是同步实行，同时还按照传统的模式来开拓程序，就会导致严重的问题。举个大略的例子，这里的 “Hello World” 字符串可能是其他某个模块的运行结果。假设 “Hello World” 的天生非常耗时，就会壅塞当前网络要求的回调，导致下一次网络要求也无法被相应。
办理方法很大略，采取异步回调机制即可。我们可以把用来产生输出结果的 response 参数通报给其他模块，并用异步的办法天生输出结果，末了在回调函数中实行真正的输出。这样的好处是，http.createServer 的回调函数不会壅塞，因此不会涌现要求无相应的情形。
举个例子，我们改造一下 server 的入口，实际上如果要自己完成路由，大约也是这个思路:
var http = require('http');var output = require('./string') // 一个第三方模块http.createServer(function (request, response) {output.output(response); // 调用第三方模块进行输出}).listen(8888);
第三方模块:
function sleep(milliSeconds) { // 仿照卡顿var startTime = new Date().getTime(); while (new Date().getTime() < startTime + milliSeconds);}function outputString(response) {sleep(10000); // 壅塞 10s response.end('Hello World\n'); // 先实行耗时操作，再输出}exports.output = outputString;
总之，在利用 Node.js 编程时，任何耗时操作一定要利用异步来完成，避免壅塞当前函数。由于你在为客户端供应做事，而所有代码总是单线程、顺序实行。
如果初学者看到这里还是无法理解，建议阅读 “Nodejs 入门” 这本书，或者阅读下文关于事宜循环的章节。
文件 I/O
异步是为了优化体验，避免卡顿。而真正节省处理韶光，利用 CPU 多核性能，还是要靠多线程并行处理。
实际上 Node.js 在底层掩护了一个线程池。之前在根本观点部分也提到过，不存在真正的异步文件 I/O，常日是通过线程池来仿照。线程池中默认有四个线程，用来进行文件 I/O。
须要把稳的是，我们无法直接操作底层的线程池，实际上也不须要关心它们的存在。线程池的浸染仅仅是完成 I/O 操作，而非用来实行 CPU 密集型的操作，比如图像、视频处理，大规模打算等。
如果有少量 CPU 密集型的任务须要处理，我们可以启动多个 Node.js 进程并利用 IPC 机制进行进程间通讯，或者调用外部的 C++/Java 程序。如果有大量 CPU 密集型任务，那只能解释选择 Node.js 是一个缺点的决定。
榨干 CPU
到目前为止，我们知道了 Node.js 采取 I/O 多路复用技能，利用单线程处理网络 I/O，利用线程池和少量线程仿照异步文件 I/O。那在一个 32 核 CPU 上，Node.js 的单线程是否显得鸡肋呢？
答案是否定的，我们可以启动多个 Node.js 进程。不同于上一节的是，进程之间不须要通讯，它们各自监听一个端口，同时在最外层利用 Nginx 做负载均衡。
Nginx 负载均衡非常随意马虎实现，只要编辑配置文件即可:
http{upstream sampleapp { // 可选配置项，如 least_conn，ip_hashserver 127.0.0.1:3000;server 127.0.0.1:3001; // ... 监听更多端口}....server{listen 80;...location / {proxy_pass http://sampleapp; // 监听 80 端口，然后转发}}
默认的负载均衡规则是把网络要求依次分配到不同的端口，我们可以用 least_conn 标志把网络要求转发到连接数最少的 Node.js 进程，也可以用 ip_hash 担保同一个 ip 的要求一定由同一个 Node.js 进程处理。
多个 Node.js 进程可以充分发挥多核 CPU 的处理能力，也具有很强大的拓展能力。
事宜循环
在 Node.js 中存在一个事宜循环(Event Loop)，有过 iOS 开拓履历的同学可能会以为眼熟。没错，它和 Runloop 在一定程度上是类似的。
一次完全的 Event Loop 也可以分为多个阶段(phase)，依次是 poll、check、close callbacks、timers、I/O callbacks 、Idle。
由于 Node.js 是事宜驱动的，每个事宜的回调函数会被注册到 Event Loop 的不同阶段。比如 fs.readFile 的回调函数被添加到 I/O callbacks，setImmediate 的回调被添加到下一次 Loop 的 poll 阶段结束后，process.nextTick() 的回调被添加到当前 phase 结束后，下一个 phase 开始前。
不同异步方法的回调会在不同的 phase 被实行，节制这一点很主要，否则就会由于调用顺序问题产生逻辑缺点。
Event Loop 不断的循环，每一个阶段内都会同步实行所有在该阶段注册的回调函数。这也正是为什么我在网络 I/O 部分提到，不要在回调函数中调用壅塞方法，总是用异步的思想来进行耗时操作。一个耗时太久的回调函数可能会让 Event Loop 卡在某个阶段良久，新来的网络要求就无法被及时相应。
由于本文的目的是对 Node.js 有一个初步的，全面的认识。就不详细先容 Event Loop 的每个阶段了，详细细节可以查看官方文档。
可以看出 Event Loop 还是比较偏底层的，为了方便的利用事宜驱动的思想，Node.js 封装了 EventEmitter 这个类:
var EventEmitter = require('events');var util = require('util');function MyThing() {EventEmitter.call(this);setImmediate(function (self) {self.emit('thing1');}, this);process.nextTick(function (self) {self.emit('thing2');}, this);}util.inherits(MyThing, EventEmitter);var mt = new MyThing();mt.on('thing1', function onThing1() { console.log(\"大众Thing1 emitted\"大众);});mt.on('thing2', function onThing1() { console.log(\公众Thing2 emitted\"大众);});
根据输出结果可知，self.emit(thing2) 虽然后定义，但先被实行，这也完备符合 Event Loop 的调用规则。
Node.js 中很多模块都继续自 EventEmitter，比如下一节中提到的 fs.readStream，它用来创建一个可读文件流， 打开文件、读取数据、读取完成时都会抛出相应的事宜。
数据流
利用数据流的好处很明显，生活中也有真实写照。举个例子，老师支配了暑假作业，如果学生每天都做一点(作业流)，就可以比较轻松的完成任务。如果积压在一起，到了末了一天，面对堆成小山的作业本，就会感到力不从心。
Server 开拓也是这样，假设用户上传 1G 文件，或者读取本地 1G 的文件。如果没有数据流的观点，我们须要开辟 1G 大小的缓冲区，然后在缓冲区满后一次性集中处理。
如果是采取数据流的办法，我们可以定义很小的一块缓冲区，比如大小是 1Mb。当缓冲区满后就实行回调函数，对这一小块数据进行处理，从而避免涌现积压。
实际上 request 和 fs 模块的文件读取都是一个可读数据流:
var fs = require('fs');var readableStream = fs.createReadStream('file.txt');var data = '';readableStream.setEncoding('utf8');// 每次缓冲区满，处理一小块数据 chunkreadableStream.on('data', function(chunk) {data+=chunk;});// 文件流全部读取完成readableStream.on('end', function() { console.log(data);});
利用管道技能，可以把一个流中的内容写入到另一个流中:
var fs = require('fs');var readableStream = fs.createReadStream('file1.txt');var writableStream = fs.createWriteStream('file2.txt');readableStream.pipe(writableStream);
不同的流还可以串联(Chain)起来，比如读取一个压缩文件，一边读取一边解压，并把解压内容写入到文件中:
var fs = require('fs');var zlib = require('zlib');fs.createReadStream('input.txt.gz').pipe(zlib.createGunzip()).pipe(fs.createWriteStream('output.txt'));
Node.js 供应了非常简洁的数据流操作，以上便是大略的利用先容。
总结
对付高并发的长连接，事宜驱动模型比线程轻量得多，多个 Node.js 进程合营负载均衡可以方便的进行拓展。因此 Node.js 非常适宜为 I/O 密集型运用供应做事。但这种办法的毛病便是不善于处理 CPU 密集型任务。
Node.js 中常日以流的办法来描述数据，也对此供应了很好的封装。
Node.js 利用前端措辞(JavaScript) 开拓，同时也是一个后端做事器，因此为前后端分离供应了一个良好的思路。我会不才一篇文章中对此进行剖析。
