node chat源码解读(三)
发布于 9 年前 作者 pengchun 5036 次浏览 最后一次编辑是 4 年前

再优雅的代码本身也只是表象。表象之后,nodejs最核心的地方在哪里呢?我认为,可以从以下几个方面来概括: <br/><h1>程序即server</h1> <br/>传统的web服务通常是把提供HTTP协议支持的前端server与背后承担业务逻辑的程序分开的。比如用PHP写成的wordpress只是程序,它的前段一定要架设一个nginx,或者apache,或者其他的web server才能提供服务。 <br/> <br/>这一模式显然有他与生俱来的优势——把协议层和应用层隔离开了。程序开发者只需要关心业务代码的开发,而不用或者很少去关心协议层的实现。而且,在大多数情况下,同样的应用层代码可以在不同的web server上正确地工作。同样地,协议层的web server开发者只需要专心实现好协议层的功能即可,而不需要也无法照顾业务层的功能。 <br/> <br/>这种模式使得隔离后的双方都更专注,催生了一批优秀的开源软件,如server端的nginx,apache和lighttp等;即便在需求复杂多变的应用端,也诞生了不计其数的优秀作品。 <br/> <br/>也正因为上述server与程序分离的原因,多次HTTP请求之间很难通过server建立高效的数据共享通道,对于读请求远多于写请求的系统来说,业务端程序需要反复地读取很少变动的数据,不仅性能不好,而且给后端存储带来了不必要的压力。尤其是这种分离直接导致了对连接池的支持乏力。 <br/> <br/>尽管后来在二者之间出现了一些借助共享内存实现的数据共享机制(如apc),甚至有些对性能有较高要求的团队通过给http server写module的方式定制化地满足了请求之间的数据共享,但双方配合方式没有实质性的改变。 <br/> <br/>而nodejs由于自身直接提供了http服务的module(或者说框架),因而开发者能很容易地写出一个协议层面的HTTP Server。将http server与程序逻辑写在一起是如此地容易,那么前端还要什么web server呢! <br/> <br/>这一做法绝不是噱头。在这种方式下,数据能够很容易地在请求之间共享,对连接池的支持也似乎不是一件值得炫耀的事情了。 <br/><h1>异步IO与事件机制</h1> <br/>异步IO这一特性并没有在node chat中得到足够的体现,但却是nodejs不得不提的一个特性。这一特性把浪费在IO等待上的CPU时间充分地”压榨”了出来,在一定程度上能够降低程序的响应时间。 <br/>但是,异步总会使得程序更复杂,非必要情况下我们不建议使用。而nodejs中采用事件机制来降低由此带来的程序复杂度,不能不说是绝妙的组合。 <br/>如水所述,我们可以大致地概括出,在nodejs模式下,一个提供web服务的“<strong><span style=“color: #ff0000”>程序</span></strong>”的一些基本的设计思路: <br/><ol> <br/> <li>在http server中用连接池来保护外部资源;</li> <br/> <li>很少改变的数据作为“静态”变量“缓存”在http server层,通过定时器或者外部接口进行更新;</li> <br/> <li>对外部资源的读写采用异步IO+事件绑定的方式实现CPU时间的零等待。</li> <br/></ol>

2 回复

也诞生了不急其数的优秀作品 <br/>错别字,不计其数

谢谢细心的订正

回到顶部