摘要：PHP开发技术在这几年依然比较火热，也有越来越多的开发者加入到了PHP开发阵营，在复杂的框架和冗余的代码面前，选择合适的PHP库就显得 尤为重要，优秀的PHP库可以为你节省很多代码和编码时间。 下面是一些非常有用的PHP类库，相信一定可以为你的WEB开发提供更好和更为快速的方法。 图表库 下面的类库可以让你很简的创建复杂的图表和图片。当然，它们需要GD库的支持。 pChart – 一个可以创建统计图的库。 Libchart – 这也是一个简单的统计图库。 JpGraph – 一个面向对象的图片创建类。 Open Flash Chart – 这是一个基于Flash的统计图。 RSS 解析 解释RSS并是一件很单调的事情，不过幸好你有下面的类库可以帮助你方便地读取RSS的Feed。 MagpieRSS – 开源的PHP版RSS解析器，据说功能强大，未验证。 SimplePie – 这是一个非常快速，而且易用的RSS和Atom 解析库。 缩略图生成 phpThumb – 功能很强大，如何强大还是自己去体会吧。 支付 你的网站需要处理支付方面的事情？需要一个和支付网关的程序？下面这个程序可以帮到你。 PHP Payment Library – 支持Paypal, Authorize.net 和2Checkout (2CO) OpenID PHP-OpenID – 支持OpenID的一个PHP库。OpenID是帮助你使用相同的用户名和口令登录不同的网站的一种解决方案。如果你对OpenID不熟悉的话，你可以到这里看看：http://openid.net.cn/ 数据为抽象/对象关系映射ORM ADOdb – 数据库抽象 Doctrine – 对象关系映射Object relational mapper (ORM) ，需要 PHP 5.2.3+ 版本，一个非常强大的database abstraction layer (DBAL). Propel – 对象关系映射框架- PHP5 Outlet – 也是关于对象关系映射的一个工具。 注：对象关系映射（Object Relational Mapping，简称ORM）是一种为了解决面向对象与关系数据库存在的互不匹配的现象的技术。 简单的说，ORM是通过使用描述对象和数据库之间映射的元数据，将程序中的对象自动持久化到关系数据库中。本质上就是将数据从一种形式转换到另外一种形 式。 这也同时暗示者额外的执行开销；然而，如果ORM作为一种中间件实现，则会有很多机会做优化，而这些在手写的持久层并不存在。 更重要的是用于控制转换的元数据需要提供和管理；但是同样，这些花费要比维护手写的方案要少；而且就算是遵守ODMG规范的对象数据库依然需要类级别的元 数据。 PDF 生成器 FPDF – 这量一个可以让你生成PDF的纯PHP类库。 Excel 相关 你的站点需要生成Excel？没有问题，下面这两个类库可以让你轻松做到这一点。 php-excel […]
View DetailsIf you are a PHP developer or graphic web designer you must be aware and know about the basic tools one requires by which to perform certain web related tasks. However, most experienced web developers and designers constantly look for the new tools which they can use to make their workflow and web related tasks easier, faster, and better. In this article we have collected a few of the best PHP Tools and Applications to assist you within your work related tasks. We hope you will find them […]
View DetailsPHP标准库 (SPL)的目的就是提供一组接口，让开发者在PHP5中充分利用面向对象编程。因此本文我们搜集了8个最好的，能辅助开发者简化他们的工作，为他们的开发任务服务的PHP库。 如果你喜欢本文，也许你对我们的其他文章感兴趣：8个给开发者的最好的PHP工具和应用 1. Whoops : 更好的php错误报告库 Whoops是一个易于处理和调试错误的PHP库 。它提供基于堆栈的的错误处理和好看的错误界面。它有个简单的API来处理异常，跟踪帧和数据，并能和任何框架整合（随时可用的集成端和Silex）。 Source 2. PhpFastCache phpFastCache 是一个开源的 PHP 缓存库，只提供一个简单的 PHP 文件，可方便集成到已有项目，支持多种缓存方法，包括：apc, memcache, memcached, wincache, files, pdo and mpdo。可通过简单的 API 来定义缓存的有效时间。 Source 3. Eden : 功能强大的 PHP 库 Eden是一个开源且免费的PHP快速开发类库。它包含很多组件用来自动加载、事件驱动、文档系统、缓存、模板、国际化、数据库、web服务、支付网关、装载和云服务技术。为了给我们最好的选择，他已经将现有的函数实现了与谷歌服务（Youtube, Drive, Contacts, Analytics, Checkout, Maps），Facebook（脸谱）, Twitter（推特）, Tumblr（轻博客）, PayPal（贝宝）, Authorize.net, FedEx（联邦快递）, UPS（联合包裹服务公司）, Amazon + Rackspace Clouds（亚马逊+Rackspace 云）等服务的交互。 Source 4. Php Error PHP Error 是一个开源的 PHP 库，用于转换标准的 PHP 错误信息，主要用于开发过程中的调试。PHP Error 紧密集成到 PHP 环境中，显示带语法高亮的错误提示。 Source 5. Detector Detector是一个开源的PHP类库用于检测关于用户的浏览器环境的许多东西。它可以获得浏览器的使用和浏览器的html5 css3功能,分析是否移动电话、平板电脑、桌面或网页爬虫和其他项如：颜色深度, 视口尺寸、cookie等支持。类库可以自动适应新的浏览器、版本和设备对每一个浏览器使用独特的用户代理字符。 Source 6. Opauth Opauth 是一个开源的 PHP 库，提供了 OAuth 认证的支持，让你无需关注不同 Provider 之间的差别，提供统一标准的访问方法。目前支持 Google、Twitter 和 Facebook，其他的 Provider 支持也将陆续提供。同时也支持处理任何 […]
View Details|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 162 163 164 165 166 167 168 169 170 171 172 173 174 175 176 177 178 179 180 181 182 183 184 185 186 187 188 189 190 191 192 193 194 195 196 |
using System; using System.Collections.Generic; using System.Linq; using System.Text; using System.Reflection; using System.Data; using System.Data.Common; using System.Web.Script.Serialization; using System.Globalization; using System.Collections; using System.IO; using System.Drawing; using System.IO.Compression; using System.Runtime.Serialization.Formatters.Binary; namespace Pub.Class { public static class ArrayExtensions { public static bool IsNullEmpty(this Array array) { return array == null || array.Length == 0; } public static bool IsNullEmpty(this ArrayList list) { return (list == null) || (list.Count == 0); } public static int GetInArrayID(this string[] stringArray, string strSearch, bool caseInsensetive) { for (int i = 0; i < stringArray.Length; i++) { if (caseInsensetive) { if(strSearch.ToLower() == stringArray[i].ToLower()) return i; } else { if(strSearch == stringArray[i]) return i; } } return -1; } public static int GetInArrayID(this string[] stringArray, string strSearch) { return GetInArrayID(stringArray, strSearch, true); } public static string ToDelimitedString<T>(this T[] array, string format, string delimiter) { if (array == null || array.Length == 0) return string.Empty; if (format.IsNullEmpty()) format = "{0}"; StringBuilder builder = new StringBuilder(); for (int index = 0; index < array.Length; ++index) { if (index != 0) builder.Append(delimiter); builder.AppendFormat(format, array[index]); } return builder.ToString(); } public static T[] RemoveDuplicates<T>(this T[] array) { ArrayList al = new ArrayList(); for (int i = 0; i < array.Length; i++) { if (!al.Contains(array[i])) al.Add(array[i]); } return (T[])al.ToArray(typeof(T)); } public static T[] Slice<T>(this T[] array, int start, int end) { if (start >= array.Length) { start = 0; end = 0; } if (end < 0) end = array.Length - start - end; if (end <= start) end = start; if (end >= array.Length) end = array.Length-1; int len = end - start + 1; T[] res = new T[len]; for (int i = 0; i < len; i++) res[i] = array[i + start]; return res; } public static string Join<T>(this T[] array, string splitStr) { StringBuilder sb = new StringBuilder(); foreach(T info in array) { sb.AppendFormat("{0}{1}", info.ToString(), splitStr); } return sb.ToString().Left(sb.Length - splitStr.Length); } public static void Action<T>(this T[] inArray, Action<T, Int32> inAction) { for (int i0 = 0; i0 < inArray.GetLength(0); i0++) { inAction(inArray[i0], i0); } } public static void Action<T>(this T[,] inArray, Action<T, Int32, Int32> inAction) { for (int i0 = 0; i0 < inArray.GetLength(0); i0++) { for (int i1 = 0; i1 < inArray.GetLength(1); i1++) inAction(inArray[i0, i1], i0, i1); } } public static void Action<T>(this T[,,] inArray, Action<T, Int32, Int32, Int32> inAction) { for (int i0 = 0; i0 < inArray.GetLength(0); i0++) { for (int i1 = 0; i1 < inArray.GetLength(1); i1++) { for (int i2 = 0; i2 < inArray.GetLength(2); i2++) inAction(inArray[i0, i1, i2], i0, i1, i2); } } } public static void Action<T>(this T[,] inArray, Int32 inDimension, Int32 inIndex, Action<T, Int32> inAction) { if (inDimension == 0) { for (int i = 0; i < inArray.GetLength(1); i++) inAction(inArray[inIndex, i], i); } else if (inDimension == 1) { for (int i = 0; i < inArray.GetLength(0); i++) inAction(inArray[i, inIndex], i); } else { throw new ArgumentException("inDimension must be zero or one"); } } public static void Action<T>(this T[,,] inArray, Int32 inDimension, Int32 inIndex, Action<T, Int32, Int32> inAction) { if (inDimension == 0) { for (int i0 = 0; i0 < inArray.GetLength(1); i0++) { for (int i1 = 0; i1 < inArray.GetLength(2); i1++) inAction(inArray[inIndex, i0, i1], i0, i1); } } else if (inDimension == 1) { for (int i0 = 0; i0 < inArray.GetLength(0); i0++){ for (int i1 = 0; i1 < inArray.GetLength(2); i1++) inAction(inArray[i0, inIndex, i1], i0, i1); } } else if (inDimension == 2) { for (int i0 = 0; i0 < inArray.GetLength(0); i0++){ for (int i1 = 0; i1 < inArray.GetLength(1); i1++) inAction(inArray[i0, i1, inIndex], i0, i1); } } else { throw new ArgumentException("inDimension must be zero or one or two"); } } public static Image ToImage(this byte[] bytes) { if (bytes != null) { MemoryStream ms = new MemoryStream(bytes, 0, bytes.Length); ms.Write(bytes, 0, bytes.Length); return Image.FromStream(ms, true); } return null; } public static bool ToFile(this byte[] bytes, string fileName, FileMode fileMode) { bool returnValue = true; FileAccess fileAccess = FileAccess.ReadWrite; if (fileMode == FileMode.Append) fileAccess = FileAccess.Write; FileStream fs = new FileStream(fileName, fileMode, fileAccess); BinaryWriter bw = new BinaryWriter(fs); try { bw.Write(bytes); } catch (Exception) { returnValue = false; } finally { fs.Close(); bw.Close(); } return returnValue; } public static byte[] Compress(this byte[] data) { using (MemoryStream output = new MemoryStream()) { using (DeflateStream def = new DeflateStream(output, CompressionMode.Compress)) { def.Write(data, 0, data.Length); } return output.ToArray(); } } public static byte[] Decompress(this byte[] data) { using (MemoryStream input = new MemoryStream()) { input.Write(data, 0, data.Length); input.Position = 0; using (DeflateStream def = new DeflateStream(input, CompressionMode.Decompress)) { using (MemoryStream output = new MemoryStream()) { byte[] buff = new byte[64]; int read = -1; read = def.Read(buff, 0, buff.Length); while (read > 0) { output.Write(buff, 0, read); read = def.Read(buff, 0, buff.Length); } def.Close(); return output.ToArray(); } } } } public static T Decompress<T>(this byte[] compressedData) where T : class { return compressedData.Decompress().Deserialize<T>(); } public static T Deserialize<T>(this byte[] data) where T : class { var formatter = new BinaryFormatter(); using (MemoryStream ms = new MemoryStream(data)) return formatter.Deserialize(ms) as T; } public static bool IsInArray(this string[] stringArray, string strSearch, bool caseInsensetive) { return stringArray.GetInArrayID(strSearch, caseInsensetive) >= 0; } public static bool IsInArray(this string[] stringarray, string str) { return stringarray.IsInArray(str, false); } public static bool IsInIPArray(this string[] iparray, string ip) { string[] userip = ip.Split(@"."); for (int ipIndex = 0; ipIndex < iparray.Length; ipIndex++) { string[] tmpip = iparray[ipIndex].Split(@"."); int r = 0; for (int i = 0; i < tmpip.Length; i++) { if (tmpip[i] == "*") return true; if (userip.Length > i) { if (tmpip[i] == userip[i]) r ++; else break; } else break; } if (r == 4) return true; } return false; } //Action<string, int> MsgW3 = (s, i) => { Msg.Write(s + i); Msg.Write("<br />"); }; //"test1,test2,test3".Split(',').Action<string>(MsgW3); } } |
转自：http://www.cnblogs.com/livexy/archive/2010/07/06/1772502.html
View Details上一篇专栏简单介绍了Connect模块的基本架构，它的执行模型十分简单，中间件机制也使得它十分易于扩展，具备良好的可伸缩性。在Connect的良好机制下，我们本章开始将逐步解开Connect生态圈中中间件部分，这部分给予Connect良好的功能扩展。 静态文件中间件 也许你还记得我曾经写过的Node.js静态文件服务器实战，那篇文章中我叙述了如何利用Node.js实现一个静态文件服务器的许多技术细节，包括路由实现，MIME，缓存控制，传输压缩，安全、欢迎页、断点续传等。但是这里我们不需要去亲自处理细节，Connect的static中间件为我们提供上述所有功能。代码只需寥寥3行即可：
|
1 2 3 |
var connect = require('connect'); var app = connect(); app.use(connect.static(__dirname + '/public')); |
在项目中需要临时搭建静态服务器，也无需安装apache之类的服务器，通过NPM安装Connect之后，三行代码即可解决需求。这里需要提及的是在使用该模块的一点性能相关的细节。 动静分离 前一章提及，app.use()方法在没有指定路由信息时，相当于app.use("/", middleware)。这意味着静态文件中间件将会在处理所有路径的请求。在动静态请求混杂的场景下，静态中间件会在动态请求时也调用fs.stat来检测文件系统是否存在静态文件。这造成了不必要的系统调用，使得性能降低。 解决影响性能的方法既是动静分离。利用路由检测，避免不必要的系统调用，可以有效降低对动态请求的性能影响。
|
1 |
app.use('/public', connect.static(__dirname + '/public')); |
在大型的应用中，动静分离通常无需到一个Node.js实例中进行，CDN的方式直接在域名上将请求分离。小型应用中，适当的进行动静分离即可避免不必要的性能损耗。 缓存策略 缓存策略包含客户端和服务端两个部分。客户端的缓存，主要是利用浏览器对HTTP协议响应头中cache-control和expires字段的支持。浏览器在得到明确的相应头后，会将文件缓存在本地，依据cache-control和expires的值进行相应的过期策略。这使得重复访问的过程中，浏览器可以从本地缓存中读取文件，而无需从网络读取文件，提升加载速度，也可以降低对服务器的压力。默认情况下静态中间件的最大缓存时设置为0，意味着它在浏览器关闭后就被清除。这显然不是我们所期望的结果。除非是在开发环境可以无视maxAge的设置外，生产环境请务必设置缓存，因为它能有效节省网络带宽。
|
1 |
app.use('/public', connect.static(__dirname + '/public', {maxAge: 86400000})); |
maxAge选项的单位为毫秒。YUI3的CDN服务器设置过期时间为10年，是一个值得参考的值。静态文件如果在客户端被缓存，在需要清除缓存的时候，又该如何清除呢？这里的实现方法较多，一种较为推荐的做法是为文件进行md5处理。
|
1 |
http://some.url/some.js?md5 |
当文件内容产生改变时，md5值也将发生改变，浏览器根据URL的不同会重新获取静态文件。md5的方式可以避免不必要的缓存清除，也能精确清除缓存。由于浏览器本身缓存容量的限制，尽管我们可能设置了10年的过期时间，但是也许两天之后就被新的静态文件挤出了本地缓存。这将持续引起静态服务器的响应，也即意味着，客户端缓存并不能完全解决降低服务器压力的问题。为了解决静态服务器重复读取磁盘造成的压力，这里需要引出第二个相关的中间件：staticCache。
|
1 2 |
app.use(connect.staticCache()); app.use(“/public”, connect.static(__dirname + '/public', {maxAge: 86400000})); |
这是一个提供上层缓存功能的中间件，能够将磁盘中的文件加载到内存中，以提高响应速度和提高性能。它的官方测试数据如下：
|
1 2 3 |
static(): 2700 rps node-static: 5300 rps static() + staticCache(): 7500 rps |
另一个专门用于静态文件托管的模块叫node-static，其性能是Connect静态文件中间件的效率的两倍。但是在缓存中间件的协助下，可以弥补性能损失。事实上，这个中间件在生产环境下并不推荐被使用，而且它将在Connect 3.0版本中被移除。但是它的实现中有值得玩味的地方，这有助于我们认识Node.js模型的优缺点。staticCache中间件有两个主要的选项：maxObjects和maxLength。代表的是能存储多少个文件和单个文件的最大尺寸，其默认值为128和256kb。为何会有这两个选项的设定，原因在于V8有内存限制的原因，作为缓存，如果没有良好的过期策略，缓存将会无限增加，直到内存溢出。设置存储数量和单个文件大小后，可以有效抑制缓存区的大小。事实上，该缓存还存在的缺陷是单机情况下，通常为了有效利用CPU，Node.js实例并不只有一个，多个实例进程之间将会存在冗余的缓存占用，这对于内存使用而言是浪费的。除此之外，V8的垃圾回收机制是暂停JavaScript线程执行，通过扫描的方式决定是否回收对象。如果缓存对象过大，键太多，则扫描的时间会增加，会引起JavaScript响应业务逻辑的速度变慢。但是这个模块并非没有存在的意义，上述提及的缺陷大多都是V8内存限制和Node.js单线程的原因。解决该问题的方式则变得明了。风险转移是Node.js中常用于解决资源不足问题的方式，尤其是内存方面的问题。将缓存点，从Node.js实例进程中转移到第三方成熟的缓存中去即可。这可以保证： 缓存内容不冗余。 集中式缓存，减少不一致性的发生。 缓存的算法更优秀以保持较高的命中率。 让Node.js保持轻量，以解决它更擅长的问题。 Connect推荐服务器端缓存采用varnish这样的成熟缓存代理。而笔者目前的项目则是通过Redis来完成后端缓存的任务。 参考内容 https://www.varnish-cache.org/releases http://www.senchalabs.org/connect/static.html http://www.senchalabs.org/connect/staticCache.html 转自：http://www.infoq.com/cn/articles/nodejs-8-connect-module-part-2
View DetailsConnect模块背景 Node.js的愿望是成为一个能构建高速，可伸缩的网络应用的平台，它本身具有基于事件，异步，非阻塞，回调等特性，这在前几篇专栏中有过描述。正是基于这样的一些特性，Node.js平台上的Web框架也具有不同于其他平台的一些特性，其中Connect是众多Web框架中的佼佼者。Connect在它的官方介绍中，它是Node的一个中间件框架。超过18个捆绑的中间件和一些精选第三方中间件。尽管Connect可能不是性能最好的Node.jsWeb框架，但它却几乎是最为流行的Web框架。为何Connect能在众多框架中胜出，其原因不外乎有如下几个： 模型简单 中间件易于组合和插拔 中间件易于定制和优化 丰富的中间件 Connect自身十分简单，其作用是基于Web服务器做中间件管理。至于如何如何处理网络请求，这些任务通过路由分派给管理的中间件们进行处理。它的处理模型仅仅只是一个中间队列，进行流式处理而已，流式处理可能性能不是最优，但是却是最易于被理解和接受。基于中间件可以自由组合和插拔的情况，优化它十分容易。Connect模块目前在NPM仓库的MDO（被依赖最多的模块）排行第八位。但这并没有真实反映出它的价值，因为排行第五位的Express框架实际上是依赖Connect创建而成的。关于Express的介绍，将会在后续的专栏中一一为你讲解。 中间件 让我们回顾一下Node.js最简单的Web服务器是如何编写的：
|
1 2 3 4 5 |
var http = require('http'); http.createServer(function (req, res) { res.writeHead(200, {'Content-Type': 'text/plain'}); res.end('Hello World\n'); }).listen(1337, '127.0.0.1'); |
我们从最朴素的Web服务器处理流程开始，可以看到HTTP模块基于事件处理网络访问无外乎两个主要的因素，请求和响应。同理的是Connect的中间件也是扮演这样一个角色，处理请求，然后响应客户端或是让下一个中间件继续处理。如下是一个中间件最朴素的原型：
|
1 2 3 |
function (req, res, next) { // 中间件 } |
在中间件的上下文中，有着三个变量。分别代表请求对象、响应对象、下一个中间件。如果当前中间件调用了res.end()结束了响应，执行下一个中间件就显得没有必要。 流式处理 为了演示中间件的流式处理，我们可以看看中间件的使用形式：
|
1 2 3 4 5 6 7 8 9 10 11 12 13 |
var app = connect(); // Middleware app.use(connect.staticCache()); app.use(connect.static(__dirname + '/public')); app.use(connect.cookieParser()); app.use(connect.session()); app.use(connect.query()); app.use(connect.bodyParser()); app.use(connect.csrf()); app.use(function (req, res, next) { // 中间件 }); app.listen(3001); |
Conncet提供use方法用于注册中间件到一个Connect对象的队列中，我们称该队列叫做中间件队列。 Conncet的部分核心代码如下，它通过use方法来维护一个中间件队列。然后在请求来临的时候，依次调用队列中的中间件，直到某个中间件不再调用下一个中间件为止。
|
1 2 3 4 5 6 7 8 9 10 |
app.stack = []; app.use = function(route, fn){ // … // add the middleware debug('use %s %s', route || '/', fn.name || 'anonymous'); this.stack.push({ route: route, handle: fn }); return this; }; |
值得注意的是，必须要有一个中间件调用res.end()方法来告知客户端请求已被处理完成，否则客户端将一直处于等待状态。流式处理也是Node.js中用于流程控制的经典模式，Connect模块是典型的应用了它。流式处理的好处在于，每一个中间层的职责都是单一的，开发者通过这个模式可以将复杂的业务逻辑进行分解。 路由 从前文可以看到其实app.use()方法接受两个参数，route和fn，既路由信息和中间件函数，一个完整的中间件，其实包含路由信息和中间件函数。路由信息的作用是过滤不匹配的URL。请求在遇见路由信息不匹配时，直接传递给下一个中间件处理。通常在调用app.use()注册中间件时，只需要传递一个中间件函数即可。实际上这个过程中，Connect会将/作为该中间件的默认路由，它表示所有的请求都会被该中间件处理。中间件的优势类似于Java中的过滤器，能够全局性地处理一些事务，使得业务逻辑保持简单。任何事物均有两面性，当你调用app.use()添加中间件的时候，需要考虑的是中间件队列是否太长，因为每一层中间件的调用都是会降低性能的。为了提高性能，在添加中间件的时候，如非全局需求的，尽量附带上精确的路由信息。以multipart中间件为例，它用于处理表单提交的文件信息，相对而言较为耗费资源。它存在潜在的问题，那就是有可能被人在客户端恶意提交文件，造成服务器资源的浪费。如果不采用路由信息加以限制，那么任何URL都可以被攻击。
|
1 |
app.use("/upload", connect.multipart({ uploadDir: path })); |
加上精确的路由信息后，可以将问题减小。 MVC目录 借助Connect可以自由定制中间件的优势，可以自行提升性能或是设计出适合自己需要的项目。Connect自身提供了路由功能，在此基础上，可以轻松搭建MVC模式的框架，以达到开发效率和执行效率的平衡。以下是笔者项目中采用的目录结构，清晰地划分目录结构可以帮助划分代码的职责，此处仅供参考。
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 |
├── Makefile // 构建文件，通常用于启动单元测试运行等操作 ├── app.js // 应用文件 ├── automation // 自动化测试目录 ├── bin // 存放启动应用相关脚本的目录 ├── conf // 配置文件目录 ├── controllers // 控制层目录 ├── helpers // 帮助类库 ├── middlewares // 自定义中间件目录 ├── models // 数据层目录 ├── node_modules // 第三方模块目录 ├── package.json // 项目包描述文件 ├── public // 静态文件目录 │ ├── images // 图片目录 │ ├── libs // 第三方前端JavaScript库目录 │ ├── scripts // 前端JavaScript脚本目录 │ └── styles // 样式表目录 ├── test // 单元测试目录 └── views // 视图层目录 |
参考： Connect主页 http://www.senchalabs.org/connect/ NPM仓库 http://search.npmjs.org/ 转自：http://www.infoq.com/cn/articles/nodejs-connect-module
View Details作为前端的JSer，是一件非常幸福的事情，因为在字符串上从来没有出现过任何纠结的问题。我们来看看PHP对字符串长度的判断结果：
|
1 2 3 4 5 |
<? php echo strlen("0123456789"); echo strlen("零一二三四五六七八九"); echo mb_strlen("零一二三四五六七八九", "utf-8"); echo "\n"; |
以上三行判断分别返回10、30、10。对于中国人而言，strlen这个方法对于Unicode的判断结果是非常让人疑惑。而看看JavaScript中对字符串长度的判断，就知道这个length属性对调用者而言是多么友好。
|
1 2 3 |
console.log("0123456789".length); // 10 console.log("零一二三四五六七八九".length); /10 console.log("\u00bd".length); // 1 |
尽管在计算机内部，一个中文字和一个英文字占用的字节位数是不同的，但对于用户而言，它们拥有相同的长度。我认为这是JavaScript中 String处理得精彩的一个点。正是由于这个原因，所有的数据从后端传输到前端被调用时，都是这般友好的字符串。所以对于前端工程师而言，他们是没有字 符串Buffer的概念的。如果你是一名前端工程师，那么从此在与Node.js打交道的过程中，一定要小心Buffer啦，因为它比传统的String 要调皮一点。 你该小心Buffer啦 像许多计算机的技术一样，都是从国外传播过来的。那些以英文作为母语的传道者们应该没有考虑过英文以外的使用者，所以你有可能看到如下这样一段代码在向你描述如何在data事件中连接字符串。
|
1 2 3 4 5 6 7 8 9 |
var fs = require('fs'); var rs = fs.createReadStream('testdata.md'); var data = ''; rs.on("data", function (trunk){ data += trunk; }); rs.on("end", function () { console.log(data); }); |
如果这个文件读取流读取的是一个纯英文的文件，这段代码是能够正常输出的。但是如果我们再改变一下条件，将每次读取的buffer大小变成一个奇数，以模拟一个字符被分配在两个trunk中的场景。
|
1 |
var rs = fs.createReadStream('testdata.md', {bufferSize: 11}); |
我们将会得到以下这样的乱码输出：
|
1 |
事件循���和请求���象构成了Node.js���异步I/O模型的���个基本���素，这也是典���的消费���生产者场景。 |
造成这个问题的根源在于data += trunk语句里隐藏的错误，在默认的情况下，trunk是一个Buffer对象。这句话的实质是隐藏了toString的变换的：
|
1 |
data = data.toString() + trunk.toString(); |
由于汉字不是用一个字节来存储的，导致有被截破的汉字的存在，于是出现乱码。解决这个问题有一个简单的方案，是设置编码集：
|
1 |
var rs = fs.createReadStream('testdata.md', {encoding: 'utf-8', bufferSize: 11}); |
这将得到一个正常的字符串响应：
|
1 |
事件循环和请求对象构成了Node.js的异步I/O模型的两个基本元素，这也是典型的消费者生产者场景。 |
遗憾的是目前Node.js仅支持hex、utf8、ascii、binary、base64、ucs2几种编码的转换。对于那些因为历史遗留问题依旧还生存着的GBK，GB2312等编码，该方法是无能为力的。 有趣的string_decoder 在这个例子中，如果仔细观察，会发现一件有趣的事情发生在设置编码集之后。我们提到data += trunk等价于data = data.toString() + trunk.toString()。通过以下的代码可以测试到一个汉字占用三个字节，而我们按11个字节来截取trunk的话，依旧会存在一个汉字被分割在两个trunk中的情景。
|
1 2 |
console.log("事件循环和请求对象".length); console.log(new Buffer("事件循环和请求对象").length); |
按照猜想的toString()方式，应该返回的是事件循xxx和请求xxx象才对，其中“环”字应该变成乱码才对，但是在设置了encoding（默认的utf8）之后，结果却正常显示了，这个结果十分有趣。 在好奇心的驱使下可以探查到data事件调用了string_decoder来进行编码补足的行为。通过string_decoder对象输出第一个截取Buffer(事件循xx)时，只返回事件循这个字符串，保留xx。第二次通过string_decoder对象输出时检测到上次保留的xx，将上次剩余内容和本次的Buffer进行重新拼接输出。于是达到正常输出的目的。 string_decoder，目前在文件流读取和网络流读取中都有应用到，一定程度上避免了粗鲁拼接trunk导致的乱码错误。但是，遗憾在于string_decoder目前只支持utf8编码。它的思路其实还可以扩展到其他编码上，只是最终是否会支持目前尚不可得知。 连接Buffer对象的正确方法 那么万能的适应各种编码而且正确的拼接Buffer对象的方法是什么呢？我们从Node.js在github上的源码中找出这样一段正确读取文件，并连接buffer对象的方法：
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 |
var buffers = []; var nread = 0; readStream.on('data', function (chunk) { buffers.push(chunk); nread += chunk.length; }); readStream.on('end', function () { var buffer = null; switch(buffers.length) { case 0: buffer = new Buffer(0); break; case 1: buffer = buffers[0]; break; default: buffer = new Buffer(nread); for (var i = 0, pos = 0, l = buffers.length; i < l; i++) { var chunk = buffers[i]; chunk.copy(buffer, pos); pos += chunk.length; } break; } }); |
在end事件中通过细腻的连接方式，最后拿到理想的Buffer对象。这时候无论是在支持的编码之间转换，还是在不支持的编码之间转换（利用iconv模块转换），都不会导致乱码。 简化连接Buffer对象的过程 上述一大段代码仅只完成了一件事情，就是连接多个Buffer对象，而这种场景需求将会在多个地方发生，所以，采用一种更优雅的方式来完成该过程是必要的。笔者基于以上的代码封装出一个bufferhelper模块，用于更简洁地处理Buffer对象。可以通过NPM进行安装：
|
1 |
npm install bufferhelper |
下面的例子演示了如何调用这个模块。与传统data += trunk之间只是bufferHelper.concat(chunk)的差别，既避免了错误的出现，又使得代码可以得到简化而有效地编写。
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 |
var http = require('http'); var BufferHelper = require('bufferhelper'); http.createServer(function (request, response) { var bufferHelper = new BufferHelper(); request.on("data", function (chunk) { bufferHelper.concat(chunk); }); request.on('end', function () { var html = bufferHelper.toBuffer().toString(); response.writeHead(200); response.end(html); }); }).listen(8001); |
所以关于Buffer对象的操作的最佳实践是： 保持编码不变，以利于后续编码转换 使用封装方法达到简洁代码的目的 参考 https://github.com/joyent/node/blob/master/lib/fs.js#L107 https://github.com/JacksonTian/bufferhelper 转自：http://www.infoq.com/cn/articles/nodejs-about-buffer
View Details专栏的第四篇文章《Node.js的事件机制》。之前介绍了Node.js的模块机制，本文将深入Node.js的事件部分。 Node.js的事件机制 Node.js在其Github代码仓库（https://github.com/joyent/node）上有着一句短短的介绍：Evented I/O for V8 JavaScript。这句近似广告语的句子却道尽了Node.js自身的特色所在：基于V8引擎实现的事件驱动IO。在本文的这部分内容中，我来揭开这Evented这个关键词的一切奥秘吧。 Node.js能够在众多的后端JavaScript技术之中脱颖而出，正是因其基于事件的特点而受到欢迎。拿Rhino来做比较，可以看出Rhino引擎支持的后端JavaScript摆脱不掉其他语言同步执行的影响，导致JavaScript在后端编程与前端编程之间有着十分显著的差别，在编程模型上无法形成统一。在前端编程中，事件的应用十分广泛，DOM上的各种事件。在Ajax大规模应用之后，异步请求更得到广泛的认同，而Ajax亦是基于事件机制的。在Rhino中，文件读取等操作，均是同步操作进行的。在这类单线程的编程模型下，如果采用同步机制，无法与PHP之类的服务端脚本语言的成熟度媲美，性能也没有值得可圈可点的部分。直到Ryan Dahl在2009年推出Node.js后，后端JavaScript才走出其迷局。Node.js的推出，我觉得该变了两个状况： 龙生网络 统一了前后端JavaScript的编程模型。 利用事件机制充分利用用异步IO突破单线程编程模型的性能瓶颈，使得JavaScript在后端达到实用价值。 有了第二次浏览器大战中的佼佼者V8的适时助力，使得Node.js在短短的两年内达到可观的运行效率，并迅速被大家接受。这一点从Node.js项目在Github上的流行度和NPM上的库的数量可见一斑。 至于Node.js为何会选择Evented I/O for V8 JavaScript的结构和形式来实现，可以参见一下2011年初对作者Ryan Dahl的一次采访：http://bostinno.com/2011/01/31/node-js-interview-4-questions-with-creator-ryan-dahl/ 。 事件机制的实现 Node.js中大部分的模块，都继承自Event模块（http://nodejs.org/docs/latest/api/events.html ）。Event模块（events.EventEmitter）是一个简单的事件监听器模式的实现。具有addListener/on，once，removeListener，removeAllListeners，emit等基本的事件监听模式的方法实现。它与前端DOM树上的事件并不相同，因为它不存在冒泡，逐层捕获等属于DOM的事件行为，也没有preventDefault()、stopPropagation()、 stopImmediatePropagation() 等处理事件传递的方法。 从另一个角度来看，事件侦听器模式也是一种事件钩子（hook）的机制，利用事件钩子导出内部数据或状态给外部调用者。Node.js中的很多对象，大多具有黑盒的特点，功能点较少，如果不通过事件钩子的形式，对象运行期间的中间值或内部状态，是我们无法获取到的。这种通过事件钩子的方式，可以使编程者不用关注组件是如何启动和执行的，只需关注在需要的事件点上即可。
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 |
var options = { host: 'www.google.com', port: 80, path: '/upload', method: 'POST' }; var req = http.request(options, function (res) { console.log('STATUS: ' + res.statusCode); console.log('HEADERS: ' + JSON.stringify(res.headers)); res.setEncoding('utf8'); res.on('data', function (chunk) { console.log('BODY: ' + chunk); }); }); req.on('error', function (e) { console.log('problem with request: ' + e.message); }); // write data to request body req.write('data\n'); req.write('data\n'); req.end(); |
在这段HTTP request的代码中，程序员只需要将视线放在error，data这些业务事件点即可，至于内部的流程如何，无需过于关注。 值得一提的是如果对一个事件添加了超过10个侦听器，将会得到一条警告，这一处设计与Node.js自身单线程运行有关，设计者认为侦听器太多，可能导致内存泄漏，所以存在这样一个警告。调用：
|
1 |
emitter.setMaxListeners(0); |
可以将这个限制去掉。 其次，为了提升Node.js的程序的健壮性，EventEmitter对象对error事件进行了特殊对待。如果运行期间的错误触发了error事件。EventEmitter会检查是否有对error事件添加过侦听器，如果添加了，这个错误将会交由该侦听器处理，否则，这个错误将会作为异常抛出。如果外部没有捕获这个异常，将会引起线程的退出。 事件机制的进阶应用 继承event.EventEmitter 实现一个继承了EventEmitter类是十分简单的，以下是Node.js中流对象继承EventEmitter的例子：
|
1 2 3 4 |
function Stream() { events.EventEmitter.call(this); } util.inherits(Stream, events.EventEmitter); |
Node.js在工具模块中封装了继承的方法，所以此处可以很便利地调用。程序员可以通过这样的方式轻松继承EventEmitter对象，利用事件机制，可以帮助你解决一些问题。 多事件之间协作 在略微大一点的应用中，数据与Web服务器之间的分离是必然的，如新浪微博、Facebook、Twitter等。这样的优势在于数据源统一，并且可以为相同数据源制定各种丰富的客户端程序。以Web应用为例，在渲染一张页面的时候，通常需要从多个数据源拉取数据，并最终渲染至客户端。Node.js在这种场景中可以很自然很方便的同时并行发起对多个数据源的请求。
|
1 2 3 4 5 6 7 8 9 |
api.getUser("username", function (profile) { // Got the profile }); api.getTimeline("username", function (timeline) { // Got the timeline }); api.getSkin("username", function (skin) { // Got the skin }); |
Node.js通过异步机制使请求之间无阻塞，达到并行请求的目的，有效的调用下层资源。但是，这个场景中的问题是对于多个事件响应结果的协调并非被Node.js原生优雅地支持。为了达到三个请求都得到结果后才进行下一个步骤，程序也许会被变成以下情况：
|
1 2 3 4 5 6 7 |
api.getUser("username", function (profile) { api.getTimeline("username", function (timeline) { api.getSkin("username", function (skin) { // TODO }); }); }); |
这将导致请求变为串行进行，无法最大化利用底层的API服务器。 为解决这类问题，我曾写作一个模块（EventProxy，https://github.com/JacksonTian/eventproxy）来实现多事件协作，以下为上面代码的改进版：
|
1 2 3 4 5 6 7 8 9 10 11 12 13 |
var proxy = new EventProxy(); proxy.all("profile", "timeline", "skin", function (profile, timeline, skin) { // TODO }); api.getUser("username", function (profile) { proxy.emit("profile", profile); }); api.getTimeline("username", function (timeline) { proxy.emit("timeline", timeline); }); api.getSkin("username", function (skin) { proxy.emit("skin", skin); }); |
EventProxy也是一个简单的事件侦听者模式的实现，由于底层实现跟Node.js的EventEmitter不同，无法合并进Node.js中。但是却提供了比EventEmitter更强大的功能，且API保持与EventEmitter一致，与Node.js的思路保持契合，并可以适用在前端中。 这里的all方法是指侦听完profile、timeline、skin三个方法后，执行回调函数，并将侦听接收到的数据传入。 最后还介绍一种解决多事件协作的方案：Jscex（https://github.com/JeffreyZhao/jscex ）。Jscex通过运行时编译的思路（需要时也可在运行前编译），将同步思维的代码转换为最终异步的代码来执行，可以在编写代码的时候通过同步思维来写，可以享受到同步思维的便利写作，异步执行的高效性能。如果通过Jscex编写，将会是以下形式：
|
1 2 3 4 5 6 7 |
var data = $await(Task.whenAll({ profile: api.getUser("username"), timeline: api.getTimeline("username"), skin: api.getSkin("username") })); // 使用data.profile, data.timeline, data.skin // TODO |
此节感谢Jscex作者@老赵（http://blog.zhaojie.me/）的指正和帮助。 利用事件队列解决雪崩问题 所谓雪崩问题，是在缓存失效的情景下，大并发高访问量同时涌入数据库中查询，数据库无法同时承受如此大的查询请求，进而往前影响到网站整体响应缓慢。那么在Node.js中如何应付这种情景呢。
|
1 2 3 4 5 |
var select = function (callback) { db.select("SQL", function (results) { callback(results); }); }; |
以上是一句数据库查询的调用，如果站点刚好启动，这时候缓存中是不存在数据的，而如果访问量巨大，同一句SQL会被发送到数据库中反复查询，影响到服务的整体性能。一个改进是添加一个状态锁。
|
1 2 3 4 5 6 7 8 9 10 |
var status = "ready"; var select = function (callback) { if (status === "ready") { status = "pending"; db.select("SQL", function (results) { callback(results); status = "ready"; }); } }; |
但是这种情景，连续的多次调用select发，只有第一次调用是生效的，后续的select是没有数据服务的。所以这个时候引入事件队列吧：
|
1 2 3 4 5 6 7 8 9 10 11 12 |
var proxy = new EventProxy(); var status = "ready"; var select = function (callback) { proxy.once("selected", callback); if (status === "ready") { status = "pending"; db.select("SQL", function (results) { proxy.emit("selected", results); status = "ready"; }); } }; |
这里利用了EventProxy对象的once方法，将所有请求的回调都压入事件队列中，并利用其执行一次就会将监视器移除的特点，保证每一个回调只会被执行一次。对于相同的SQL语句，保证在同一个查询开始到结束的时间中永远只有一次，在这查询期间到来的调用，只需在队列中等待数据就绪即可，节省了重复的数据库调用开销。由于Node.js单线程执行的原因，此处无需担心状态问题。这种方式其实也可以应用到其他远程调用的场景中，即使外部没有缓存策略，也能有效节省重复开销。此处也可以用EventEmitter替代EventProxy，不过可能存在侦听器过多，引发警告，需要调用setMaxListeners(0)移除掉警告，或者设更大的警告阀值。 参考： http://nodejs.org/docs/latest/api/events.html https://github.com/JacksonTian/eventproxy/blob/master/README.md https://github.com/JeffreyZhao/jscex/blob/master/README-cn.md
View Details之前介绍了Node.js的事件机制，也许读者对此尚会觉得意犹未尽，因为仅仅只是简单的事件机制，并不能道尽Node.js的神奇。如果Node.js是一盘别开生面的磁带，那么事件与异步分别是其A面和B面，它们共同组成了Node.js的别样之处。本文将翻转Node.js到B面，与你共同聆听。 异步I/O 在操作系统中，程序运行的空间分为内核空间和用户空间。我们常常提起的异步I/O，其实质是用户空间中的程序不用依赖内核空间中的I/O操作实际完成，即可进行后续任务。以下伪代码模仿了一个从磁盘上获取文件和一个从网络中获取文件的操作。异步I/O的效果就是getFileFromNet的调用不依赖于getFile调用的结束。
|
1 2 |
getFile("file_path"); getFileFromNet("url"); |
如果以上两个任务的时间分别为m和n。采用同步方式的程序要完成这两个任务的时间总花销会是m + n。但是如果是采用异步方式的程序，在两种I/O可以并行的状况下（比如网络I/O与文件I/O），时间开销将会减小为max(m, n)。 异步I/O的必要性 有的语言为了设计得使应用程序调用方便，将程序设计为同步I/O的模型。这意味着程序中的后续任务都需要等待I/O的完成。在等待I/O完成的过程中，程序无法充分利用CPU。为了充分利用CPU，和使I/O可以并行，目前有两种方式可以达到目的： 多线程单进程 多线程的设计之处就是为了在共享的程序空间中，实现并行处理任务，从而达到充分利用CPU的效果。多线程的缺点在于执行时上下文交换的开销较大，和状态同步（锁）的问题。同样它也使得程序的编写和调用复杂化。 单线程多进程 为了避免多线程造成的使用不便问题，有的语言选择了单线程保持调用简单化，采用启动多进程的方式来达到充分利用CPU和提升总体的并行处理能力。 它的缺点在于业务逻辑复杂时（涉及多个I/O调用），因为业务逻辑不能分布到多个进程之间，事务处理时长要远远大于多线程模式。 前者在性能优化上还有回旋的余地，后者的做法纯粹是一种加三倍服务器的行为。 而且现在的大型Web应用中，单机的情形是十分稀少的，一个事务往往需要跨越网络几次才能完成最终处理。如果网络速度不够理想，m和n值都将会变大，这时同步I/O的语言模型将会露出其最脆弱的状态。 这种场景下的异步I/O将会体现其优势，max(m, n)的时间开销可以有效地缓解m和n值增长带来的性能问题。而当并行任务更多的时候，m + n + …与max(m, n, …)之间的孰优孰劣更是一目了然。从这个公式中，可以了解到异步I/O在分布式环境中是多么重要，而Node.js天然地支持这种异步I/O，这是众多云计算厂商对其青睐的根本原因。 操作系统对异步I/O的支持 我们听到Node.js时，我们常常会听到异步，非阻塞，回调，事件这些词语混合在一起。其中，异步与非阻塞听起来似乎是同一回事。从实际效果的角度说，异步和非阻塞都达到了我们并行I/O的目的。但是从计算机内核I/O而言，异步/同步和阻塞/非阻塞实际上时两回事。 I/O的阻塞与非阻塞 阻塞模式的I/O会造成应用程序等待，直到I/O完成。同时操作系统也支持将I/O操作设置为非阻塞模式，这时应用程序的调用将可能在没有拿到真正数据时就立即返回了，为此应用程序需要多次调用才能确认I/O操作完全完成。 I/O的同步与异步 I/O的同步与异步出现在应用程序中。如果做阻塞I/O调用，应用程序等待调用的完成的过程就是一种同步状况。相反，I/O为非阻塞模式时，应用程序则是异步的。 异步I/O与轮询技术 当进行非阻塞I/O调用时，要读到完整的数据，应用程序需要进行多次轮询，才能确保读取数据完成，以进行下一步的操作。 轮询技术的缺点在于应用程序要主动调用，会造成占用较多CPU时间片，性能较为低下。现存的轮询技术有以下这些： read select poll epoll pselect kqueue read是性能最低的一种，它通过重复调用来检查I/O的状态来完成完整数据读取。select是一种改进方案，通过对文件描述符上的事件状态来进行判断。操作系统还提供了poll、epoll等多路复用技术来提高性能。 轮询技术满足了异步I/O确保获取完整数据的保证。但是对于应用程序而言，它仍然只能算时一种同步，因为应用程序仍然需要主动去判断I/O的状态，依旧花费了很多CPU时间来等待。 上一种方法重复调用read进行轮询直到最终成功，用户程序会占用较多CPU，性能较为低下。而实际上操作系统提供了select方法来代替这种重复read轮询进行状态判断。select内部通过检查文件描述符上的事件状态来进行判断数据是否完全读取。但是对于应用程序而言它仍然只能算是一种同步，因为应用程序仍然需要主动去判断I/O的状态，依旧花费了很多CPU时间等待，select也是一种轮询。 理想的异步I/O模型 理想的异步I/O应该是应用程序发起异步调用，而不需要进行轮询，进而处理下一个任务，只需在I/O完成后通过信号或是回调将数据传递给应用程序即可。 幸运的是，在Linux下存在一种这种方式，它原生提供了一种异步非阻塞I/O方式（AIO）即是通过信号或回调来传递数据的。 不幸的是，只有Linux下有这么一种支持，而且还有缺陷（AIO仅支持内核I/O中的O_DIRECT方式读取，导致无法利用系统缓存。参见：http://forum.nginx.org/read.php?2,113524,113587#msg-113587 以上都是基于非阻塞I/O进行的设定。另一种理想的异步I/O是采用阻塞I/O，但加入多线程，将I/O操作分到多个线程上，利用线程之间的通信来模拟异步。Glibc的AIO便是这样的典型http://www.ibm.com/developerworks/linux/library/l-async/。然而遗憾在于，它存在一些难以忍受的缺陷和bug。可以简单的概述为：Linux平台下没有完美的异步I/O支持。 所幸的是，libev的作者Marc Alexander Lehmann重新实现了一个异步I/O的库：libeio。libeio实质依然是采用线程池与阻塞I/O模拟出来的异步I/O。 那么在Windows平台下的状况如何呢？而实际上，Windows有一种独有的内核异步IO方案：IOCP。IOCP的思路是真正的异步I/O方案，调用异步方法，然后等待I/O完成通知。IOCP内部依旧是通过线程实现，不同在于这些线程由系统内核接手管理。IOCP的异步模型与Node.js的异步调用模型已经十分近似。 以上两种方案则正是Node.js选择的异步I/O方案。由于Windows平台和*nix平台的差异，Node.js提供了libuv来作为抽象封装层，使得所有平台兼容性的判断都由这一层次来完成，保证上层的Node.js与下层的libeio/libev及IOCP之间各自独立。Node.js在编译期间会判断平台条件，选择性编译unix目录或是win目录下的源文件到目标程序中。 下文我们将通过解释Windows下Node.js异步I/O（IOCP）的简单例子来探寻一下从JavaScript代码到系统内核之间都发生了什么。 Node.js的异步I/O模型 很多同学在遇见Node.js后必然产生过对回调函数究竟如何被调用产生过好奇。在文件I/O这一块与普通的业务逻辑的回调函数不同在于它不是由我们自己的代码所触发，而是系统调用结束后，由系统触发的。下面我们以最简单的fs.open方法来作为例子，探索Node.js与底层之间是如何执行异步I/O调用和回调函数究竟是如何被调用执行的。
|
1 2 3 4 5 6 7 8 9 10 11 12 13 |
fs.open = function(path, flags, mode, callback) { callback = arguments[arguments.length - 1]; if (typeof(callback) !== 'function') { callback = noop; } mode = modeNum(mode, 438 /*=0666*/); binding.open(pathModule._makeLong(path), stringToFlags(flags), mode, callback); }; |
fs.open的作用是根据指定路径和参数，去打开一个文件，从而得到一个文件描述符，是后续所有I/O操作的初始操作。 在JavaScript层面上调用的fs.open方法最终都透过node_file.cc调用到了libuv中的uv_fs_open方法，这里libuv作为封装层，分别写了两个平台下的代码实现，编译之后，只会存在一种实现被调用。 请求对象 在uv_fs_open的调用过程中，Node.js创建了一个FSReqWrap请求对象。从JavaScript传入的参数和当前方法都被封装在这个请求对象中，其中回调函数则被设置在这个对象的oncomplete_sym属性上。
|
1 |
req_wrap->object_->Set(oncomplete_sym, callback); |
对象包装完毕后，调用QueueUserWorkItem方法将这个FSReqWrap对象推入线程池中等待执行。
|
1 |
QueueUserWorkItem(&uv_fs_thread_proc, req, WT_EXECUTELONGFUNCTION) |
QueueUserWorkItem接受三个参数，第一个是要执行的方法，第二个是方法的上下文，第三个是执行的标志。当线程池中有可用线程的时候调用uv_fs_thread_proc方法执行。该方法会根据传入的类型调用相应的底层函数，以uv_fs_open为例，实际会调用到fs__open方法。调用完毕之后，会将获取的结果设置在req->result上。然后调用PostQueuedCompletionStatus通知我们的IOCP对象操作已经完成。
|
1 |
PostQueuedCompletionStatus((loop)->iocp, 0, 0, &((req)->overlapped)) |
PostQueuedCompletionStatus方法的作用是向创建的IOCP上相关的线程通信，线程根据执行状况和传入的参数判定退出。 至此，由JavaScript层面发起的异步调用第一阶段就此结束。 事件循环 在调用uv_fs_open方法的过程中实际上应用到了事件循环。以在Windows平台下的实现中，启动Node.js时，便创建了一个基于IOCP的事件循环loop，并一直处于执行状态。
|
1 |
uv_run(uv_default_loop()); |
每次循环中，它会调用IOCP相关的GetQueuedCompletionStatus方法检查是否线程池中有执行完的请求，如果存在，poll操作会将请求对象加入到loop的pending_reqs_tail属性上。 另一边这个循环也会不断检查loop对象上的pending_reqs_tail引用，如果有可用的请求对象，就取出请求对象的result属性作为结果传递给oncomplete_sym执行，以此达到调用JavaScript中传入的回调函数的目的。 至此，整个异步I/O的流程完成结束。其流程如下： 事件循环和请求对象构成了Node.js的异步I/O模型的两个基本元素，这也是典型的消费者生产者场景。在Windows下通过IOCP的GetQueuedCompletionStatus、PostQueuedCompletionStatus、QueueUserWorkItem方法与事件循环实。对于*nix平台下，这个流程的不同之处在与实现这些功能的方法是由libeio和libev提供。 参考： 《nodejs异步IO的实现》http://cnodejs.org/blog/?p=244 《linux AIO （异步IO） 那点事儿》http://cnodejs.org/blog/?p=2426 《libev 设计分析》http://cnodejs.org/blog/?p=2489 《Node Roadmap》http://nodejs.org/nodeconf.pdf 《多路复用select(2)与事件通知poll(2)、epoll(7)内核源码初探》http://blog.dccmx.com/2011/04/select-poll-epoll-in-kernel/ 《使用异步 I/O […]
View Details专栏的第三篇文章《深入Node.js的模块机制》。之前介绍了Node.js安装的基础知识，本文将深入Node.js的模块机制。 Node.js模块的实现 之前在网上查阅了许多介绍Node.js的文章，可惜对于Node.js的模块机制大都着墨不多。在后续介绍模块的使用之前，我认为有必要深入一下Node.js的模块机制。 CommonJS规范 早在Netscape诞生不久后，JavaScript就一直在探索本地编程的路，Rhino是其代表产物。无奈那时服务端JavaScript走的路均是参考众多服务器端语言来实现的，在这样的背景之下，一没有特色，二没有实用价值。但是随着JavaScript在前端的应用越来越广泛，以及服务端JavaScript的推动，JavaScript现有的规范十分薄弱，不利于JavaScript大规模的应用。那些以JavaScript为宿主语言的环境中，只有本身的基础原生对象和类型，更多的对象和API都取决于宿主的提供，所以，我们可以看到JavaScript缺少这些功能： JavaScript没有模块系统。没有原生的支持密闭作用域或依赖管理。 JavaScript没有标准库。除了一些核心库外，没有文件系统的API，没有IO流API等。 JavaScript没有标准接口。没有如Web Server或者数据库的统一接口。 JavaScript没有包管理系统。不能自动加载和安装依赖。 于是便有了CommonJS（http://www.commonjs.org）规范的出现，其目标是为了构建JavaScript在包括Web服务器，桌面，命令行工具，及浏览器方面的生态系统。 CommonJS制定了解决这些问题的一些规范，而Node.js就是这些规范的一种实现。Node.js自身实现了require方法作为其引入模块的方法，同时NPM也基于CommonJS定义的包规范，实现了依赖管理和模块自动安装等功能。这里我们将深入一下Node.js的require机制和NPM基于包规范的应用。 简单模块定义和使用 在Node.js中，定义一个模块十分方便。我们以计算圆形的面积和周长两个方法为例，来表现Node.js中模块的定义方式。
|
1 2 3 4 5 6 7 |
var PI = Math.PI; exports.area = function (r) { return PI * r * r; }; exports.circumference = function (r) { return 2 * PI * r; }; |
将这个文件存为circle.js，并新建一个app.js文件，并写入以下代码：
|
1 2 |
var circle = require('./circle.js'); console.log( 'The area of a circle of radius 4 is ' + circle.area(4)); |
可以看到模块调用也十分方便，只需要require需要调用的文件即可。 在require了这个文件之后，定义在exports对象上的方法便可以随意调用。Node.js将模块的定义和调用都封装得极其简单方便，从API对用户友好这一个角度来说，Node.js的模块机制是非常优秀的。 模块载入策略 Node.js的模块分为两类，一类为原生（核心）模块，一类为文件模块。原生模块在Node.js源代码编译的时候编译进了二进制执行文件，加载的速度最快。另一类文件模块是动态加载的，加载速度比原生模块慢。但是Node.js对原生模块和文件模块都进行了缓存，于是在第二次require时，是不会有重复开销的。其中原生模块都被定义在lib这个目录下面，文件模块则不定性。
|
1 |
node app.js |
由于通过命令行加载启动的文件几乎都为文件模块。我们从Node.js如何加载文件模块开始谈起。加载文件模块的工作，主要由原生模块module来实现和完成，该原生模块在启动时已经被加载，进程直接调用到runMain静态方法。
|
1 2 3 4 5 |
// bootstrap main module. Module.runMain = function () { // Load the main module--the command line argument. Module._load(process.argv[1], null, true); }; |
_load静态方法在分析文件名之后执行
|
1 |
var module = new Module(id, parent); |
并根据文件路径缓存当前模块对象，该模块实例对象则根据文件名加载。
|
1 |
module.load(filename); |
实际上在文件模块中，又分为3类模块。这三类文件模块以后缀来区分，Node.js会根据后缀名来决定加载方法。 .js。通过fs模块同步读取js文件并编译执行。 .node。通过C/C++进行编写的Addon。通过dlopen方法进行加载。 .json。读取文件，调用JSON.parse解析加载。 这里我们将详细描述js后缀的编译过程。Node.js在编译js文件的过程中实际完成的步骤有对js文件内容进行头尾包装。以app.js为例，包装之后的app.js将会变成以下形式：
|
1 2 3 4 |
(function (exports, require, module, __filename, __dirname) { var circle = require('./circle.js'); console.log('The area of a circle of radius 4 is ' + circle.area(4)); }); |
这段代码会通过vm原生模块的runInThisContext方法执行（类似eval，只是具有明确上下文，不污染全局），返回为一个具体的function对象。最后传入module对象的exports，require方法，module，文件名，目录名作为实参并执行。 这就是为什么require并没有定义在app.js 文件中，但是这个方法却存在的原因。从Node.js的API文档中可以看到还有__filename、__dirname、module、exports几个没有定义但是却存在的变量。其中__filename和__dirname在查找文件路径的过程中分析得到后传入的。module变量是这个模块对象自身，exports是在module的构造函数中初始化的一个空对象（{}，而不是null）。 在这个主文件中，可以通过require方法去引入其余的模块。而其实这个require方法实际调用的就是load方法。 load方法在载入、编译、缓存了module后，返回module的exports对象。这就是circle.js文件中只有定义在exports对象上的方法才能被外部调用的原因。 以上所描述的模块载入机制均定义在lib/module.js中。 require方法中的文件查找策略 由于Node.js中存在4类模块（原生模块和3种文件模块），尽管require方法极其简单，但是内部的加载却是十分复杂的，其加载优先级也各自不同。 从文件模块缓存中加载 尽管原生模块与文件模块的优先级不同，但是都不会优先于从文件模块的缓存中加载已经存在的模块。 从原生模块加载 原生模块的优先级仅次于文件模块缓存的优先级。require方法在解析文件名之后，优先检查模块是否在原生模块列表中。以http模块为例，尽管在目录下存在一个http/http.js/http.node/http.json文件，require(“http”)都不会从这些文件中加载，而是从原生模块中加载。 原生模块也有一个缓存区，同样也是优先从缓存区加载。如果缓存区没有被加载过，则调用原生模块的加载方式进行加载和执行。 从文件加载 当文件模块缓存中不存在，而且不是原生模块的时候，Node.js会解析require方法传入的参数，并从文件系统中加载实际的文件，加载过程中的包装和编译细节在前一节中已经介绍过，这里我们将详细描述查找文件模块的过程，其中，也有一些细节值得知晓。 require方法接受以下几种参数的传递： http、fs、path等，原生模块。 ./mod或../mod，相对路径的文件模块。 /pathtomodule/mod，绝对路径的文件模块。 mod，非原生模块的文件模块。 在进入路径查找之前有必要描述一下module path这个Node.js中的概念。对于每一个被加载的文件模块，创建这个模块对象的时候，这个模块便会有一个paths属性，其值根据当前文件的路径计算得到。我们创建modulepath.js这样一个文件，其内容为：
|
1 |
console.log(module.paths); |
我们将其放到任意一个目录中执行node modulepath.js命令，将得到以下的输出结果。
|
1 2 3 4 |
[ '/home/jackson/research/node_modules', '/home/jackson/node_modules', '/home/node_modules', '/node_modules' ] |
Windows下：
|
1 |
[ 'c:\\nodejs\\node_modules', 'c:\\node_modules' ] |
可以看出module path的生成规则为：从当前文件目录开始查找node_modules目录；然后依次进入父目录，查找父目录下的node_modules目录；依次迭代，直到根目录下的node_modules目录。 除此之外还有一个全局module path，是当前node执行文件的相对目录（../../lib/node）。如果在环境变量中设置了HOME目录和NODE_PATH目录的话，整个路径还包含NODE_PATH和HOME目录下的.node_libraries与.node_modules。其最终值大致如下：
|
1 |
[NODE_PATH，HOME/.node_modules，HOME/.node_libraries，execPath/../../lib/node] |
下图是笔者从源代码中整理出来的整个文件查找流程： 简而言之，如果require绝对路径的文件，查找时不会去遍历每一个node_modules目录，其速度最快。其余流程如下： 从module path数组中取出第一个目录作为查找基准。 直接从目录中查找该文件，如果存在，则结束查找。如果不存在，则进行下一条查找。 尝试添加.js、.json、.node后缀后查找，如果存在文件，则结束查找。如果不存在，则进行下一条。 尝试将require的参数作为一个包来进行查找，读取目录下的package.json文件，取得main参数指定的文件。 尝试查找该文件，如果存在，则结束查找。如果不存在，则进行第3条查找。 如果继续失败，则取出module path数组中的下一个目录作为基准查找，循环第1至5个步骤。 如果继续失败，循环第1至6个步骤，直到module path中的最后一个值。 如果仍然失败，则抛出异常。 整个查找过程十分类似原型链的查找和作用域的查找。所幸Node.js对路径查找实现了缓存机制，否则由于每次判断路径都是同步阻塞式进行，会导致严重的性能消耗。 包结构 前面提到，JavaScript缺少包结构。CommonJS致力于改变这种现状，于是定义了包的结构规范（http://wiki.commonjs.org/wiki/Packages/1.0 ）。而NPM的出现则是为了在CommonJS规范的基础上，实现解决包的安装卸载，依赖管理，版本管理等问题。require的查找机制明了之后，我们来看一下包的细节。 一个符合CommonJS规范的包应该是如下这种结构： 一个package.json文件应该存在于包顶级目录下 二进制文件应该包含在bin目录下。 JavaScript代码应该包含在lib目录下。 […]
View Details