引言
近段时间听说了Node.js，很多文章表述这个事件驱动模型多么多么优秀，应用在服务器开发中有很大的优势，本身对此十分感性去，决定深入了解一下，由此也引发了一些对程序设计的思考，记录下来。
什么是Node.js
Node.js在官网上是这样定义的:“一个搭建在Chrome JavaScript运行时上的平台，用于构建高速、可伸缩的网络程序。Node.js采用的事件驱动、非阻塞I/O模型使它既轻量又高效，是构建运行在分布式设备上的数据密集型实时程序的完美选择。”
Node.js的事件驱动
简单来说就是只有一个线程，所有IO操作（网络，文件访问等）都是异步的，通过回调来响应处理。
Node.js做了什么
Node.js将网络，文件，数据库等操作等都实现了异步接口，让开发者所设计的程序只跑在一个线程上，易于设计出性能良好的高并发网络程序。
如果不采用异步的方式来实现，可能的处理方式有针对每一个连接建立一个线程处理，有多少个连接就建立多少个线程，每一个线程独立不互相干扰。乍一看这么处理是没有问题的，但是要知道线程的创建是有代价的，如果按照这么处理在连接数上万，就已经很难处理过来的，创建线程浪费了大量资源。
Node.js的劣势
从前文的描述中可以看出Node.js的事件驱动机制在IO密集型应用中，是有比较大的优势的，那么考虑另外一种场景，CPU密集型应用（如数据加密，压缩）。由于Node.js的代码是在一个线程中运行的，这种情况下事件循环就被阻塞住了。当然Node.js也提供了一下其他机制（nextTick，child_process等）解决这种场景，但是看起来这些实现可以说是比较丑陋的。
关于程序设计的思考
感觉Node.js的设计在IO密集型应用上有优势是值得在程序设计中参考借鉴的，如果在支持多线程的语言中采用如下设计是不是既拥有事件驱动的优势又避免了在CPU密集型场景下的劣势呢？
- 整体业务逻辑基于事件驱动的处理，可以避免许多多线程操作中繁琐、易错的地方。
- CPU密集高运算的场景使用线程处理，主线程回调处理结果。
最后
对Node.js也只是简单的了解一下，并未深入学习，有什么错漏大家勿喷。