［讨论］部署Rails的最佳方案是什么？

从来没真正部署过一个production级别的rails应用，但是9月份很可能要部署一个，所以最近也开始关注Rails的部署问题。这里算是抛砖引玉吧，还请各位有经验的同志热烈讨论，我想很多人也都对这方面很感兴趣。

Robbin之前的帖子里面讨论过如何选择Rails的部署方案，也挺详细的，我估计硬件和操作系统方面大家分歧应该不大，总归是linux，服务器越强劲，内存越大越好。所以问题就到了软件方面。数据库大概也不用怎么讨论，mysql之类的东西大家心里都有数。关键还是server的问题。

JavaEye现在用的server应该是lighttpd和fastcgi吧，从大家浏览网站的体验上看，性能还是不错的。Robbin有写文章讲过如何安装这些server，但是很想知道选择这些server的原因。apache应该是最传统的选择，为什么Robbin没有选它呢？

ThoughtWorks的RubyWorks选择的是HAProxy和Mongel，这里没有静态web server，文档里说可以用apache和一个叫nginx的东东。我想大公司选择这些东东作为RubyWorks的默认安装，肯定是有原因的吧。那它们的lighttpd+fastcgi比较起来如何呢？gigix也许可以解释一下。

如果有哪位大哥可以总结一下目前比较流行的server组合，说说各自的优缺点，那小弟真是感激不尽啊。

另外，我个人觉得选择server的时候，不单单要看功能和性能方面，还要看安装配置是不是比较简单，不知道各位是否同意这一观点呢？

FastCGI最大的问题是不成熟，稳定性不够，即便像DreamHost这样老资格的shared host也经常出现FastCGI进程挂死的情况。至于Apache，我们还没有看到把它放进统一配置的需求，也许以后会加进去。
我列举了几个一站式的Rails环境安装方案：http://gigix.thoughtworkers.org/articles/2007/07/05/existing-rails-deployment-stacks

谢谢解释，我刚才也去看了一下JavaEye以前的帖子，Robbin说apache首先可以排除，也不知道为什么，呵呵。
PS：ThoughtWorks啥时候来上海开分公司啊？我毕业想去那里工作呢。

那你申请北京分公司吧。反正是要经常出差的。

Rails部署也算是个不错的topic
楼主可以调研、试验一番，各种方式来个对比，然后写篇总结

RoR的部署方式从架构上来说分为前端和后端：

一、前端
前端的作用就是处理静态资源，将动态请求分发到后端，有时候也带有一些额外的功能，例如对特定URL进行rewrite和redirect，对HTTP输出进行gzip压缩等等。

前端目前已知的可以选择apache, lighttpd, litespeed, nginx, haproxy

1、apache2.2
apache是全球市场占有率最高的web server，超过全球互联网网站50%的网站都用apache。apache2.2 + mod_proxy_balancer是一个非常流行，非常稳定的方案。

使用apache2.2唯一的问题就是apache的性能和后面那些轻量级web server相比，差太远了。一方面在处理静态请求方面apache要比lighttpd慢3-5倍，内存消耗和CPU消耗也高出一个数量级，另一方面mod_proxy_balancer的分发性能也不高，比haproxy差很远。

2、lighttpd
lighttpd是一个轻量级高性能web server，一个在MySQL Inc工作的德国人写的。性能很好，内存和CPU资源消耗很低，支持绝大多数apache的功能，是apache的绝好替代者。目前lighttpd已经上升到全球互联网第四大web server，市场占有率仅此于apache，IIS和Sun。

lighttpd唯一的问题是proxy功能不完善，因此不适合搭配mongrel来使用。lighttpd下一个版本1.5.0的proxy模块重写过了，将会解决这个问题。

3、litespeed
和lighttpd差不多，商业产品，收费的。比lighttpd来说，多一个web管理界面，不用写配置文件了。litespeed专门为单机运行的RoR开发了一个lsapi协议，号称性能最好，比httpd和fcgi都要好。他的proxy功能比lighttpd完善。

litespeed的缺点我却认为恰恰是这个lsapi。因为lsapi不是web server启动的时候启动固定数目的ruby进程，而是根据请求繁忙程度，动态创建和销毁ruby进程，貌似节省资源，实则和apache2.2进程模型一样，留下很大的黑客攻击漏洞。只要黑客瞬时发起大量动态请求，就会让服务器忙于创建ruby进程而导致CPU资源耗尽，失去响应。

当然，litespeed也支持httpd和fcgi，这个和lighttpd用法一样的，到没有这种问题。

4、nginx
一个俄国人开发的轻量级高性能web server，特点是做proxy性能很好，因此被推荐取代apache2.2的mod_proxy_balancer，来和mongrel cluster搭配。其他方面和lighttpd到差不多。

要说缺点，可能就是发展的时间比较短，至今没有正式版本，还是beta版。没有经过足够网站的验证。

5、haproxy
就是一个纯粹的高性能proxy，不处理静态资源的，所有请求统统分发到后端。


二、后端
后端就是跑ruby进程，处理RoR动态请求了。运行后端ruby进程有两种方式：

1、fcgi方式
准确的说，不能叫做fcgi方式，其实就是启动一个ruby进程，让这个ruby进程监听一个tcp/unix socket，以fcgi协议和前端通讯。所以fcgi不是指ruby进程的运行方式，而是ruby进程使用的通讯协议。这就好比你tomcat可以用http，ajp通讯一样，tomcat自己的运行方式都一样的，只是通讯方式不一样。

fcgi方式启动ruby进程，可以使用lighttpd带的一个spawn-fcgi工具来启动(JavaEye目前采用这种方式)。

值得一提的是，apache2.2的mod_fastcgi的方式也上面还不太一样，由apache动态创建fcgi进程和管理fcgi进程，这种方式和litespeed的lsapi面临的问题是一样的，此外apache的mod_fastcgi自己也有很多严重的bug，是一种很糟糕的部署方式。这种糟糕的部署方式也败坏了fcgi的名声。

fastcgi只是一种协议，虽然古老，但并不是不好用，http协议也很古老。没有必要因为apache的mod_fastcgi的运行方式的问题而连带把fastcgi都一同否定了。

2、http方式
也就是用mongrel去跑ruby进程，由于mongrel实际上已经是一个简单的http server，所以也可以单独作为web server使用。mongrel现在越来越受欢迎了。

用fcgi方式还是http方式，我个人觉得区别不大，关键还是看应用的场合，一般而言，推荐的搭配是：

lighttpd ＋ fcgi 或者 nginx ＋mongrel，而apache因为性能差距，而不被推荐。

JavaEye为什么用lighttpd ＋ fcgi呢？原因如下：

1) lighttpd发展了好几年了，市场占有率也相当高，是一个经过实践检验的server，它的文档也很全；而nginx还没有经过足够的市场检验，文档也很缺乏
2) JavaEye的ruby进程和web server在一台机器上面跑，通过unix socket使用fcgi协议通讯可以避免tcp的网络开销，其通讯速度比使用tcp socket使用http协议通讯要快一些。

什么场合使用haproxy？

大规模部署，例如你的RoR应用到十几台服务器上面去，你用haproxy会更好，可以方便的添加删除应用服务器节点，proxy性能更好。

RubyWorks Production Stack就是haproxy+mongrel的

谢谢你的详细讲解，受益匪浅。我看Agile Web Development with Rails 2e里面说fastcgi总是会出现莫名其妙的问题，而mongrel则是未来的一个趋势，因此它推荐使用mongrel而确实也说道one-box下使用fastcgi也可以。

也许可以先用lighttpd+fastcgi搭配，然后当lighttpd对mongrel的支持增强后再换到mongrel。

很是奇怪，既然lighttpd性能这么好，呼声这么高，咋没有谁弄个lighttpd+XXX的one-stack安装包出来呢。

haproxy+mongrel

静态资源怎么处理？直接交给mongrel？
把haproxy整合进lighttpd多好，呵呵

第一，不是fastcgi有问题，fastcgi只是一个协议(程序之间的语言)，是apache的mod_fastcgi这个模块有问题。打个比方，有个人英语水平很差，和你用英语对话，总是结结巴巴的，那你说是英语(fastcgi)这种语言有问题呢？还是和你对话的这个人(mod_fastcgi)有问题呢？

第二，分布式部署使用lighttpd + fastcgi也是已经被证明了非常stable的方案，至少是目前RoR方案当中performance和stablition最好的。

第三，lighttpd下一个版本1.5.0搭配fastcgi还是通过http proxy代理到mongrel，没有什么区别。1.5.0已经把这两种协议统一在一个module里面了。但是单机情况下，使用fastcgi比走http有一个额外的优势，就是通过unix socket通讯，可以降低通讯开销。

第四，one-stack的installer也只有ThoughtWorks一家在做，没有其他人在做。你也可以问问他们，为什么不做apache的installer，为什么不做nginx的installer，为什么不做litespeed的installer。

第五，传统Unix的Adminstrator都不屑于使用one-stack installer这种东西。高性能的Server需要通过自己手工安装和调整每一个参数来取得最好的效果。这是one-stack installer这种东西做不到的。打个比方，你有没有见过专业的摄影师用傻瓜相机的？