我怎么就觉得rails适合做大型应用

    之前读了不少文章，说rails不大适合做大型的互联网应用或者企业应用，但通过实际的使用rails，越发的发现rails做大型应用是个不错的选择。 说rails不适合做大型应用无非瞄准了rails的2个软肋，一个是ruby的性能，一个是后期的可维护性。 

    先谈谈可维护性吧，可维护性最大的问题是需求的改变，简单的说，取决于项目结束后，客户要求你变更程度的大小与多寡，这更多的是项目管理的范畴，具体到语言的层面，其实意义不大，我们可以想想，一个后期维护的问题放到rails难解决，那么放到java、php……里面就简单了？真要比个优劣的话，我倒是觉得rails更胜一筹，rails本身就是一套良好实践的集合，你按它的规范做，会少走不少弯路，与其说rails是框架级代码的复用，不如说是良好设计和经验的复用。

    咱好好谈谈性能吧，由于rails是个全栈式MVC框架，各个组件之间的搭配都是经过优化的，而采用SSH，需要自行协调各个组件之间的协同工作，稍有不慎，肯定会带来性能上的问题，我想各位看客也知道那个意思，我这里就有个例子，一个用SSH开发的社区网站，速度极其的慢，采用ruby on rails 改版后，速度明显提升很多，当然这可能也和开发者的水平有关，我也懒的去研究为什么当初采用SSH时性能会出现瓶颈，仅仅这个例子，让我知道一个一般的程序员用rails开发出东西未见得比用SSH的东西性能要低。

    当然，上面的例子可能并不具有普遍性，所以说服力也不够。那么总所周知的是，做一个大型应用的杀手锏是“分”，当年的j2ee也是这种理念，尽可能的分，但遗憾的是j2ee分的效果并不太好，或许是过于复杂了，我所知道的java项目大都跑在一台服务器上。当然也是有很多大型java项目还是分布式的，那么既然大家都跑在多台廉价的服务器上，单纯的比单台服务器的速度其实意义并不大，在一个可伸缩的架构中，资源的消耗应该随负载线性上升，负载可由用户流量、数据量等测量。如果说性能衡量的是每一工作单元所需的资源消耗，可伸缩性则是衡量当工作单元的数量或尺寸增加时，资源消耗的变化情况。换句话说，可伸缩性是整个价格-性能曲线的形状，而不是曲线上某一点的取值。

    所以问题归到了架构上面来了，而对于目前或者未来的应用架构，最合理的方式是把一个大型应用拆成许多合理的单元，而内置了REST支持机制的rails将抢占了未来的先机，当然可能这种机制尚不完善，但它的方向我认为是正确的。

那么我对rails的"分"的方案有以下几种思路：

    1 在应用程序的之间水平切分，一个系统拆成各自独立的系统拼接而成，每个独立的系统的后台将做服务器级别的集群，举个例子，校内最近开发的爱听网就是用ruby on rails 开发的，它将是个独立的系统，会作为一个频道拼到现有校内的菜单上，这种方式不错，但相互过于独立，数据共享是个问题。

    2 在应用程序的内部水平切分，这种粒度要小一点，做相册的负责图片，做音乐的负责音乐，做博客的负责博客，用标准的负载均衡服务器来路由进入的流量。所有应用服务器都是均等的，而且任何服务器都不会维持事务性的状态，因此负载均衡可以选择自己的应用服务器。如果需要更多处理能力，只需要简单地增加新的应用服务器。貌似豆瓣是这种模式。

    3 针对具体资源的切分，这种方法是把所有的服务抽象成粒度更小的资源，分布在各个服务器上，在主服务器上通过REST调用展现出来，这样各个服务节点相互独立，不会因为某一节点造成性能上的瓶颈，当然我也不是随便说说，目前准备用这种方式构建一个社会化网络，就目前的感觉---良好。

    4 SOA，相关的功能部分应该合在一起，不相关的功能部分应该分割开来——不管你是否把它叫做SOA，功能分解还是工程秘诀。而且，不相关的功能之间耦合程度越松散，就越能灵活地独立伸缩其中的一部分。我对SOA理解不深，这里有一段访谈倒是蛮有说服力,

 

 

 

 

 

 

 

写道

Engine Yard公司的首席技术官Tom Mornini表示，单机百万线应用的时代已经结束，面向服务架构(SOA)是这一时代的终结者。该公司提供Ruby and Rails主机服务器。
　　他在最近的采访中说“我认为使用大型程序的年代已经结束了”“有些程序看起来很大，但是随着时间的推移，它们将最终成为许多小程序的结合体。”
　　通过为全球市场的业务提供灵活性，SOA的可组合性改变了应用开发比赛。在全球市场中，商业机会不是一成不变的。
　　Mornini说“我实在看不出任何其他方式可以满足存取数据，改变流体的需求，以便在企业内外跟上时代的步伐。”“这就是为什么未来能解决所有问题的单机百万线应用在这一点上仅仅是个遗迹。”
　　Mornini认为，这不再是SOA是传统应用开发选择的问题，而是除了SOA以外，我们没有其它的选择。
　　他说“这些大型程序很难管理和维护，很难想像单机应用会成为未来发展的方向”。
　　Engine Yard公司的首席技术官认为带有REST的Ruby on Rails是为SOA建立新一代的服务和应用的一种方法。与Java不同，Java是在SOA应用开发时代前开发的项目，他注意到，Ruby on Rails 和REST怀抱SOA为理念向世人提供了一个前所未有的方法。
　　Mornini说“拥有一个服从该框架的牢固而又深厚的面向服务架构就是Rails的秘诀”该架构的开发商认为（它的SOA功能）是该平台的一大优势。
　　他认为Ruby on Rails非常适合SOA开发。新发布的Rail 2.0令该框架更容易为SOA应用以及旧数据存取所接受。他承认，原有的Rails框架与旧数据存取关系并不是十分融洽。今年推出的新模型已经超过了前者。
　　他说，例如，Rails组提供的代码增加了许多新的功能，通过以服务的形式将旧数据曝光，使得在SOA应用中访问旧数据变得更为简便。
　　Engine Yard公司的首席技术官说 “由于遵循了售后服务书籍和网络视频记录的规程，Rails令开发商使用RESTful数据变得更为简单”。
　　他说，“如果你遵循RESTful Rails的标准过程，在系统外用Rails编写了一个程序，就会自动得到该程序展示的一个建立在XML-over-HTTP基础之上的API。
　　但是如果要使其运转，"继续使用 Rails"很重要。Mornini说这就是Rails遵循既定规程的妙招。

 

 

 

 

 

评论

254 楼 gigix 2008-08-27  

ltian 写道

gigix 写道

ltian 写道

你说的那些风险管理的东西，和给我做CMMI培训的人说的一模一样，你原来搞过CMMI？

那个…人类早在有CMMI之前很多年就开始风险管理了好哇？

那个。。。我是说你说话的口气很象那个CMMI咨询师。

唔…
那说明你们买的CMMI咨询至少在风险管理的理论基础这一部分是靠谱的，恭喜

引用

你发这种东西有意义吗？扣30分还不过瘾？明显是在挑逗，吵架

没觉得啊…CMMI咨询师怎么了？莫非又有了”你才是CMMI咨询师，你们全家都是CMMI咨询师“这样的说法？

253 楼 liuqiang 2008-08-27  

<div class='quote_title'>ltian 写道</div>
<div class='quote_div'>
<div class='quote_title'>gigix 写道</div>
<div class='quote_div'>
<div class='quote_title'>ltian 写道</div>
<div class='quote_div'>你说的那些风险管理的东西，和给我做CMMI培训的人说的一模一样，你原来搞过CMMI？ <br/></div>
<br/>那个…人类早在有CMMI之前很多年就开始风险管理了好哇？</div>
<br/><br/>那个。。。我是说你说话的口气很象那个CMMI咨询师。 <br/></div>
<p> </p>
<p>明显是在挑逗</p>
<p> </p>

252 楼 pufan 2008-08-27  

gigix 写道

pufan 写道

ye_jian_hui 写道

得了，人家的经验都是扯谈，你自己的经验才是最重要的。

PS：这年头做好人还真是难啊。

是骡子是马拉出来遛遛，讲大话谁不会啊，就怕有脸出来没脸回去。

我早说了，直接认栽
pufan同志说得对的，我说那些什么狗屁第一原则，都是我自己胡诌的，pufan同志英明神武，一眼就看穿我这点小伎俩
pufan同志很正确，我回家思过去
（to ye_jian_hui: 说几句口水话就让他一辈子以为花生是树上长的，这生意多划算。）

你看，教坏了小朋友不是，误人子弟啊，ye_jian_hu同学，别介意啊。

251 楼 gigix 2008-08-27  

ltian 写道

你说的那些风险管理的东西，和给我做CMMI培训的人说的一模一样，你原来搞过CMMI？

那个…人类早在有CMMI之前很多年就开始风险管理了好哇？

250 楼 gigix 2008-08-27  

pufan 写道

ye_jian_hui 写道

得了，人家的经验都是扯谈，你自己的经验才是最重要的。

PS：这年头做好人还真是难啊。

是骡子是马拉出来遛遛，讲大话谁不会啊，就怕有脸出来没脸回去。

我早说了，直接认栽
pufan同志说得对的，我说那些什么狗屁第一原则，都是我自己胡诌的，pufan同志英明神武，一眼就看穿我这点小伎俩
pufan同志很正确，我回家思过去
（to ye_jian_hui: 说几句口水话就让他一辈子以为花生是树上长的，这生意多划算。）

249 楼 pufan 2008-08-27  

ye_jian_hui 写道

pufan 写道

ye_jian_hui 写道

pufan 写道

还有那个通讯第一原则更是扯，按我看第一原则是减少传输量，网络传输的最小单元是bit，文本又是什么东西。

To pufan:
我建议你先看看《UNIX编程艺术》里关于网络协议部份的说法再下定论也不迟。虽然里面说的不一定就是真理，但也是那些大师门多年的经验之谈。这年头可能谁也不比谁聪明，但肯定有不少人比自己懂得多，说话还是谦虚点好。

没工夫，你若有不同看法敬请发表。

别整天大师大师们的，人家的经验是人家的，你就是天天引用也未必会归你所有。

得了，人家的经验都是扯谈，你自己的经验才是最重要的。

PS：这年头做好人还真是难啊。

是骡子是马拉出来遛遛，讲大话谁不会啊，就怕有脸出来没脸回去。

248 楼 ye_jian_hui 2008-08-27  

pufan 写道

ye_jian_hui 写道

pufan 写道

还有那个通讯第一原则更是扯，按我看第一原则是减少传输量，网络传输的最小单元是bit，文本又是什么东西。

To pufan:
我建议你先看看《UNIX编程艺术》里关于网络协议部份的说法再下定论也不迟。虽然里面说的不一定就是真理，但也是那些大师门多年的经验之谈。这年头可能谁也不比谁聪明，但肯定有不少人比自己懂得多，说话还是谦虚点好。

没工夫，你若有不同看法敬请发表。

别整天大师大师们的，人家的经验是人家的，你就是天天引用也未必会归你所有。

得了，人家的经验都是扯谈，你自己的经验才是最重要的。

PS：这年头做好人还真是难啊。

247 楼 qichunren 2008-08-27  

火星叔叔马丁 写道

已改正

PS:头像是偶家mm，辛苦的追求ing

请问一下，你家MM也是来自火星的吗？

246 楼 gigix 2008-08-27  

liuqiang 写道

我一再申明，新手能力不见得比老手低，最近不才就遇到一位号称几年工作经验的老程序员，分不清rails、RIA、分布式的概念，越发的觉得能力和经验无关，但该老程序员的质量意识还是蛮高的，一再苦口婆心权大家：UI其实很重要的，企业级开发没你想的那么简单，这是好事，至少有风险意识比没有好。

这个，不叫风险意识，叫瞎操心。
什么叫风险管理？识别风险，量化风险，选择应对策略，适时规避，适时缓解，适时承担。
有风险的生意才是有margin的生意。
面对未知连看清楚的勇气都没有，一味缩手缩脚，这不是有风险意识，这只是胆怯。

与熊共舞 写道

风险越大，回报也越大--尤其是在软件行业里。逃避风险的企业将很快被竞争对手远远抛在身后。但是，由于管理者的不审慎（他们自己更喜欢的说法是"乐观的思维"或者"'我能做到'的态度"），软件企业常常被置于一种尴尬的两难处境：要么承担风险而失败，要么回避风险而落后。

245 楼 风清云淡 2008-08-27  

ltian 写道

好，我对Grail也有兴趣，不过我是java+pureMVc+BlazeDs+Flex做的电力营销系统。试运行了。用户反映还不错。
提醒你一下， 做大系统pureMVc慎用，这个框架看起来不错，但是一旦消息过多，你不知到发出的消息谁会感兴趣。那么调试和维护将会非常难，有时候一个消息会被监听多次，多次执行后台数据请求，这些问题都很隐蔽。
我们后来开发的功能已经不用pureMVc了。而且注意pureMVc有多核版。如果一个View要被两个界面引用并同时打开，你需要用多核 PureMVC。我博客里面有我翻译的pureMVc中文API，以及Flex相关文档，可以供参考。

呵呵，多谢，以后得向你请教。现在正在摸索中。
这方面我有深刻的教训：在．ｎｅｔ的ｒｅｍｏｔｉｎｇ刚出来的时候，尝鲜做了一个高并发量的大型分布式系统，结果死的很难看，后来对新技术就谨慎使用了。很多东西，做个小ｄｅｍｏ例子是无法发现问题的。
ＰＳ：ｇｉｇｉｘ和ｒｏｂｂｉｎ要多写帖子，说说自己对ＲＯＲ的心得和经验，让后来人少趟点雷！

244 楼 Readonly 2008-08-27  

这贴真热，偶也来做个road map：

gigix: 代码少是王道
ltian: 用几千行写个大型系统给偶看看
Quake: JavaEye的代码是5千多行
ltian: JavaEye就是一CRUD的论坛，偶说的是大型企业应用，企业应用你们懂么？
gigix: 又是老调调
ltian: 偶可不是老调调，你们显然没有做过偶说的那种大型企业应用。
众人:   那么到底啥是企业应用？
ltian: 界面贼复杂的那种，有window，grid, tree N个复杂控件的那种才叫企业应用，Rails能够搞定么？
众人:   Orz...

ltian: 企业应用的V很重要
众人:  无语
ltian: Rails搞不定这些企业应用
路人甲: 这和Rails没有关系...

ltian: 企业应用的V很重要
众人:  无语
ltian: Rails搞不定这些企业应用
路人乙: 这是javascript的内容...

ltian: 企业应用的V很重要
ltian: Rails搞不定这些企业应用

ltian: 企业应用的V很重要
ltian: Rails搞不定这些企业应用

ltian: 企业应用的V很重要
ltian: Rails搞不定这些企业应用

这样这个帖子就吵了30多页...

243 楼 liuqiang 2008-08-27  

<div class='quote_title'>ejb3 写道</div>
<div class='quote_div'>各位真能扯，鉴定完毕，笑了我一个半小时</div>
<p> </p>
<p><span style='color: #ff0000;'>注意，此类话题已转向：</span></p>
<p><a href='http://www.iteye.com/topic/231725?page=5'><span style='color: #ff0000;'>http://www.iteye.com/topic/231725?page=5</span></a> ， 欢迎讨论。</p>
<p> </p>
<p> </p>
<div class='quote_title'>verygoodverypowerful 写道</div>
<div class='quote_div'>我很想问下你当新手的时候新在哪里</div>
<p> </p>
<p> 同理啊。</p>
<p>回应一下，我对新手绝无贬低的意思，只是拿出来讨论下，找到问题，解决问题，这样对新手也是个提高。</p>
<p>我一再申明，新手能力不见得比老手低，最近不才就遇到一位号称几年工作经验的老程序员，分不清rails、RIA、分布式的概念，越发的觉得能力和经验无关，但该老程序员的质量意识还是蛮高的，一再苦口婆心权大家：“UI其实很重要的，企业级开发没你想的那么简单”，这是好事，至少有风险意识比没有好。</p>
<p><a href='http://www.iteye.com/topic/231725?page=5'/></p>

242 楼 风清云淡 2008-08-27  

我不知道什么是企业级应用的定义，《企业应用架构模式》那本书下的定义貌似也不能覆盖中国企业千奇百怪的需求。反正俺就一民工，做了N年的企业“大杂烩”系统。

1.对这些“大杂烩”的痛苦在于需求很难界定，需求很繁杂，需求变更几乎不可控，搞的业务好像碎片一样，觉得难以掌握。痛苦过后俺开始用”领域建模“来驱动设计了，确实能从纷繁中见核心，业务模型清晰易懂。团队能抓住用户业务的核心关系和价值了。

2.用户对界面的挑剔，又让我抓狂，好羡慕delphi、PB、.net，但没办法用户就认准B/S，从自己用js做UI组件到echo，extJs，现在开始接触FLEX，好像有点儿看见黎明的曙光了（我强调的是要平衡效果和开发成本，那种有专业交互设计师和美工的哥们儿就别揶揄俺了，^_^）。

3.JAVA各种开源框架多的让人眼花缭乱，但就是没有俺想要的那种感觉，虽然俺也饱读各种OO设计、设计模式的书籍，对低耦合、高内聚甚至到了”膜拜“的地步，也会经常一个人熬夜重构-精雕细琢代码，但就是觉得这么多分层、配置以及许多不爽的地方(太多了，一下子说不过来），好像让人写代码的时候，背了很多包袱在前行，只有用”写程序本就是苦差事“来安慰自己和项目组内的兄弟。看到rails和grails让我有种轻松的感觉，不过俺没实际用这东东做过项目，希望它能让兄弟们轻松点，多点时间陪陪GF/LP。

241 楼 pufan 2008-08-27  

ye_jian_hui 写道

pufan 写道

还有那个通讯第一原则更是扯，按我看第一原则是减少传输量，网络传输的最小单元是bit，文本又是什么东西。

To pufan:
我建议你先看看《UNIX编程艺术》里关于网络协议部份的说法再下定论也不迟。虽然里面说的不一定就是真理，但也是那些大师门多年的经验之谈。这年头可能谁也不比谁聪明，但肯定有不少人比自己懂得多，说话还是谦虚点好。

没工夫，你若有不同看法敬请发表。

别整天大师大师们的，人家的经验是人家的，你就是天天引用也未必会归你所有。

240 楼 ejb3 2008-08-27  

各位真能扯，鉴定完毕，笑了我一个半小时

239 楼 ye_jian_hui 2008-08-27  

pufan 写道

还有那个通讯第一原则更是扯，按我看第一原则是减少传输量，网络传输的最小单元是bit，文本又是什么东西。

To pufan:
我建议你先看看《UNIX编程艺术》里关于网络协议部份的说法再下定论也不迟。虽然里面说的不一定就是真理，但也是那些大师门多年的经验之谈。这年头可能谁也不比谁聪明，但肯定有不少人比自己懂得多，说话还是谦虚点好。

238 楼 t0uch 2008-08-27  

lz:我看rails适合做大型应用
gi:恩恩，我也这么看
众人：嗯嗯，我们也这么看

突然杀出v lord

v lord:rails就是一sb才用的，还ruby，简直就是扯淡。还5行代码，忽悠人也不能这么夸张哇。rails比得上RIA吗？？哼哼，傻了吧。

(恩，确实，显示器比鼠标好用多了)

众人挑出几个精英，组成v字仇杀队，对v lord进行围剿

继续围剿...

还在围剿...

237 楼 cquaker 2008-08-27  

什么v不v的，美工审美感好一点比啥都强，flex也不例外。

236 楼 jemysky 2008-08-27  

乱 
一个字就是乱
如果小学写作文
这篇作文不及格


我目前有一个erp要做，在参考用什么比较好，公司传统是用c#.net，用的工资自有框架，不过在我看来效率不敢认同，请大侠们指点一下

235 楼 Ashela 2008-08-27  

火星叔叔马丁 写道

对于一个企业应用，良好架构，良好设计重要性居然不如你所说那几个V？
况且这些v和rails无关，你用RIA实现，我就不能在前台用RIA了

不知道Itian是装傻还是卖傻[/quot]
V 都做不出来你做的后台给谁用啊。难道你做得企业应用没有V？真是太天真了。就算良好架构，良好设计比V的重要性重要1000倍，连V都做不好还空谈什么啊？

我还真做过很复杂的企业应用没有V的，后期扩展也就加了两个V而已