Fastcgi到底是什么样的技术

Fastcgi到底是什么样的技术

注:本人对LAMP,python了解不是很多,此文是我的个人理解,如果有误忘告知

自从接触rubyonrails以来,fastcgi这个技术标准就进入了我的视线,从技术角度看,fastcgi的优点还是很多的,作为一种替代cgi的技术标准, fastcgi有如下优点(稳定,安全,高性能,方便扩展)

从稳定性上看, fastcgi是以独立的进程池运行来cgi,单独一个进程死掉,系统可以很轻易的丢弃,然后重新分配新的进程来运行逻辑.

从安全性上看, fastcgi和宿主的server完全独立, fastcgi怎么down也不会把server搞垮,

从性能上看, fastcgi把动态逻辑的处理从server中分离出来, 大负荷的IO处理还是留给宿主server, 这样宿主server可以一心一意作IO,对于一个普通的动态网页来说, 逻辑处理可能只有一小部分, 大量的图片等静态IO处理完全不需要逻辑程序的参与(注1)

从扩展性上讲, fastcgi是一个中立的技术标准, 完全可以支持任何语言写的处理程序(php,java,python...)

但是让我感到迷惑不解的是,apache对fastcgi的支持mod_fastcgi简直就是一塌糊涂, 最新的稳定版本居然还是2003年的,snap也只到2004年, 在1.3下面还勉强可以用, 在apache2.0上更是被报告无法稳定运行.fastcgi在[lighttpd][]上表现还算不错, 但是lighttpd在用户群,兼容性上还不够主流(也就在linux上面表现不错, 没有正式的windows版本, solaris下面也有bug). 另外fastcgi也缺乏发展,让人有被废弃掉了的感觉.(ruby的dbi也是这个状况). 和其他日新月异的技术标准比, fastcgi地位尴尬

 

直到我看到这篇文章才明白,fastcgi真是的命苦.(呵呵,以下的内容取自该文章)

 

从名字上看fastcgi是fast的cgi的,属于改良派.从理论上,他可以很多程序语言接口来开发动态web,但是这些程序语言每一个都是走完全革命的道路. java阵营就自己搞了一套j2ee server标准,要协作也直接找apache或者IIS谈,瞧不上fastcgi. aspx直接和IIS是亲兄弟,没有fastcgi的份. 剩下的php因为太流行(LAMP),和apache是铁哥们,一个mod_php就解决了,简单方便, python社区的牛人太多,精力旺盛,人家搞了个SCGI玩,和fastcgi比是有过之而无不及. 等到rails出山的时候, fastcgi真的算是老态龙钟了.

 

rails的出现使得fastcgi重新焕发了青春, apache也开始重新构建新的mod_proxy_fcgi,但是它的前途还不能说是一片光明, 我觉得至少有以下几个问题

目前的fastcgi和server沟通还不够智能,一个fastcgi进程如果执行时间过长会被当成是死进程杀掉重起,这样在处理长时间任务的时候很麻烦.这样做也使得fastcgi无法允许联机调试.

SCGI等类似技术的都可以替换fastcgi, SCGI在python中很成功,功能完备,目前SCGI也开始支持rails了

随着rails的流行,一个独立的mod_rails是可能出现的,而且ruby自身的webserver也开始涌现,以后极有可能自己搞一套东西连接主流的webserver.fastcgi设计的时候是想作common gateway interface(cgi)的,但是这个目标的现在看来已经不适合了

总结: 我觉得fastcgi的前途不明朗, 但是目前来说,他也是rails唯一可以进入生产环境的工具,只用搞懂怎么配就可以了,没有必要深入研究.

注1: 有时候逻辑也会参与图片的生成,这时候图片的IO处理就需要动态程序介入了,此时fastcgi技术上的优势虽然体现不出来,但是也不会比其他技术标准差