我怎么就觉得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理解不深，这里有一段访谈倒是蛮有说服力,

写道