node.js是由Ryan Dahl编写的服务器端js framework，其初衷是为了编写更为高效的web服务器。
使用当前最快的google v8 js engine
单线程。因为不需要考虑并发，所以也就没有了锁和阻塞的概念，大大简化编程。
事件回调模型。所有的异步操作，比如数据库访问都是通过事件触发的。
完全发挥javascript作为动态解释语言的强大威力。开发人员可以自由的使用一切特性比如closure，并且不需要担心跨浏览器支持（因为是服务端）。
你可能会问单线程怎么处理多用户请求呢？事实上Ryan观察到web访问的一个事实：每次web请求服务周期最耗费时间的往往是IO操作，包括读写文件、数据库操作、开启网络连接访问某个rest api等等。真正web server内部的运算只占很小的比例。比如浏览器访问一个页面，几乎大部分时间都花在IO的读写上了，从读文件一直到向socket写数据，花在页面后端代码的计算量则微乎其微。
举个不很恰当的例子来说明单线程和回调的作用。假设web server是一个银行，每个浏览器的访问相当于客户去窗口取一笔钱。客户在某个窗口办理业务相当于服务器从本地硬盘读写文件。这个操作会花很长时间（相信大家深有体会），由于窗口数有限所以需要一个排队叫号系统就是我们的nodejs线程（相当于apache不过是单线程的）。当窗口有空时营业员就通知排号系统请叫下一位，但是喇叭一次只播放一个叫号的声音，所以所有通知都存放在了一个事件队列中，排号系统报完一个号再处理下一个直到队列空为止，然后就处于idle状态。如果把叫号类比后端代码执行(如.aspx的页面生命周期)，他的速度要比处理银行业务快的多，所以只需要一个喇叭就足够了。由于没有多线程的切换消耗，所有计算都作用在了实际的计算上从而提高了处理量。
工作原理:
Javascript是一个事件驱动语言，Node利用了这个优点，编写出可扩展性高的服务器。Node采用了一个称为“事件循环(event loop）”的架构，使得编写可扩展性高的服务器变得既容易又安全。提高服务器性能的技巧有多种多样。Node选择了一种既能提高性能，又能减低开发复杂 度的架构。这是一个非常重要的特性。并发编程通常很复杂且布满地雷。Node绕过了这些，但仍提供很好的性能。
Node采用一系列“非阻塞”库来支持事件循环的方式。本质上就是为文件系统、数据库之类的资源提供接口。当 你向文件系统发送一个请求时，无需等待硬盘（寻址并检索文件），硬盘准备好的时候非阻塞接口会通知Node。该模型以可扩展的方式简化了对慢资源的访问， 直观，易懂。尤其是对于熟悉onmouseover、onclick等DOM事件的用户，更有一种似曾相识的感觉。
Node 非常适合以下情况:
1.可能有很高的流量，而在响应客户端之前服务器端逻辑和处理所需不一定是巨大的。
Node 表现出众的典型示例包括：
RESTful API
提供 RESTful API 的 web 服务接收几个参数，解析它们，组合一个响应，并返回一个响应（通常是较少的文本）给用户。这是适合 Node 的理想情况，因为您可以构建它来处理数万条连接。它还不需要大量逻辑；它只是从一个数据库查找一些值并组合一个响应。由于响应是少量文本，入站请求时少量文本，因此流量不高，一台机器甚至也可以处理最繁忙的公司的 API 需求。
Twitter 队列
想像一下像 Twitter 这样的公司，它必须接收 tweets 并将其写入一个数据库。实际上，每秒几乎有数千条 tweets 达到，数据库不可能及时处理高峰时段需要的写入数量。Node 成为这个问题的解决方案的重要一环。如您所见，Node 能处理数万条入站 tweets。它能迅速轻松地将它们写入一个内存排队机制（例如 memcached），另一个单独进程可以从那里将它们写入数据库。Node 在这里的角色是迅速收集 tweet 并将这个信息传递给另一个负责写入的进程。想象一下另一种设计 — 一个常规 PHP 服务器自己试图处理对数据库的写入 — 每个 tweet 将在写入数据库时导致一个短暂的延迟，这是因为数据库调用正在阻塞通道。由于数据库延迟，一台这样设计的机器每秒可能只能处理 2000 条入站 tweets。 每秒 100 万条 tweets 需要 500 个服务器。相反，Node 能处理每个连接而不会阻塞通道，从而能捕获尽可能多的 tweets。一个能处理 50,000 条 tweets 的 Node 机器只需要 20 个服务器。
映像文件服务器
一个拥有大型分布式网站的公司（比如 Facebook 或 Flickr）可能会决定将所有机器只用于服务映像。Node 将是这个问题的一个不错的解决方案，因为该公司能使用它编写一个简单的文件检索器，然后处理数万条连接。Node 将查找映像文件，返回文件或一个 404 错误，然后什么也不用做。这种设置将允许这类分布式网站减少它们服务映像、.js 和 .css 文件等静态文件所需的服务器数量。
下面是 Node 不擅长的领域：
动态创建的页
目前，Node 没有提供一种默认方法来创建动态页。例如，使用 JavaServer Pages (JSP) 技术时，可以创建一个在 <% for (int i=0; i<20; i++) { } %> 这样的 JSP 代码段中包含循环的 index.jsp 页。Node 不支持这类动态的、HTML 驱动的页面。同样，Node 不太适合作为 Apache 和 Tomcat 这样的网页服务器。因此，如果您想在 Node 中提供这样一个服务器端解决方案，必须自己编写整个解决方案。PHP 程序员不想在每次部署 web 应用程序时都编写一个针对 Apache 的 PHP 转换器，当目前为止，这正是 Node 要求您做的。
关系数据库重型应用程序
Node 的目的是快速、异步和非阻塞。数据库并不一定分享这些目标。它们是同步和阻塞的，因为读写时对数据库的调用在结果生成之前将一直阻塞通道。因此，一个每个请求都需要大量数据库调用、大量读取、大量写入的 web 应用程序非常不适合 Node，这是因为关系数据库本身就能抵销 Node 的众多优势。（新的 NoSQL 数据库更适合 Node，不过那完全是另一个主题了。）
使用当前最快的google v8 js engine
单线程。因为不需要考虑并发，所以也就没有了锁和阻塞的概念，大大简化编程。
事件回调模型。所有的异步操作，比如数据库访问都是通过事件触发的。
完全发挥javascript作为动态解释语言的强大威力。开发人员可以自由的使用一切特性比如closure，并且不需要担心跨浏览器支持（因为是服务端）。
你可能会问单线程怎么处理多用户请求呢？事实上Ryan观察到web访问的一个事实：每次web请求服务周期最耗费时间的往往是IO操作，包括读写文件、数据库操作、开启网络连接访问某个rest api等等。真正web server内部的运算只占很小的比例。比如浏览器访问一个页面，几乎大部分时间都花在IO的读写上了，从读文件一直到向socket写数据，花在页面后端代码的计算量则微乎其微。
举个不很恰当的例子来说明单线程和回调的作用。假设web server是一个银行，每个浏览器的访问相当于客户去窗口取一笔钱。客户在某个窗口办理业务相当于服务器从本地硬盘读写文件。这个操作会花很长时间（相信大家深有体会），由于窗口数有限所以需要一个排队叫号系统就是我们的nodejs线程（相当于apache不过是单线程的）。当窗口有空时营业员就通知排号系统请叫下一位，但是喇叭一次只播放一个叫号的声音，所以所有通知都存放在了一个事件队列中，排号系统报完一个号再处理下一个直到队列空为止，然后就处于idle状态。如果把叫号类比后端代码执行(如.aspx的页面生命周期)，他的速度要比处理银行业务快的多，所以只需要一个喇叭就足够了。由于没有多线程的切换消耗，所有计算都作用在了实际的计算上从而提高了处理量。
工作原理:
Javascript是一个事件驱动语言，Node利用了这个优点，编写出可扩展性高的服务器。Node采用了一个称为“事件循环(event loop）”的架构，使得编写可扩展性高的服务器变得既容易又安全。提高服务器性能的技巧有多种多样。Node选择了一种既能提高性能，又能减低开发复杂 度的架构。这是一个非常重要的特性。并发编程通常很复杂且布满地雷。Node绕过了这些，但仍提供很好的性能。
Node采用一系列“非阻塞”库来支持事件循环的方式。本质上就是为文件系统、数据库之类的资源提供接口。当 你向文件系统发送一个请求时，无需等待硬盘（寻址并检索文件），硬盘准备好的时候非阻塞接口会通知Node。该模型以可扩展的方式简化了对慢资源的访问， 直观，易懂。尤其是对于熟悉onmouseover、onclick等DOM事件的用户，更有一种似曾相识的感觉。
Node 非常适合以下情况:
1.可能有很高的流量，而在响应客户端之前服务器端逻辑和处理所需不一定是巨大的。
Node 表现出众的典型示例包括：
RESTful API
提供 RESTful API 的 web 服务接收几个参数，解析它们，组合一个响应，并返回一个响应（通常是较少的文本）给用户。这是适合 Node 的理想情况，因为您可以构建它来处理数万条连接。它还不需要大量逻辑；它只是从一个数据库查找一些值并组合一个响应。由于响应是少量文本，入站请求时少量文本，因此流量不高，一台机器甚至也可以处理最繁忙的公司的 API 需求。
Twitter 队列
想像一下像 Twitter 这样的公司，它必须接收 tweets 并将其写入一个数据库。实际上，每秒几乎有数千条 tweets 达到，数据库不可能及时处理高峰时段需要的写入数量。Node 成为这个问题的解决方案的重要一环。如您所见，Node 能处理数万条入站 tweets。它能迅速轻松地将它们写入一个内存排队机制（例如 memcached），另一个单独进程可以从那里将它们写入数据库。Node 在这里的角色是迅速收集 tweet 并将这个信息传递给另一个负责写入的进程。想象一下另一种设计 — 一个常规 PHP 服务器自己试图处理对数据库的写入 — 每个 tweet 将在写入数据库时导致一个短暂的延迟，这是因为数据库调用正在阻塞通道。由于数据库延迟，一台这样设计的机器每秒可能只能处理 2000 条入站 tweets。 每秒 100 万条 tweets 需要 500 个服务器。相反，Node 能处理每个连接而不会阻塞通道，从而能捕获尽可能多的 tweets。一个能处理 50,000 条 tweets 的 Node 机器只需要 20 个服务器。
映像文件服务器
一个拥有大型分布式网站的公司（比如 Facebook 或 Flickr）可能会决定将所有机器只用于服务映像。Node 将是这个问题的一个不错的解决方案，因为该公司能使用它编写一个简单的文件检索器，然后处理数万条连接。Node 将查找映像文件，返回文件或一个 404 错误，然后什么也不用做。这种设置将允许这类分布式网站减少它们服务映像、.js 和 .css 文件等静态文件所需的服务器数量。
下面是 Node 不擅长的领域：
动态创建的页
目前，Node 没有提供一种默认方法来创建动态页。例如，使用 JavaServer Pages (JSP) 技术时，可以创建一个在 <% for (int i=0; i<20; i++) { } %> 这样的 JSP 代码段中包含循环的 index.jsp 页。Node 不支持这类动态的、HTML 驱动的页面。同样，Node 不太适合作为 Apache 和 Tomcat 这样的网页服务器。因此，如果您想在 Node 中提供这样一个服务器端解决方案，必须自己编写整个解决方案。PHP 程序员不想在每次部署 web 应用程序时都编写一个针对 Apache 的 PHP 转换器，当目前为止，这正是 Node 要求您做的。
关系数据库重型应用程序
Node 的目的是快速、异步和非阻塞。数据库并不一定分享这些目标。它们是同步和阻塞的，因为读写时对数据库的调用在结果生成之前将一直阻塞通道。因此，一个每个请求都需要大量数据库调用、大量读取、大量写入的 web 应用程序非常不适合 Node，这是因为关系数据库本身就能抵销 Node 的众多优势。（新的 NoSQL 数据库更适合 Node，不过那完全是另一个主题了。）
扫一扫
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
