Node.Js 学习随笔2

Node 旨在解决什么问题？

Node 公开宣称的目标是 “旨在提供一种简单的构建可伸缩网络程序的方法”。当前的服务器程序有什么问题？我们来做个数学题。在 Java™ 和 PHP 这类语言中，每个连接都会生成一个新线程，每个新线程可能需要 2 MB 配套内存。在一个拥有 8 GB RAM 的系统上，理论上最大的并发连接数量是 4,000 个用户。随着您的客户端基础的增长，您希望您的 web 应用程序支持更多用户，这样，您必须添加更多服务器。当然，这会增加业务成本，尤其是服务器成本、运输成本和人工成本。除这些成本上升外，还有一个技术问 题：用户可能针对每个请求使用不同的服务器，因此，任何共享资源都必须在所有服务器之间共享。例如，在 Java 中，静态变量和缓存需要在每个服务器上的 JVMs 之间共享。这就是整个 web 应用程序架构中的瓶颈：一个服务器能够处理的并发连接的最大数量。

Node 解决这个问题的方法是：更改连接连接到服务器的方式。每个连接都创建一个进程，该进程不需要配套内存块，而不是为每个连接生成一个新的 OS 线程（并向其分配一些配套内存）。Node 声称它绝不会死锁，因为它根本不允许使用锁，它不会直接阻塞 I/O 调用。Node 还宣称，运行它的服务器能支持数万个并发连接。事实上，Node 通过将整个系统中的瓶颈从最大连接数量更改到单个系统的流量来改变服务器面貌。

现在您有了一个能处理数万条并发连接的程序，那么您能通过 Node 实际构建什么呢？如果您有一个 web 应用程序需要处理这么多连接，那将是一件很 “恐怖” 的事！那是一种 “如果您有这个问题，那么它根本不是问题” 的问题。在回答上面的问题之前，我们先看看 Node 如何工作以及它被设计的如何运行。

 

Node 肯定不是什么

没错，Node 是一个服务器程序。但是，它肯定不 像 Apache 或 Tomcat。那些服务器是独立服务器产品，可以立即安装并部署应用程序。通过这些产品，您可以在一分钟内启动并运行一个服务器。Node 肯定不是这种产品。Apache 能添加一个 PHP 模块来允许开发人员创建动态 web 页，使用 Tomcat 的程序员能部署 JSPs 来创建动态 web 页。Node 肯定不是这种类型。

在 Node 的早期阶段（当前是 version 0.4.6），它还不是一个 “运行就绪” 的服务器程序，您还不能安装它，向其中放置文件，拥有一个功能齐全的 web 服务器。即使是要实现 web 服务器在安装完成后启动并运行这个基本功能，也还需要做大量工作。

 

 

Node 如何工作

Node 本身运行 V8 JavaScript。等等，服务器上的 JavaScript？没错，您没有看错。服务器端 JavaScript 是一个相对较新的概念，这个概念是大约两年前在 developerWorks 上讨论 Aptana Jaxer 产品时提到的（参见 参考资料）。尽管 Jaxer 一直没有真正流行，但这个理念本身并不是遥不可及的 — 为何不能在服务器上使用客户机上使用的编程语言？

什么使 V8？V8 JavaScript 引擎是 Google 用于他们的 Chrome 浏览器的底层 JavaScript 引擎。很少有人考虑 JavaScript 在客户机上实际做了些什么？实际上，JavaScript 引擎负责解释并执行代码。使用 V8，Google 创建了一个以 C++ 编写的超快解释器，该解释器拥有另一个独特特征；您可以下载该引擎并将其嵌入任何 应用程序。它不仅限于在一个浏览器中运行。因此，Node 实际上使用 Google 编写的 V8 JavaScript 引擎并将其重建为在服务器上使用。太完美了！既然已经有一个不错的解决方案可用，为何还要创建一种新语言呢？

 

它对什么有好处？

正如您此前所看到的，Node 非常适合以下情况：您预计可能有很高的流量，而在响应客户端之前服务器端逻辑和处理所需不一定是巨大的。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 不擅长的领域：

• 动态创建的页

  目前，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，不过那完全是另一个主题了。）

 

   注：本文参考CSDN 以及 developerWorks作者Mike Abernethy的文章整理而来