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

liuqiang

浏览: 161213 次
性别:
来自: 华东

最近访客更多访客>>

czbkjava

renzhe1981

lansim

yuan

博主相关

博客

微博

相册

留言

关于我

文章分类

社区版块

存档分类

博客分类：

Ruby

Rails 企业应用网络应用应用服务器 Ruby

之前读了不少文章，说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遵循既定规程的妙招。

分享到：

Linux与BSD之间的10个不同之处 | 新手到底新在什么地方

2008-08-25 13:24
浏览 3478
评论(254)
论坛回复 / 浏览 (251 / 104731)
查看更多

134 楼 ray_linn 2008-08-26

PS:

支持起企业应用的，是“能开发企业应用”的人，而不是靠某种啥有的没的。
SQL, Cobol, C, java, C# 都曾经在大型企业应用中出现过。

133 楼 gigix 2008-08-26

ray_linn 写道

从某种意义上，部署Ruby可能需要考虑的冗错的问题抵消了Ruby的效率。这就是好的VM和差的VM之区别。

什么意思？

132 楼 ray_linn 2008-08-26

<div class='quote_title'>robbin 写道</div>
<div class='quote_div'>
<div class='quote_title'>liuqiang 写道</div>
<div class='quote_div'>
<div class='quote_title'>ray_linn 写道</div>
<div class='quote_div'>一个烂的VM是支撑不起一个企业应用的。</div>
<p> </p>
<p> 我很大一部分就是针对你这种观点而写的，把应用分开，合理的分，rails鼓励你去分，<span style='color: #ff0000;'>一个好的VM也难支撑起一个企业应用的</span>。</p>
<p> </p>
<p>另外，貌似几年前很多做c++的就嘲笑JVM的性能</p>
</div>
<p> </p>
<p>这句话说的很棒！的确一个好的VM也无法支持一个大型企业应用。在我接触过的大型企业应用，往往都要水平＋垂直群集部署，没见过一个JVM打天下的。</p>
<p> </p>
<p>而且随着现在PC服务器的CPU数量猛增，以及内存容量的不断增加，单机部署多个JVM已经是一个非常迫切的话题了。一个JVM的堆内存不宜超过2GB，否则FullGC会非常恐怖，事实上堆内存以少于1G为宜，那么现在PC服务器动不动8G，16G，32G内存，你怎么办？只能多个JVM组成群集一起跑，充分利用CPU的多核，以及超大的物理内存。</p>
</div>
<p> </p>
<p> </p>
<p>恰恰相反，在企业中单JVM 的应用也是很多的，而多JVM的应用恰恰反而比较少数。</p>
<p> </p>
<p>从某种意义上，部署Ruby可能需要考虑的冗错的问题抵消了Ruby的效率。这就是好的VM和差的VM之区别。</p>

131 楼 sg552 2008-08-26

建议 ltian 保持一颗开放的心态，乐观的接受新事物。

看到大家上面那么多帖子，让我也收获很大。

学习Ruby on Rails, 看来是我近期的重点工作了！

130 楼 robbin 2008-08-26

刑天战士写道

robbin 写道

ray_linn 写道

一个烂的VM是支撑不起一个企业应用的。

的确，一个烂的VM支撑不了一个企业应用，但是一堆烂的VM就可以支撑一个企业应用了。所以我一直反复强调，Rails部署要多进程，要多进程，哈哈。

事实上Rails的多进程部署方式巧妙的规避了RubyVM的绝大多数问题，而代价就是要多吃猛吃内存，好在内存条便宜，只管加就是。

我们用apache+mongrel，配合一个叫god的监控gem（老板喜欢尝鲜，不愿意用大家都用的monit）。准备换成passenger的形式，不知道会不会更好……

rails绝对是吃内存的大户……而且对IO要求很高……

monit我研究过，用起来太麻烦，我自己写一个shell脚本就搞定了，总共40行代码而已。

Passenger只能稍微节省一点点内存而已，效果并不大。因为Ruby进程吃内存的地方主要在于堆地址分配，不在于共享库的加载。Passenger只能节省共享库加载的地址空间，但并不能让多进程共享堆地址空间(如果真能共享堆地址，其实麻烦更大)。

Rails的硬盘IO要求是很低的。

下图是一个Ruby进程的物理内存映射表，堆内存占据的空间是我抽取出来的三行：

00000000005d4000 125260K rwx--    [ anon ]
0000002a95c23000  23456K rw---    [ anon ]
0000002a99186000  50980K rw---    [ anon ]

0000000000400000    760K r-x--  /usr/local/ruby/bin/ruby
00000000005bd000     92K rw---  /usr/local/ruby/bin/ruby
00000000005d4000 125260K rwx--    [ anon ]
0000002a95556000     84K r-x--  /lib64/ld-2.3.3.so
0000002a9556b000     12K rw---    [ anon ]
0000002a9556e000     24K r--s-  /usr/lib64/gconv/gconv-modules.cache
0000002a95574000      4K rw---    [ anon ]
0000002a95577000     12K rw---    [ anon ]
0000002a9557a000    204K r----  /usr/lib/locale/en_US.utf8/LC_CTYPE
0000002a9566a000     12K rw---  /lib64/ld-2.3.3.so
0000002a9566d000      8K r-x--  /lib64/libdl.so.2
0000002a9566f000   1024K -----  /lib64/libdl.so.2
0000002a9576f000      4K rw---  /lib64/libdl.so.2
0000002a95770000     36K r-x--  /lib64/libcrypt.so.1
0000002a95779000   1020K -----  /lib64/libcrypt.so.1
0000002a95878000      8K rw---  /lib64/libcrypt.so.1
0000002a9587a000    184K rw---    [ anon ]
0000002a958a8000    336K r-x--  /lib64/tls/libm.so.6
0000002a958fc000   1024K -----  /lib64/tls/libm.so.6
0000002a959fc000     16K rw---  /lib64/tls/libm.so.6
0000002a95a00000   1068K r-x--  /lib64/tls/libc.so.6
0000002a95b0b000   1020K -----  /lib64/tls/libc.so.6
0000002a95c0a000    100K rw---  /lib64/tls/libc.so.6
0000002a95c23000  23456K rw---    [ anon ]
0000002a9730c000     16K r-x--  /usr/local/ruby/lib/ruby/1.8/x86_64-linux/thread.so
0000002a97310000   1020K -----  /usr/local/ruby/lib/ruby/1.8/x86_64-linux/thread.so
0000002a9740f000      4K rw---  /usr/local/ruby/lib/ruby/1.8/x86_64-linux/thread.so
0000002a97410000     32K r-x--  /usr/local/ruby/lib/ruby/1.8/x86_64-linux/zlib.so
0000002a97418000   1020K -----  /usr/local/ruby/lib/ruby/1.8/x86_64-linux/zlib.so
0000002a97517000      8K rw---  /usr/local/ruby/lib/ruby/1.8/x86_64-linux/zlib.so
0000002a97519000     72K r-x--  /lib64/libz.so.1.2.1
0000002a9752b000   1024K -----  /lib64/libz.so.1.2.1
0000002a9762b000      4K rw---  /lib64/libz.so.1.2.1
0000002a9762c000     40K r-x--  /usr/local/ruby/lib/ruby/1.8/x86_64-linux/socket.so
0000002a97636000   1020K -----  /usr/local/ruby/lib/ruby/1.8/x86_64-linux/socket.so
0000002a97735000      8K rw---  /usr/local/ruby/lib/ruby/1.8/x86_64-linux/socket.so
0000002a97737000     20K r-x--  /usr/local/ruby/lib/ruby/1.8/x86_64-linux/stringio.so
0000002a9773c000   1020K -----  /usr/local/ruby/lib/ruby/1.8/x86_64-linux/stringio.so
0000002a9783b000      4K rw---  /usr/local/ruby/lib/ruby/1.8/x86_64-linux/stringio.so
0000002a9783c000      8K r-x--  /usr/local/ruby/lib/ruby/1.8/x86_64-linux/etc.so
0000002a9783e000   1024K -----  /usr/local/ruby/lib/ruby/1.8/x86_64-linux/etc.so
0000002a9793e000      4K rw---  /usr/local/ruby/lib/ruby/1.8/x86_64-linux/etc.so
0000002a9793f000    236K r-x--  /usr/local/ruby/lib/ruby/1.8/x86_64-linux/nkf.so
0000002a9797a000   1024K -----  /usr/local/ruby/lib/ruby/1.8/x86_64-linux/nkf.so
0000002a97a7a000     20K rw---  /usr/local/ruby/lib/ruby/1.8/x86_64-linux/nkf.so
0000002a97a7f000      4K rw---    [ anon ]
0000002a97a80000     40K r-x--  /usr/local/ruby/lib/ruby/1.8/x86_64-linux/bigdecimal.so
0000002a97a8a000   1020K -----  /usr/local/ruby/lib/ruby/1.8/x86_64-linux/bigdecimal.so
0000002a97b89000      8K rw---  /usr/local/ruby/lib/ruby/1.8/x86_64-linux/bigdecimal.so
0000002a97b8b000    108K r-x--  /usr/local/ruby/lib/ruby/1.8/x86_64-linux/syck.so
0000002a97ba6000   1024K -----  /usr/local/ruby/lib/ruby/1.8/x86_64-linux/syck.so
0000002a97ca6000     12K rw---  /usr/local/ruby/lib/ruby/1.8/x86_64-linux/syck.so
0000002a97ca9000     16K r-x--  /usr/local/ruby/lib/ruby/1.8/x86_64-linux/strscan.so
0000002a97cad000   1024K -----  /usr/local/ruby/lib/ruby/1.8/x86_64-linux/strscan.so
0000002a97dad000      4K rw---  /usr/local/ruby/lib/ruby/1.8/x86_64-linux/strscan.so
0000002a97dae000      4K r-x--  /usr/local/ruby/lib/ruby/1.8/x86_64-linux/fcntl.so
0000002a97daf000   1024K -----  /usr/local/ruby/lib/ruby/1.8/x86_64-linux/fcntl.so
0000002a97eaf000      4K rw---  /usr/local/ruby/lib/ruby/1.8/x86_64-linux/fcntl.so
0000002a97eb0000      4K r-x--  /usr/local/ruby/lib/ruby/1.8/x86_64-linux/digest/md5.so
0000002a97eb1000   1024K -----  /usr/local/ruby/lib/ruby/1.8/x86_64-linux/digest/md5.so
0000002a97fb1000      4K rw---  /usr/local/ruby/lib/ruby/1.8/x86_64-linux/digest/md5.so
0000002a97fb2000    988K r-x--  /usr/lib64/libcrypto.so.0.9.7
0000002a980a9000   1024K -----  /usr/lib64/libcrypto.so.0.9.7
0000002a981a9000    216K rw---  /usr/lib64/libcrypto.so.0.9.7
0000002a981df000     16K rw---    [ anon ]
0000002a981e3000     12K r-x--  /usr/local/ruby/lib/ruby/1.8/x86_64-linux/digest.so
0000002a981e6000   1020K -----  /usr/local/ruby/lib/ruby/1.8/x86_64-linux/digest.so
0000002a982e5000      4K rw---  /usr/local/ruby/lib/ruby/1.8/x86_64-linux/digest.so
0000002a982e6000    228K r-x--  /usr/local/ruby/lib/ruby/1.8/x86_64-linux/openssl.so
0000002a9831f000   1020K -----  /usr/local/ruby/lib/ruby/1.8/x86_64-linux/openssl.so
0000002a9841e000     32K rw---  /usr/local/ruby/lib/ruby/1.8/x86_64-linux/openssl.so
0000002a98426000    184K r-x--  /usr/lib64/libssl.so.0.9.7
0000002a98454000   1024K -----  /usr/lib64/libssl.so.0.9.7
0000002a98554000     28K rw---  /usr/lib64/libssl.so.0.9.7
0000002a9855b000      4K rw---    [ anon ]
0000002a9855c000     16K r-x--  /usr/local/ruby/lib/ruby/1.8/x86_64-linux/racc/cparse.so
0000002a98560000   1020K -----  /usr/local/ruby/lib/ruby/1.8/x86_64-linux/racc/cparse.so
0000002a9865f000      4K rw---  /usr/local/ruby/lib/ruby/1.8/x86_64-linux/racc/cparse.so
0000002a98660000     16K r-x--  /usr/local/ruby/lib/ruby/1.8/x86_64-linux/iconv.so
0000002a98664000   1020K -----  /usr/local/ruby/lib/ruby/1.8/x86_64-linux/iconv.so
0000002a98763000      4K rw---  /usr/local/ruby/lib/ruby/1.8/x86_64-linux/iconv.so
0000002a98764000    320K r-x--  /usr/local/ruby/lib/ruby/gems/1.8/gems/memcached-0.10/lib/rlibmemcached.so
0000002a987b4000   1024K -----  /usr/local/ruby/lib/ruby/gems/1.8/gems/memcached-0.10/lib/rlibmemcached.so
0000002a988b4000     16K rw---  /usr/local/ruby/lib/ruby/gems/1.8/gems/memcached-0.10/lib/rlibmemcached.so
0000002a988b8000     40K r-x--  /usr/local/lib/libmemcached.so.2.0.0
0000002a988c2000   1020K -----  /usr/local/lib/libmemcached.so.2.0.0
0000002a989c1000      8K rw---  /usr/local/lib/libmemcached.so.2.0.0
0000002a989c3000      4K r-x--  /usr/local/ruby/lib/ruby/1.8/x86_64-linux/digest/sha1.so
0000002a989c4000   1024K -----  /usr/local/ruby/lib/ruby/1.8/x86_64-linux/digest/sha1.so
0000002a98ac4000      4K rw---  /usr/local/ruby/lib/ruby/1.8/x86_64-linux/digest/sha1.so
0000002a98ac5000     60K r-x--  /usr/local/ruby/lib/ruby/gems/1.8/gems/hpricot-0.6/lib/i686-linux/hpricot_scan.so
0000002a98ad4000   1020K -----  /usr/local/ruby/lib/ruby/gems/1.8/gems/hpricot-0.6/lib/i686-linux/hpricot_scan.so
0000002a98bd3000      4K rw---  /usr/local/ruby/lib/ruby/gems/1.8/gems/hpricot-0.6/lib/i686-linux/hpricot_scan.so
0000002a98bd4000    588K r-x--  /usr/local/ruby/lib/ruby/gems/1.8/gems/ferret-0.11.6/lib/ferret_ext.so
0000002a98c67000   1024K -----  /usr/local/ruby/lib/ruby/gems/1.8/gems/ferret-0.11.6/lib/ferret_ext.so
0000002a98d67000    184K rw---  /usr/local/ruby/lib/ruby/gems/1.8/gems/ferret-0.11.6/lib/ferret_ext.so
0000002a98d95000      8K rw---    [ anon ]
0000002a98d97000     24K r-x--  /usr/local/ruby/lib/ruby/gems/1.8/gems/rmmseg-cpp-0.2.5/ext/rmmseg/rmmseg.so
0000002a98d9d000   1024K -----  /usr/local/ruby/lib/ruby/gems/1.8/gems/rmmseg-cpp-0.2.5/ext/rmmseg/rmmseg.so
0000002a98e9d000      4K rw---  /usr/local/ruby/lib/ruby/gems/1.8/gems/rmmseg-cpp-0.2.5/ext/rmmseg/rmmseg.so
0000002a98e9e000    696K r-x--  /usr/lib64/libstdc++.so.5.0.6
0000002a98f4c000   1024K -----  /usr/lib64/libstdc++.so.5.0.6
0000002a9904c000    116K rw---  /usr/lib64/libstdc++.so.5.0.6
0000002a99069000     72K rw---    [ anon ]
0000002a9907b000     40K r-x--  /lib64/libgcc_s.so.1
0000002a99085000   1020K -----  /lib64/libgcc_s.so.1
0000002a99184000      8K rw---  /lib64/libgcc_s.so.1
0000002a99186000  50980K rw---    [ anon ]
0000002a9c34f000     16K r-x--  /usr/local/ruby/lib/ruby/site_ruby/1.8/x86_64-linux/fcgi.so
0000002a9c353000   1020K -----  /usr/local/ruby/lib/ruby/site_ruby/1.8/x86_64-linux/fcgi.so
0000002a9c452000      4K rw---  /usr/local/ruby/lib/ruby/site_ruby/1.8/x86_64-linux/fcgi.so
0000002a9c453000     36K r-x--  /usr/local/fcgi/lib/libfcgi.so.0.0.0
0000002a9c45c000   1024K -----  /usr/local/fcgi/lib/libfcgi.so.0.0.0
0000002a9c55c000      8K rw---  /usr/local/fcgi/lib/libfcgi.so.0.0.0
0000002a9c55e000     68K r-x--  /lib64/libnsl.so.1
0000002a9c56f000   1024K -----  /lib64/libnsl.so.1
0000002a9c66f000     12K rw---  /lib64/libnsl.so.1
0000002a9c672000      8K rw---    [ anon ]
0000002a9c674000     76K r-x--  /usr/local/ruby/lib/ruby/site_ruby/1.8/x86_64-linux/mysql.so
0000002a9c687000   1020K -----  /usr/local/ruby/lib/ruby/site_ruby/1.8/x86_64-linux/mysql.so
0000002a9c786000      8K rw---  /usr/local/ruby/lib/ruby/site_ruby/1.8/x86_64-linux/mysql.so
0000002a9c788000    264K r-x--  /opt/mysql5/lib/mysql/libmysqlclient.so.15.0.0
0000002a9c7ca000   1024K -----  /opt/mysql5/lib/mysql/libmysqlclient.so.15.0.0
0000002a9c8ca000    340K rw---  /opt/mysql5/lib/mysql/libmysqlclient.so.15.0.0
0000002a9c91f000      4K rw---    [ anon ]
0000002a9c920000     36K r-x--  /lib64/libnss_files.so.2
0000002a9c929000   1020K -----  /lib64/libnss_files.so.2
0000002a9ca28000      8K rw---  /lib64/libnss_files.so.2
0000002a9ca2a000   6808K rw---    [ anon ]
0000002a9d0d0000     12K r-x--  /usr/lib64/gconv/EUC-CN.so
0000002a9d0d3000   1024K -----  /usr/lib64/gconv/EUC-CN.so
0000002a9d1d3000      4K rw---  /usr/lib64/gconv/EUC-CN.so
0000002a9d1d4000     64K r-x--  /usr/lib64/gconv/libGB.so
0000002a9d1e4000   1020K -----  /usr/lib64/gconv/libGB.so
0000002a9d2e3000      4K rw---  /usr/lib64/gconv/libGB.so
0000007fbeddd000  18572K rw---    [ stack ]
ffffffffff600000   8192K -----    [ anon ]
 total           280676K

129 楼 gigix 2008-08-26

liusong1111 写道

gigix 写道

其实Rails能不能做所谓的大型企业应用，这都是细枝末节的事情
大型企业应用这种东西本身会消失
看不到这个趋势，才是真可悲的

这个论断看起来大胆，却是不论大公司还是小公司，想做大还是做专，有意还是无意，过去还是现在，都在奔的方向。比起过去，现在的思路和解决方案更清晰，可行性更高了。

这个话题的展开，会很有意思，期待一下。

谈不上。只是不同的历史阶段做不同的事。
企业为什么需要信息化？他们为什么曾经需要COBOL的系统？那时候他们有什么？为什么曾经需要C++的系统？那时候他们有什么？为什么曾经（并且正在）需要JavaEE的系统？现在他们有什么？他们需要什么？
现在的全球经济环境和80年代90年代有什么重要的区别？
其实都是很自然的答案。

128 楼 liuqiang 2008-08-26

<div class='quote_title'>liusong1111 写道</div>
<div class='quote_div'>
<div class='quote_title'>gigix 写道</div>
<div class='quote_div'><br/>其实Rails能不能做所谓的大型企业应用，这都是细枝末节的事情 <br/><strong>大型企业应用这种东西本身会消失</strong> <br/>看不到这个趋势，才是真可悲的 <br/></div>
<br/>这个论断看起来大胆，却是不论大公司还是小公司，想做大还是做专，有意还是无意，过去还是现在，都在奔的方向。比起过去，现在的思路和解决方案更清晰，可行性更高了。 <br/><br/>这个话题的展开，会很有意思，期待一下。 <br/><br/></div>
<p> </p>
<p> 尽管我很讨厌上校内网，但据说他们要用rails开发新频道，我特意跑去看了一下，发现他们的各个频道都是独立的，单独把他的日志或者相册拿出来，就是一个独立的系统，这些系统可能是基于java、php、ruby的，事实上，这些系统并不大，但这些系统组在一起，就是一个足以支撑千万级用户的SNS社区。</p>
<p> </p>
<p> </p>

127 楼刑天战士 2008-08-26

robbin 写道

ray_linn 写道

一个烂的VM是支撑不起一个企业应用的。

126 楼 rubynroll 2008-08-26

嗯，说到VM，目前MRI的实现确实存在不少问题。最近用RubyGnome做东西，很多地方需要手工调用GC#start，否则内存很快飙升到G。可能做web感觉不是那么明显（大部分是小对象），做桌面应用，图像处理之类，感觉就很明显。

不过说到企业应用，有了JRuby，VM的问题可不可以说和Java齐平了呢？

125 楼 liusong1111 2008-08-26

gigix 写道

其实Rails能不能做所谓的大型企业应用，这都是细枝末节的事情
大型企业应用这种东西本身会消失
看不到这个趋势，才是真可悲的

124 楼 robbin 2008-08-26

liusong1111 写道

刑天战士写道

引用

说说ROR开发的弱点:
Ruby目前漏洞太多,还未成熟
滥用plugins,gems造成的安全性问题
应用服务器的稳定性问题

其他都可以归结为设计问题,能力问题,信仰问题

please enlight me.

顺便说一下，别吵了，帮我看看这个简单的问题吧：http://www.iteye.com/topic/231961

使用rails，需要我们手工去声明事务。
ActiveRecord会自动合并事务，即PROPAGATION_REQUIRED。
并对create、update、destroy启用"隐式事务"

http://hideto.iteye.com/blog/194865

其实我特羡慕Spring提供的7种事务模型，曾经非常鄙夷Rails只有PROPAGATION_REQUIRED这1种事务模型。但是我一直没有机会去证明一把，Spring提供的6种其他的事务模型究竟有没有实用价值，因为我以前用Spring的时候，也只用过PROPAGATION_REQUIRED这一种而已，哈哈。

123 楼 robbin 2008-08-26

<div class='quote_title'>liuqiang 写道</div>
<div class='quote_div'>
<div class='quote_title'>ray_linn 写道</div>
<div class='quote_div'>一个烂的VM是支撑不起一个企业应用的。</div>
<p> </p>
<p> 我很大一部分就是针对你这种观点而写的，把应用分开，合理的分，rails鼓励你去分，<span style='color: #ff0000;'>一个好的VM也难支撑起一个企业应用的</span>。</p>
<p> </p>
<p>另外，貌似几年前很多做c++的就嘲笑JVM的性能</p>
</div>
<p> </p>
<p>这句话说的很棒！的确一个好的VM也无法支持一个大型企业应用。在我接触过的大型企业应用，往往都要水平＋垂直群集部署，没见过一个JVM打天下的。</p>
<p> </p>
<p>而且随着现在PC服务器的CPU数量猛增，以及内存容量的不断增加，单机部署多个JVM已经是一个非常迫切的话题了。一个JVM的堆内存不宜超过2GB，否则FullGC会非常恐怖，事实上堆内存以少于1G为宜，那么现在PC服务器动不动8G，16G，32G内存，你怎么办？只能多个JVM组成群集一起跑，充分利用CPU的多核，以及超大的物理内存。</p>

122 楼 gigix 2008-08-26

liuqiang 写道

ray_linn 写道

一个烂的VM是支撑不起一个企业应用的。

我很大一部分就是针对你这种观点而写的，把应用分开，合理的分，rails鼓励你去分，一个好的VM也难支撑起一个企业应用的。

另外，貌似几年前很多做c++的就嘲笑JVM的性能

这个故事其实要说起来就长，但背后的其实才是真正有意思的故事
我们回头看历史，Java的性能仍然比C/C++差很多，Java仍然不能像Delphi那样做漂亮的桌面应用
那为什么Java现在是最大的主流，Delphi死了？
其实Rails能不能做所谓的大型企业应用，这都是细枝末节的事情
大型企业应用这种东西本身会消失
看不到这个趋势，才是真可悲的
（反对意见者不用说了，我知道我知道，我这些都是胡说八道。COBOL都还统治着呢，大型企业应用怎么会死呢，对吧？你们是对的，我是错的，我自己认错，省得大家费口水。）

121 楼 liusong1111 2008-08-26

刑天战士写道

引用

please enlight me.

顺便说一下，别吵了，帮我看看这个简单的问题吧：http://www.iteye.com/topic/231961

120 楼 liuqiang 2008-08-26

<div class='quote_title'>ltian 写道</div>
<div class='quote_div'>
<div class='quote_title'>toostupid 写道</div>
<div class='quote_div'>
<div class='quote_title'>ray_linn 写道</div>
<div class='quote_div'>一个烂的VM是支撑不起一个企业应用的。</div>
<br/><br/>这句话比较中听。比那个Itian有水平多了。 <br/><br/>不过企业应用也要看是多大的企业。 <br/>ERP我觉得没问题，因为同时操作的人是比较少的。</div>
<br/><br/>烂的VM是你们说的，<span style='color: #ff0000;'>我不知道Rails是这样，我能胡说吗？</span> 我强调大型企业开发和语言是否精炼无关。你们看不懂汉字还是心虚啊？ <br/></div>
<p> </p>
<p>我也不知道你为啥要胡说</p>

119 楼 liuqiang 2008-08-26

<div class='quote_title'>ray_linn 写道</div>
<div class='quote_div'>一个烂的VM是支撑不起一个企业应用的。</div>
<p> </p>
<p> 我很大一部分就是针对你这种观点而写的，把应用分开，合理的分，rails鼓励你去分，一个好的VM也难支撑起一个企业应用的。</p>
<p> </p>
<p>另外，貌似几年前很多做c++的就嘲笑JVM的性能</p>

118 楼 robbin 2008-08-26

toostupid 写道

gigix 写道

Groovy的好处是它编译成byte code

byte code还能不能interpreted ?

这个问题会不会太弱智？我不关注业界新闻好多年了。

interpreted是rails一大优势，对开发者而言...省去了重启tomcat的步骤

解释执行并不是Rails的优势，事实上现在Rails在生产环境当中重新部署也需要重起应用服务器的，这和Tomcat没有区别。有区别的地方在于Rails是多进程跑，因此重起的过程，你可以一个接一个重起ruby进程，整个重起过程不会打断用户访问，不像Tomcat，单进程多线程，要重起就要整个重起，会打断用户访问。

Ruby1.9也会改成编译为字节码执行，事实上虚拟机字节码是一个优点。

117 楼 robbin 2008-08-26

ray_linn 写道

一个烂的VM是支撑不起一个企业应用的。

116 楼 liusong1111 2008-08-26

toostupid 写道

byte code还能不能interpreted ?

这个问题会不会太弱智？我不关注业界新闻好多年了。

interpreted是rails一大优势，对开发者而言...省去了重启tomcat的步骤

ROR/ruby的Class Reload并不因为interpreted就如想象中的那么自然，我现在更倾向于认为：ruby天然不能完美支持这一特性。
然而我们用得很爽，证明这是个不大的问题。

115 楼 dean_liu 2008-08-26

说了这么多,不知道有没有人用过?

« 上一页 1 2 … 6 7 8 … 12 13 下一页 »

发表评论

您还没有登录,请您登录后再发表评论

最近访客更多访客>>

博主相关

文章分类

社区版块

存档分类

最新评论