Node.js 英文原文：Using Node.js as an accelerator for WCF REST services

Node.js是一个“用于轻松创建快速、可伸缩网络应用程序”的服务器端JavaScript平台。它构建于来自Google的V8 JavaScript引擎，采用了（几乎）完全异步式事件驱动的处理模型，运行于一个单个的线程之内。如果你刚接触Node而你的反应是“为什么我会想要在服务器端运行JavaScript？”，本文的题目就是答案：用JavaScript，在150行代码之内，你就能够创建出一个可用作WCF REST服务加速器的Node.js应用*。 同直接采用WCF 服务相比，这个应用能够将作为吞吐量衡量标准的每秒内处理的消息总数提高一倍，同时还会将CPU的工作量降低一半而且还只需占用五分之一的内存。

好的，这样是可以的，前提是：

1）您的WCF服务是一个遵守HTTP的优秀公民，在请求和响应中履行客户端缓存ETag头;

2）你的服务做了一系列可信赖的工作，建立响应;

3）您的数据相对写有更多的读请求。

在我 一个项目中，我有一组WCF REST服务，他们处理的数据只每周只更新一次，但每小时读取数百次。 服务确认客户端请求提供的ETag与目前的相同，那服务会返回一个304，，这意味着更常见的场景中，客户端使用本地缓存的副本。但每周更新后，所有的客户端缓存无效了，他们都需要相同的新数据，服务现在收到数百的携带老ETag的请求，服务为 每个线程通过完整的服务栈、花费 处理时间构建响应。后面的部分流程诸如到独立云上处理数据库事务，而云拥有更多延时和停机处理的潜力。

我们能够通过ASP.NET使用 输出缓存和WCF(windows通讯接口)来解决重复访问的问题,但是当有进来的请求时，服务器仍然会将线程绑定,并且为了得到现有可靠的ETags需要每一个请求得到一次数据库的调用。加速器通过使用一个协议来解决这个问题。所有用户访问进入到这个协议中，协议路由响应到到下层REST服务(REST service)。我们通过Node直接使用协议并且从中获得的好处是服务器将会很少的被线程绑定。但是我们仍然需要一个WCF(windows通讯接口)和一次数据库响应每一次协议的调用。但是给协议添加一些有效的逻辑缓存并且在Node和WCF(windows通讯接口)之间共享ETags（所以协议并不需要调用service去得到当前的ETag），并且当数据库发生变化的时候，底层服务将会被调用且只被调用一次。所有的客户端请求将会使用协议缓存来处理。

我构建的例子放在GitHub上： NodeWcfAccelerator on sixeyed.codegallery. 架构如下图所示：

代码很简单。Node代理运行在8010端口，所有请求都发送到代理。如果客户端请求包含Etag头，代理会去tag池检测这个Etag是否是当前tag——例子使用memchached在.NET和Node之间传递Etag.如果该请求Etag与当前服务器的tag匹配，代理向客户端发送一个304响应头以及空响应体，告诉客户端使用自己缓存版本的数据。如果客户端发送的Etag已过期，代理将查找本地缓存的响应，检查以当前Etag命名的文件。如果该文件存在，其内容会作为200响应的响应体发送给客户端，并且响应头包含当前Etag.如果代理没有可用于服务器响应的缓存文件，则调用服务器，生成WCF响应作为缓存文件，并作为200响应的响应体发往客户端。所以此WCF服务只有在客户端和代理的缓存都过期的情况下才会出现问题。

在例子中，唯一一个聪明（并非确实的）的地方就是使用了ETag缓存，因此代理可以直接为缓存的请求服务，而不需要和底层的服务做任何通信，这些过程完全是非特定的，所以代理无需记住它正在服务的对象，或者是它正在做的服务本身。URL里面的相对路径，作为一个查询键，所以在.NET和Node之间没有共享的键－生成逻辑，而且当WCF保存一个tag的时候，它同时也存储了“读取”操作的URL，这一点于Etag相对，从而可以用来做一个反向查询，例如：

Key	Value
/WcfSampleService/PersonService.svc/rest/fetch/3	"28cd4796-76b8-451b-adfd-75cb50a50fa6"
"28cd4796-76b8-451b-adfd-75cb50a50fa6"	/WcfSampleService/PersonService.svc/rest/fetch/3

在Node中，我们读取缓存的内容，使用的是输入的URL路径为键，而且我们知道“28cd4796-76b8-451b-adfd-75cb50a50fa6“是当前的Etag；我们在/caches/28cd4796-76b8-451b-adfd-75cb50a50fa6.body 寻找一个本地缓存的响应体（而于此相应的.header文件里面，保存的是原有的服务响应中带有的headers，所以代理的响应和底层服务的响应就完全一致）。当一个数据被更新的时候，我们需要让Etag缓存无效－这也是我们需要反向查询缓存的原因。在WCF更新服务中，我们不需要知道相关的读取服务的URL－我们从数据库里面获得特定的实体，而做一个tag缓存的反向查询，使用就旧的Etag来获得读取的URL，并相对此URL更新新的ETag，保存新的反向查询然后再删除旧的。

使用 Apache Bench 来就两个终端节点做特定的headline performance比较。使用100个并行的（进程／线程）来发送1000个请求，而在请求中不发送任何的ETag headers，在节点代理上，我得到了每秒钟102个请求被处理的结果，平均的响应时间是975毫秒，而90％的响应在850毫秒内得以处理；使用同样的参数，通过直接访问WCF，我得到了每秒钟处理53个请求的结果，糟糕的请求响应的时间是1853毫秒，而90％的响应在3260毫秒内被处理。通过额外非正规的监测服务器在测试中的使用情况，节点的CPU使用率最大为20％以及20Mb内存；IIS最大达到了60％CPU使用率以及100Mb内存。

需要说明的是，样例WCF服务做一个数据库读之后，会睡眠250毫秒，通过这样来模拟一种平均化的处理负荷，所以这不是Node和WCF比较的基数，而对于相似的场合而言，当服务的调用很昂贵，而需要在一段长的时间片里面能应付大量的客户的时候，性能通过加速器的提升是巨大的。

＊－实际上，加速器对于任何HTTP请求都会工作的很好，当URL（路径＋查询字符串）唯一的标示一个资源的时候。在上面的例子中，有一个预先的假定，就是ETag是一个用双引号括起来的GUID数值－这个是WCF默认的配置。我是用了这个假设来唯一命名缓冲里面的文件，而改变这一点来使用别的ETag格式并不是十分重要。

本文中的所有译文仅用于学习和交流目的，转载请务必注明文章译者、出处、和本文链接。 2KB翻译工作遵照 CC 协议，如果我们的工作有侵犯到您的权益，请及时联系我们。

2KB项目（www.2kb.com，源码交易平台）,提供担保交易、源码交易、虚拟商品、在家创业、在线创业、任务交易、网站设计、软件设计、网络兼职、站长交易、域名交易、链接买卖、网站交易、广告买卖、站长培训、建站美工等服务