我怎么就觉得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遵循既定规程的妙招。

 

 

 

 

 

评论

14 楼 苹果侠 2008-08-25  

各人觉得现在的ROR更适合做OLAP的应用而不是OLTP。

13 楼 liuqiang 2008-08-25  

<div class='quote_title'>murainwood 写道</div>
<div class='quote_div'><br/>至于那个MFC,抱歉,我大学同班同学有好几个在做MFC,当然,在写汇编的也有两个. <br/><br/></div>
<p> </p>
<p> 没太明白，你的意思是现在你同学还有几个在做MFC?我没感到惊奇，我同学也有做MFC的，您的意思是？</p>

12 楼 murainwood 2008-08-25  

呵呵,这里有多少人是设计过大型的企业应用?请他们来说说吧.
至于那个MFC,抱歉,我大学同班同学有好几个在做MFC,当然,在写汇编的也有两个.

11 楼 liuqiang 2008-08-25  

<div class='quote_title'>gigix 写道</div>
<div class='quote_div'>
<div class='quote_title'>liuqiang 写道</div>
<div class='quote_div'>还是Readonly老大快人快语，我之前也是听到许多对于rails做大型应用的诟病，通过我的理解，觉得不然，忍不住说说自己的看法。 <br/><br/>大型应用的核心确实在于架构，我仍然觉得利用rails/rest构建大型应用比较适宜</div>
<br/>其实，代码越少越容易维护，这个对于大型应用更要紧</div>
<p> </p>
<p> gigix的这种理解从实际来看，是个经验之谈，不错的建议<img src='../../../../../../images/smiles/icon_idea.gif' alt=''/>。</p>
<p> </p>
<p>但之前听gigix说，单个方法的代码行平均5行，并给了例证，我想这在rails中是可以做到的，但换到java，我想就有吹水的嫌疑了吧<img src='../../../../../../images/smiles/icon_cool.gif' alt=''/>。</p>
<p>这也从一个方面说明了做大型应用，rails的可维护性是非常好的，当然这也建立在有足够多的rails开发经验之上。</p>

10 楼 toostupid 2008-08-25  

不过用rails开发企业应用最好自己写插件与改善框架。
开发成本并不高。

9 楼 liuqiang 2008-08-25  

<div class='quote_title'>toostupid 写道</div>
<div class='quote_div'>rails不兼容前版本是个问题。</div>
<p> </p>
<p> 其实我觉得随着rails2的发布要好多了，保持着内核的精简，不必要的东西分给插件完成，就像那个什么eclipse似的，rails的可扩展性大大增强。</p>
<p> </p>
<p>另外apache tomcat也存在兼容问题，开源嘛，多少都有这个问题：）</p>

8 楼 toostupid 2008-08-25  

rails不兼容前版本是个问题。

7 楼 花花公子 2008-08-25  

刑天战士 写道

性能有框架的因素，很大。

维护的话，和人和语言都有关系。

RoR最大的弱点是不后项兼容和plugin没有多少好的（比java少多了）

而且很多plugin自己也不后项兼容，好多还都是hack框架来做的

个人理解。

没有多少好的是什么意思？现有的插件已经能帮你解决很多问题了。实在不行你也可以自己写。

Java有插件吗？

6 楼 liuqiang 2008-08-25  

<div class='quote_title'>liping 写道</div>
<div class='quote_div'>J2EE发展这么多年 比ROR更加成熟吧！在企业计算方面。j2EE的稳定性,成熟度,资源等等比ROR更好.ps..性能和维护更多的是有人的因素。</div>
<p> </p>
<p> 稳定性,成熟度,资源，这也是J2EE最后的一块遮羞布，要比这些我更看好MFC，结果世道变了，MFC的稳定性,成熟度,资源已是昨日黄花。</p>
<p> </p>
<p>最近校内采用rails+flex开发新的系统，我拭目以待，至于兼容性我想每个语言都有，相对于php从4-5，我觉得rails要好多了。</p>
<p> </p>
<p> </p>
<p> </p>

5 楼 刑天战士 2008-08-25  

性能有框架的因素，很大。

维护的话，和人和语言都有关系。

RoR最大的弱点是不后项兼容和plugin没有多少好的（比java少多了）

而且很多plugin自己也不后项兼容，好多还都是hack框架来做的

个人理解。

4 楼 liping 2008-08-25  

  J2EE发展这么多年 比ROR更加成熟吧！在企业计算方面。j2EE的稳定性,成熟度,资源等等比ROR更好.ps..性能和维护更多的是有人的因素。

3 楼 gigix 2008-08-25  

liuqiang 写道

还是Readonly老大快人快语，我之前也是听到许多对于rails做大型应用的诟病，通过我的理解，觉得不然，忍不住说说自己的看法。

大型应用的核心确实在于架构，我仍然觉得利用rails/rest构建大型应用比较适宜

其实，代码越少越容易维护，这个对于大型应用更要紧

2 楼 liuqiang 2008-08-25  

还是Readonly快人快语，我之前也是听到许多对于rails做大型应用的诟病，通过我的理解，觉得不然，忍不住说说自己的看法。

大型应用的核心确实在于架构，我仍然觉得利用rails/rest构建大型应用比较适宜

1 楼 Readonly 2008-08-25  

是否适合做大型应用和框架，语言都无关

http://www.iteye.com/news/3315

DHH 写道

Sure. Any application, whether it scales or not, usually does not have a whole lot to do with the framework or the programming language or any of the other individual tech pieces in isolation. It usually weighs more on algorithms, architecture or how its all being put together. When people talk about Twitter not scaling, which by the way is false -- Twitters is obviously scaling, it's growing every single day. I use it every single day, lots of people use it every single day. It has problems, sure, but it's not that it's not scaling. Not scaling kind of implies that the site went off the air. Twitters has never more powerful than it is today, never been growing more faster than it is today. Its working regardless to the problems they're having.

As whether their problems pertain to Rails web frame or anything, it's always just an irrelevant question. To me it serves as a filter. If people make that connection in their mind ofTwitter having scaling issues thus Rails can't scale, to me, it tells more about that person than it tells me anything else. It just tells me they don't have a very, I wouldn't even say deep understanding, but would say they don't even have a shallow understanding of technology.

Its a basic misconception. that's not interesting to me. In any ways, I don't care. If that is the position that you have on the opinion you use that you wouldn't want to use Rails because Twitter's having some issues, well so what! I won't loose sleep or money or anything else over that. Everybody shouldn't use Rails. So if there's some percentage of people who take that as their reason not to use Rails, all the better.