背景
之前几篇系列文章简单介绍了node.js的安装配置及基本操作：
Node.js系列——（1）安装配置与基本使用
Node.js系列——（2）发起get/post请求
Node.js系列——（3）连接DB
接下来，我们就来整体认识下node.js
node.js
node.js官网对它的介绍是这样的：
Node.js 是一个基于 Chrome V8 引擎的 JavaScript 运行环境。
Node.js 使用了一个事件驱动、非阻塞式 I/O 的模型，使其轻量又高效。
V8引擎
V8使用C++开发，并在谷歌浏览器中使用。在运行JavaScript之前，相比其它的JavaScript的引擎转换成字节码或解释执行，V8将其编译成原生机器码（IA-32, x86-64, ARM, or MIPS CPUs），并且使用了如内联缓存（inline caching）等方法来提高性能。
有了这些功能，JavaScript程序在V8引擎下的运行速度媲美二进制程序。
具体内容可参考：为什么V8引擎这么快？
事件驱动
传统技术实现下，当一个请求到达时，会分配一个线程，该线程会占用内存，当请求的任务做完时，线程才会退出并释放内存。但node.js只有一个单线程，所有的连接都由这一个线程来处理。
网上流传着一个生动的例子：
传统技术下的处理方式——>餐馆里一个服务员接待一桌客人，服务这一桌客人点餐、上菜、陪侍，到客人离开；
node.js的处理方式——>餐馆里只有一个服务员，当有客人来，他就去招待点餐，点餐结束后就去处理其他事情，可以去招待其他客人，也可以去上菜。
Node.js是单进程单线程的，那他是如何做到高性能的呢？
主要通过事件驱动和异步回调。node中几乎所有的事件机制都是使用观察者模式实现的。
说到观察者模式，就要先明确主题Subject（即被观察者）和观察者Observer。
如下图所示，在node中
事件扮演者Subject的角色，而这个事件上的
处理函数就是观察者。还拿上面的餐馆服务员的例子来说，客人进入餐馆这一动作就是一个事件，当这一事件触发时，他的观察者就会进行一系列操作（比如招待入座、点餐等）。
由于node是单线程的，因此在实际场景中会有很多事件堆积到一起，这也就是事件队列。
在上图中所示：
1） 如果有任务或请求到达，会被放入右侧的Event Queue（事件队列）中。事件队列中每个任务会存放两个东西，处理方法和回调方法，即function和callback。
2）事件循环Event Loop会根据事件队列中的任务列表进行执行，这时分两种情况：
- 如果取到的任务是non-Blocking非阻塞的，那么可以直接执行然后调用他相对应的回调函数。
- 如果任务是Blocking阻塞的（如IO操作等），就不会直接执行，而是从线程池Thread Pool中取出一个线程来执行，当该线程完成后，就会调用回调函数，接下来的操作跟上一种情况一样了。到最后该线程的任务执行完毕，那么线程所占用的资源被释放。
Tips:
当执行过程中遇到I/O阻塞(读取文件、查询数据库、请求套接字、访问远程服务等)时，事件循环线程不会停下等待结果,转而继续执行队列中的下一个任务,不会在事件循环线程中执行。在函数执行时,Node.js在事件队列中放置回调函数,它的顺序根据函数的完成快慢决定。
具体内容参考：Node.js的事件驱动模型
Rest API
Rest API 这部分就不用多说了，node采用这种方式来规范接口和数据的形式，用法也很简单。
场景
前面说了这么多node.js的优点，那是不是任何场景都优先选择他呢？肯定不是的，我们来看下他的缺点。
1、node.js不适合做CPU密集型的工作
我们不能说node.js完全是单线程的，因为当遇到阻塞式的任务时，他会交给其他线程去处理。但除此之外，node是单线程的。因此，如果是CPU密集的场景下，选择使用node，无法使他的优势发挥出来。
2、大量的计算可能会使node单线程暂时失去反应
3、如果有一个Exception影响到了node的核心事件循环，那么整个实例就会崩溃。
