node_优缺点

一、单线程，主线程一个，底层工作线程多个。

Nodejs与操作系统交互，我们在 Javascript中调用的方法，最终都会通过 process.binding 传递到 C/C++ 层面，最终由他们来执行真正的操作。Node.js 即这样与操作系统进行互动。

nodejs所谓的单线程，只是主线程是单线程，所有的网络请求或者异步任务都交给了内部的线程池去实现，本身只负责不断的往返调度，由事件循环不断驱动事件执行。

Nodejs之所以单线程可以处理高并发的原因，得益于libuv层的事件循环机制，和底层线程池实现。

Event loop就是主线程从主线程的事件队列里面不停循环的读取事件，驱动了所有的异步回调函数的执行，Event loop总共7个阶段，每个阶段都有一个任务队列，当所有阶段被顺序执行一次后，event loop 完成了一个 tick。

二、异步、非堵塞I/O

非阻塞 I/O，也叫异步 I/O，显然对应的就是阻塞式 I/O。

传统的服务器语言大多是多线程、阻塞式 I/O。这也是 Node 与众不同的地方，对于传统的服务器语言，在与用户建立连接时，每一个连接都是一个线程。当有十万个用户连接时，服务器上就会有十万个线程。而阻塞式 I/O 是指，当一个线程在执行 I/O 操作时，这个线程会阻塞，等待 I/O 操作完成后继续执行。

举个例子可以更好理解，比如我们到一个餐馆吃饭，这个餐馆比较高级，服务员是一对一服务（每个用户都是一个线程），从我们坐下开始，服务员就把菜单给你，然后在旁边等你点菜（等待 I/O 操作），当你看完菜单，把要点的菜告诉服务员（ I/O 操作结束后线程继续执行）。在你看菜单的过程中，服务员其实是被闲置的，如果你一直看，他就会一直等，直到你点完（ I/O 操作结束）。这就是阻塞式 I/O。

阻塞式 I/O 必须要多线程，就这个例子来看，如果只有一个服务员（单线程），那当店里同时有十个顾客时，他需要一个一个等待顾客看菜单然后点菜，那后面的顾客要等待的时间就会很长，显然这个餐馆的服务就会很差（服务器性能差）。

所以传统的服务器都是多线程、阻塞式 I/O，也就是相当于有多个服务员（线程），每个进来的顾客都分配到一个服务员（线程），然后你看菜单时在旁边等候（阻塞式 I/O ）。很明显这样的服务是让顾客最舒服的，但是对于餐馆老板来说很难受，因为要雇佣大量的服务员。因此传统的方式成本是比较大的。要有性能足够好的服务器才能支撑大量的线程。但他的优点也很明显，比如某一桌客人与服务员发生争吵（线程崩了！），不会影响到其他顾客，因为每一桌都有专门的服务员负责，因此只会对当前用户产生影响。

上面的例子应该可以很好地理解多线程、阻塞式 I/O 。而 node 的特性是单线程、非阻塞时 I/O 。node 最大的优势就是性能强，同样的服务器性能使用 node 可以比传统的服务器语言多容纳一百倍的用户（对于不同的任务有不同的差别， I/O 操作越多，node优势越明显，如果都是 CPU 计算任务，那他俩几乎没有区别（上面的例子中，忽略顾客的看菜单时间）。

还是用上面的例子再比喻一下单线程、非阻塞式 I/O 。这应该是个规模比较小的餐馆，或者说老板比较穷，雇不起大量的服务员，因此只能雇佣一个服务员。当有顾客来时，服务员把菜单送过去，顾客开始看菜单（ I/O 操作），这个时候，服务员是被释放了的，他不用等待顾客看菜单，服务员说：“您先看着菜单，点好了叫我”（回调函数）。这个时候这个服务员就可以抽身去服务其他的顾客。用这种模式的话，一个服务员就可以服务多位顾客，而且不需要等待 I/O ，只需要随时监听就行了，顾客点完后会主动叫服务员（执行回调函数）。

单线程、非阻塞式 I/O 的优势就是性能强，一个人服务员就可以解决大量顾客。但是他的缺点也很明显，比如有一桌顾客和服务员又吵架了（线程崩了！），那这些顾客就都完了，因为所有人都在等这一个服务员。也就是说，如果线程崩掉了，那与这个服务器连接的所有用户都会崩溃。

三.V8虚拟机
根据百度百科解释，Node.js是一套用来编写高性能网络服务器的JavaScript工具包。Node.js是一个可以快速构建网络服务及应用的平台，该平台的构建是基于Chrome's JavaScript runtime，也就是说，实际上它是对GoogleV8引擎（应用于Google Chrome浏览器)进行了封装。V8引擎执行Javascript的速度非常快，性能非常好。

NodeJS并不是提供简单的封装，然后提供API调用，如果是这样的话那么它就不会有现在这么火了。Node对一些特殊用例进行了优化，提供了替代的API，使得V8在非浏览器环境下运行得更好。例如，在服务器环境中，处理二进制数据通常是必不可少的，但Javascript对此支持不足，因此，V8.Node增加了Buffer类，方便并且高效地处理二进制数据。因此，Node不仅仅简单的使用了V8,还对其进行了优化，使其在各环境下更加给力。
四.事件驱动
Node.js 使用事件驱动模型，当web server接收到请求，就把它关闭然后进行处理，然后去服务下一个web请求。

当这个请求完成，它被放回处理队列，当到达队列开头，这个结果被返回给用户。

这个模型非常高效可扩展性非常强，因为webserver一直接受请求而不等待任何读写操作。（这也被称之为非阻塞式IO或者事件驱动IO）

在事件驱动模型中，会生成一个主循环来监听事件，当检测到事件时触发回调函数。

缺点：

1. 不适合CPU密集型应用；CPU密集型应用给Node带来的挑战主要是：由于JavaScript单线程的原因，如果有长时间运行的计算（比如大循环），将会导致CPU时间片不能释放，使得后续I/O无法发起；

解决方案：分解大型运算任务为多个小任务，使得运算能够适时释放，不阻塞I/O调用的发起；

2. 只支持单核CPU，不能充分利用CPU

3. 可靠性低，一旦代码某个环节崩溃，整个系统都崩溃

原因：单进程，单线程

解决方案：

1. Nnigx反向代理，负载均衡，开多个进程，绑定多个端口；

2. 开多个进程监听同一个端口，使用cluster模块；

4. 开源组件库质量参差不齐，更新快，向下不兼容

5. Debug不方便，错误没有stack trace

五. 适合NodeJS的场景

1. RESTful API

这是NodeJS最理想的应用场景，可以处理数万条连接，本身没有太多的逻辑，只需要请求API，组织数据进行返回即可。它本质上只是从某个数据库中查找一些值并将它们组成一个响应。由于响应是少量文本，入站请求也是少量的文本，因此流量不高，一台机器甚至也可以处理最繁忙的公司的API需求。

2. 统一Web应用的UI层

目前MVC的架构，在某种意义上来说，Web开发有两个UI层，一个是在浏览器里面我们最终看到的，另一个在server端，负责生成和拼接页面。

不讨论这种架构是好是坏，但是有另外一种实践，面向服务的架构，更好的做前后端的依赖分离。如果所有的关键业务逻辑都封装成REST调用，就意味着在上层只需要考虑如何用这些REST接口构建具体的应用。那些后端程序员们根本不操心具体数据是如何从一个页面传递到另一个页面的，他们也不用管用户数据更新是通过Ajax异步获取的还是通过刷新页面。

3. 大量Ajax请求的应用

例如个性化应用，每个用户看到的页面都不一样，缓存失效，需要在页面加载的时候发起Ajax请求，NodeJS能响应大量的并发请求。　　总而言之，NodeJS适合运用在高并发、I/O密集、少量业务逻辑的场景。