这是一个移动端工程师涉足前端和后端开发的学习笔记，如有错误或理解不到位的地方，万望指正。
方法/步骤
1、传统意义上的JavaScript运行在浏览器上，这是因为浏览器内核实际上分为两个部分:渲染引擎和JavaScript引擎。前者负责渲染HTML+CSS，后者则负责运行JavaScript。Chrome使用的JavaScript引擎是V8，它的速度非常快。Node.js是一个运行在服务端的框架，它的底层就使用了V8引擎。我们知道Apache+PHP以及Java的Servlet都可以用来开发**页，Node.js的作用与他们类似，只不过是使用JavaScript来开发。从定义上介绍完后，举一个简单的例子，新建一个app.js文件并输入以下内容:
2、一个简单的HTTPServer就算是写完了，输入nodeapp.js即可运行，随后访问便会看到输出结果。
3、为什么要用Node.js面对一个新技术，多问几个为什么总是好的。既然PHP、Python、Java都可以用来进行后端开发，为什么还要去学习Node.js？至少我们应该知道在什么场景下，选择Node.js更合适。总的来说，Node.js适合以下场景:实时性应用，比如在线多人协作工具，网页聊天应用等。以I/O为主的高并发应用，比如为客户端提供API，读取数据库。流式应用，比如客户端经常上传文件。前后端分离。
4、实际上前两者可以归结为一种，即客户端广泛使用长连接，虽然并发数士嫣轶嗄较高，但其中大部分是空闲连接。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/ONode.js确实可以在单线程中处理大量的并发请求，但这需要一定的编程技巧。我们回顾一下文章开头的代码，执行了app.js文件后控制台立刻就会有输出，而在我们访问网页时才会看到“Hello，World”。这是因为Node.js是事件驱动的，也就是说只有网络请求这一事件发生时，它的回调函数才会执行。当有多个请求到来时，他们会排成一个队列，依次等待执行。这看上去理所当然，然而如果没有深刻认识到Node.js运行在单线程上，而且回调函数是同步执行，同时还按照传统的模式来开发程序，就会导致严重的问题。举个简单的例子，这里的“HelloWorld”字符串可能是其他某个模块的运行结果。假设“HelloWorld”的生成非常耗时，就会阻塞当前网络请求的回调，导致下一次网络请求也无法被响应。解决方法很简单，采用异步回调机制即可。我们可以把用来产生输出结果的response参数传递给其他模块，并用异步的方式生成输出结果，最后在回调函数中执行真正的输出。这样的好处是，http.createServer的回调函数不会阻塞，因此不会出现请求无响应的情况。举个例子，我们改造一下server的入口，实际上如果要自己完成路由，大约也是这个思路:
5、第三方模块:
6、总之，在利用Node.js编程时，任何耗时操作一定要使用异步来完成，避免阻塞当前函数。因为你在为客户端提供服务，而所有代码总是单线程、顺序执行。
7、实际上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负载均衡非常容易实现，只要编辑配置文件即可:
8、默认的负载均衡规则鋈守踬痊是把网络请求依次分配到不同的端口，我们可以用least_conn标志把网络请求转发到连接数最少的Node.js进程，也可以用ip_hash保证同一个ip的请求棒瀹跏癞一定由同一个Node.js进程处理。多个Node.js进程可以充分发挥多核CPU的处理能力，也具有很强大的拓展能力。事件循环在Node.js中存在一个事件循环(EventLoop)，有过iOS开发经验的同学可能会觉得眼熟。没错，它和Runloop在一定程度上是类似的。一次完整的EventLoop也可以分为多个阶段(phase)，依次是poll、check、closecallbacks、timers、I/Ocallbacks、Idle。由于Node.js是事件驱动的，每个事件的回调函数会被注册到EventLoop的不同阶段。比如fs.readFile的回调函数被添加到I/Ocallbacks，setImmediate的回调被添加到下一次Loop的poll阶段结束后，process.nextTick()的回调被添加到当前phase结束后，下一个phase开始前。不同异步方法的回调会在不同的phase被执行，掌握这一点很重要，否则就会因为调用顺序问题产生逻辑错误。EventLoop不断的循环，每一个阶段内都会同步执行所有在该阶段注册的回调函数。这也正是为什么我在网络I/O部分提到，不要在回调函数中调用阻塞方法，总是用异步的思想来进行耗时操作。一个耗时太久的回调函数可能会让EventLoop卡在某个阶段很久，新来的网络请求就无法被及时响应。由于本文的目的是对Node.js有一个初步的，全面的认识。就不详细介绍EventLoop的每个阶段了，具体细节可以查看官方文档。可以看出EventLoop还是比较偏底层的，为了方便的使用事件驱动的思想，Node.js封装了EventEmitter这个类:
9、根据输出结果可知，self.emit(thing2)虽然后定义，但先被执行，这也完全符合EventLoop的调用规则。Node.js中很多模块都继承自EventEmitter，比如下一节中提到的fs.readStream，它用来创建一个可读文件流，打开文件、读取数据、读取完成时都会抛出相应的事件。数据流使用数据流的好处很明显，生活中也有真实写照。举个例子，老师布置了暑假作业，如果学生每天都做一点(作业流)，就可以比较轻松的完成任务。如果积压在一起，到了最后一天，面对堆成小山的作业本，就会感到力不从心。Server开发也是这样，假设用户上传1G文件，或者读取本地1G的文件。如果没有数据流的概念，我们需要开辟1G大小的缓冲区，然后在缓冲区满后一次性集中处理。如果是采用数据流的方式，我们可以定义很小的一块缓冲区，比如大小是1Mb。当缓冲区满后就执行回调函数，对这一小块数据进行处理，从而避免出现积压。实际上request和fs模块的文件读取都是一个可读数据流:
10、利用管道技术，可以把一个流中的内容写入到另一个流中:
11、不同的流还可以串联(Chain)起来，比如读取一个压缩文件，一边读取一边解压，并把解压内容写入到文件中:
12、总结对于高并发的长连接，事件驱动模型比线程轻量得多，多个Node.js进程配合负载均衡可以方便的进行拓展。因此Node.js非常适合为I/O密集型应用提供服务。但这种方式的缺陷就是不擅长处理CPU密集型任务。Node.js中通常以流的方式来描述数据，也对此提供了很好的封装。Node.js使用前端语言(JavaScript)开发，同时也是一个后端服务器，因此为前后端分离提供了一个良好的思路。我会在下一篇文章中对此进行分析。