rails3项目解析之1——系统架构

在服务器版本的选择上比较好奇，为什么选择使用Ubuntu这个称霸个人桌面的服务器版？
我对Ubuntu的印象还只停留在个人版(从7.1到8.04)。
为什么不考虑使用Centos？个人感觉无论从版本更新，功能安全，还是使用习惯上都要更好些。而且多机负载均衡也好处理些。
另外，Mysql自身的负载均衡也很完善，但是从你文中好像没看出来有很好的应用？

服务器发行版选择ubuntu server，也算是一种个人爱好吧。作为rails的运行平台，无论是各种组件的安装还是问题的解决，相对都比较顺利。至少就我个人感觉，ubuntu似乎已经成为rails平台的标配，网上的教程和示例大多数都是以ubuntu为基础的。我们也曾经在公司遗留的centos上安装过rails，有一些问题还是很麻烦的。

版本更新上，ubuntu已经不输于centos，可以说有过之而无不及。从功能安全上，少安装点不必要的包，iptable规则严格一点，时常自动更新内核，也就差不多了。至于使用习惯，我们团队还是都更习惯ubuntu的，毕竟开发桌面以ubuntu居多，都是同一家的孩子，desktop和server是一脉相承的。多机负载均衡我感觉centos和ubuntu没什么本质上的区别，不知道你所指是哪方面。

你说的mysql的负载均衡，是指mysql ndb cluster吗。我们也评估过它，一是感觉太复杂，对我们的项目有点大材小用，二是我们看过一些网上的评价，很多用过的人还是持保留态度的。就算是mysql proxy之类的读写分离方案，仍然感觉有些复杂。似乎mysql原生的扩展方案都让人不是很舒服，所以干脆就只用replication做高可用了，实质上还是单机。前面我也说过，对我们的项目来说，结合nosql，单机也够用了。如果实在要扩展mysql，倒不如直接用handler_socket来得彻底。

应该也是为了寻求尽量贴合项目实际的方案吧，要是公司告诉我们做个一千万PV的，我们也就不用现在这套方案了。

不错呀，看了受益很多，公司里面就我们team在做ruby on rails尝试，都要从头积累呀，虽然比较累，但是很有意思，风险上很小，都是针对公司内部的管理系统上做尝试，允许出错。另外，公司评论已经上mongodb了，15台服务器的规模，貌似在国内是最大的了吧？不过我们ror组还没用mongodb，语言换新的就很累了，数据库再换了就会疯掉的。

希望能看到楼主更多的心得，我也愿意在ror使用中分享一些东西，希望对国内ror会有所促进。我们已经在跑的一台ror服务器是apache2.0.x+passenger，不是最优的搭配，以后会再调整，数据库是MySQL，前端就加了个memcached，因为不是做WEB，是做的API用的，每天接口调用在240万次左右，等负载高了肯定还得优化系统、加服务器呀。数据库方面读取都cache在memcached里面了，写操作是通过文件缓存来做的，比较简单：每个数据insert或者update等请求写一个文本文件，不用加锁，另外有进程定时扫描这些文件，入库后删之，所以MySQL负载很轻。

你们公司也很前卫啊。而且都不是小项目。希望你有时间分享一些你们公司海量数据和高并发系统的最佳实践，大家一起学习。

支持楼主这样实践型的老师多发博文。

看来楼主在网站架构这方面绝不是新手啊.　

请教下:　　你们在front-end server和db-server这里都用keepalived来保证高可用性.　这个方案成熟么?　对技术人员的要求如何?

keepalived本身是比较成熟的，在front-end用keepalived来做高可用，也算是比较成熟。不过个人感觉keepalived本身有一些局限性，比如服务器完全挂掉的时候keepalived很管用，但如果服务器正常，但本地的nginx服务无响应，就比较麻烦了。keepalived虽然也有检测本地服务的模块，但并不是一检测到本地服务失效就马上切换到另一台，不是我想要的效果。我研究了一段时间也没找到解决方案，不知道是我没找到，还是本来就如此。

keepalvied配合mysql的master-master复制来做高可用，是我自己琢磨的。做完了之后在网上一搜，才发现已经有人这么做了。但这个方案并不是很成熟，主要是因为mysql的复制是有一段极小的时间间隔的，如果在mysql尚未同步完成时，keepalived就切换了主从，容易造成mysql的id重复。当然这也可以解决，比如设置自增id的步长即可，不过我不喜欢这样。但总之，keepalived配合mysql，不是很成熟。

本来我是想通过修改activerecord来实现mysql master-master的自动服务转移，后来感觉比较麻烦，所以就没做，省了个事用keepalvied来实现。如果真要做可靠的mysql高可用，还是建议在rails端解决，或者是用更好的方法消除两台mysql数据同步的潜在冲突，比较好一些。其实最好的还是原生方案，象mongodb那样的，在数据库的层面就避免这个问题，这是最优的解决方案。

对技术人员没什么太高要求，keepalived比较简单，文档也算充实，一般的技术人员都能看明白并且配置成功。

对 楼主的 系统架构很是佩服。光这里列出的几种技术，就需要10年以上的功力。

弱弱的问一下，团队中有几个人能独立安装如此一套系统？万一某位大牛 私奔，如何应付。

我揣摩一下 贵网的业务模式，抛砖引玉 。

如果 是“向用户提供财经金融资讯”，应该有相当大的的比例是重复性的内容，如果利用静态缓存，可以大大降低页面渲染的需求，自然很多 缓存和负载均衡 可以省掉。

金融类，应该有明显的高峰时段，比如股票的开盘和收盘，100万 PV，可能瞬时能达到 20万/小时（参见财帮子的资料）。在高峰期，如果200ms 一个PV，估计要 16CPU 满负荷。

如果每分钟更新一次，一天最多1440次，有100种业务产品，也就是14万次PV。即使在
高峰期达到40 万，甚至更多，也不担心。

这样，rails 只需要通过 用户权限 控制一下访问页面的静态地址 ，这是简单的内存计算，可以做到 双CPU 2000/s。

对于Gluster ，我还有些怀疑，毕竟一个目标太大的项目，注定要经历漫长的考验。
http://blog.csdn.net/liuben/archive/2011/03/28/6284551.aspx

最简单的当然是NFS，拿一台旧服务器，换上RAID0+1 ,SAS  15000,甚至SSD，完全可以实现1000+ 的 IOPS。加上一个 定时备份，也足够可靠了。

总之，我的做法比较保守，尤其不愿意在系统架构上过多的投入。

我的方案是 NGINX + 多台 rais主机，memcache ，NFS ，MYSQL 5.5 主备。呵呵太简陋了，见笑。

1、要说到“独立”安装这么一套系统，确实是有点复杂，但也不是特别困难。只要把安装文档写详细了，按照步骤来安装服务器，应该问题不大，无非就是一些apt-get之类的，再加上些配置。把配置文件备份好了直接还原就很快了。代码部署是用capistrano写的，几个命令就搞定，也不存在困难。比较麻烦的是真正理解这套系统，而且出了问题能知道在哪儿，这就看个人的造化了。大牛私奔总是比较头疼的事，所以我们团队的目标是把每一个人都培养成大牛，私奔几个都不怕。

2、关于业务模式和流量的推测，看得出来你很有经验，只是有点抬举我们了。我们是个小网站，刚上线没多长时间，还没有开始大范围推广，流量很小。但是即使流量大了，我们也不太想采用静态页面这种方式。因为毕竟网站业务还没成型，需求变化很快。互联网业务的特点就是多变，有可能今天的静态页面，明天就要大范围改动和调整，或者忽然要求加上很多动态的内容。而且象金融资讯这种比较专业的网站，一般也到不了新浪那种有必要使用静态页面的程度。因此在相当长的一段时期内，我们还没有考虑静态页面。单纯的资讯页面，加上缓存，几台服务器支撑一下还是问题不大的。

3、gluster确实目标比较远大。而且当初我们选用它，也是因为它不改动操作系统内核，所以再怎么折腾也不会对系统造成致命的影响。我们目前用的主要还是gluster的replication高可用的那部分功能，有一些小问题（比如没有文档中所说的自动同步），但目前看来还是可用的。至于以后会不会用到distributed和striped等横向扩展，到时再说。说不定到时有钱了就上硬件了。走一步看一步吧。

4、你的架构不能说简陋，其实最简单的才是最有效的。我之所以做的这么复杂，也是因为我这人爱折腾，平时没事就升级个服务器重启下什么的，所以才做个没有单点的架构。个人爱好而已。呵呵。

5、nfs当然很可靠，只是我没找到怎么用nfs做高可用，一台服务器我又不放心，所以就找到了gluster来做这个，而且在gluster上也是用的nfs协议，兼容性不错。至于说访问文件的速度，这个我们没有通过gluster的read接口来做，我们只是用gluster来写文件，下载的时候绕过gluster直接用nginx读取本地文件，速度上暂时没有问题。

6、请问一下你的mysql 5.5主备，是怎么做的。5.5不能在配置文件里写主备复制的参数了，你是用脚本做的，还是启动起来之后再登录mysql敲命令？