1.简单的说nodeJs就是运行在服务器端的JavaScript。
2.nodeJs是一个基于chrome JavaScript运行时建立的一个平台。
3.nodeJs是一个事件驱动I/O服务端JavaScript环境，由c++编写，基于谷歌的v8引擎，v8引擎执行JavaScript的速度非常快，性能非常好。
NodeJs优缺点及适用场景讨论
node的特点
是一个JavaScript运行环境，c++实现。
依赖于chrome v8引擎进行代码解释。
事件驱动。
非堵塞I/O。
轻量、可伸缩，适于实时数据交互使用。
单进程，单线程。
模块化编程。
事件轮询。event loop
nodejs带来对系统的瓶颈的解决方案。
nodejs出现确实能为我们解决现实当中系统瓶颈提供了新的思路和解决方案。
并发连接
场景：银行排队办理业务
相关概念
系统线程模型
多线程、线程池模型
异步、事件驱动模型
系统线程模型
一个业务员，一次处理一个用户，无法接待下一个用户，除非完成业务。基于系统线程，thread-based
这种模式的问题显而易见，服务器端只有一个线程，并发请求到达只能处理一个，其余的要先等待，这就是堵塞，正在享受服务的请求堵塞后面的请求了。
多线程、线程池模型
多个业务员，高并发时还是需要排队。
多线程
这个模型已经比上一个模型有所进步，它调节服务器端的数量来提高对并发请求的接收和响应，但并发量高的时候，请求仍需要等待，它有一个更加严重的一个问题。
与服务器通讯的过程
服务器创建监听socket
绑定端口，listen
客户端发起连接
接收，为客户端产生新的socket
利用这个socket进行数据交互
带来的问题
连接数
socket句柄
系统内存资源
服务器端与客户端每建立一个连接，都要为这个连接分配一套配置的资源，主要体现为系统的内存资源，以PHP为例，维护一个连接可能需要20M的内存。这就是为什么并发量一大，就要多开服务器。
异步、事件驱动模型
异步机制，使不堵塞下一个用户点餐。
不用维护用户与厨师之间的连接。
通过回调，程序往下执行。
我们同样是要发起请求，等待服务器端响应；但是与银行例子不同的是，这次我们点完餐后拿到了一个号码，拿到号码，我们往往会在位置上等待，而在我们后面的请求会继续得到处理，同样是拿了一个号码然后到一旁等待，接待员能一直进行处理。
等到饭菜做号了，会喊号码，我们拿到了自己的饭菜，进行后续的处理（吃饭）。这个喊号码的动作在NodeJS中叫做回调（Callback），能在事件（烧菜，I/O）处理完成后继续执行后面的逻辑（吃饭），这体现了NodeJS的显著特点，异步机制、事件驱动整个过程没有阻塞新用户的连接（点餐），也不需要维护已经点餐的用户与厨师的连接。
基于这样的机制，理论上陆续有用户请求连接，NodeJS都可以进行响应，因此NodeJS能支持比Java、PHP程序更高的并发量虽然维护事件队列也需要成本，再由于NodeJS是单线程，事件队列越长，得到响应的时间就越长，并发量上去还是会力不从心。
总结一下NodeJS是怎么解决并发连接这个问题的：更改连接到服务器的方式，每个连接发射（emit）一个在NodeJS引擎进程中运行的事件（Event），放进事件队列当中，而不是为每个连接生成一个新的OS线程（并为其分配一些配套内存）。
I/O堵塞
ndoejs解决的另外一个问题就是I/O堵塞，需要从多个数据源拉取数据，然后进行处理。
（1）串行获取数据，这是我们一般的解决方案，以PHP为例
假如获取profile和timeline操作各需要1S，那么串行获取就需要2S。
（2）NodeJS非阻塞I/O，发射/监听事件来控制执行过程
NodeJS遇到I/O事件会创建一个线程去执行，然后主线程会继续往下执行的，因此，拿profile的动作触发一个I/O事件，马上就会执行拿timeline的动作，两个动作并行执行，假如各需要1S，那么总的时间也就是1S。它们的I/O操作执行完成后，发射一个事件，profile和timeline，事件代理接收后继续往下执行后面的逻辑，这就是NodeJS非阻塞I/O的特点。
node的优缺点
1.高并发
最重要的优点，据说可以应付百万级别的高并发。
适合做I/O密集型应用。
缺点
1.不适合做cpu的密集型应用，cpu密集型应用带来的挑战主要是
由于JavaScript单线程的原因，如果有长时间运行的计算，会导致cpu时间片不能释放，使得后续的i/o无法发起。
2.只能支持单核cpu，不能充分利用cpu
3.代码可靠性低，一旦代码某个环节奔溃，整个系统都奔溃。
解决方案
nginx方向代理，负载均衡，开多个进程，绑定多个端口。
开多个进程监听同一个端口，使用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密集、少量业务逻辑的场景。
