有感而发：JavaEE和ROR的本质区别，以及对ROR的抱怨

粗算下来，作java开发也有6、7年了，期间也短暂搞过其他技术（vb、.net、office），但还总体上是以java为主不断坚持着。。。

直到07年被《程序员》杂志和javaeye“忽悠”，到ROR的世界游历了一番（做了1.5个项目），今天刚好碰到这篇博客http://morris.iteye.com/blog/198982，
有感而发，说点自己的看法：

从架构思想上看：

JavaEE的（起码早期的）思想一直是 用大型架构 建设 错综复杂的商业系统（注意这些系统中web只是所用的众多技术中的一部分），导致他十分强调分层，开发部署比较繁重。
这个思想根深蒂固，几乎影响了所有java框架的设计。甚至所谓的轻量级框架也是如此。
（似乎成了企业级技术的特点，看看现在火热的SOA，其复杂和繁重程度甚至比JavaEE更严重）。

ROR显然没这么大的野心，它要解决的只是如何快速搭建好一个网站（因此会更注重如何多多利用web标准：html、css、javascript），他在架构上的考虑就只是MVC，能保持一个好的程序结构即可，根本无须分层。
（与JavaEE这么多年一直拥抱SOA对比，ROR到了2.0更是抛弃了webservice，转到更加简洁的REST了）

但是sun没想到实际中大多数人开发的东西没那么复杂，反倒更强调快速开发、快速适应变化，因此ROR在java社区里面引起很大反思。
（在中国这个情况更加普遍，系统不复杂、倒是需求变化快。。。）
（在网站制作领域一直都是喜欢用脚本语言，可以做到快速编码、快速部署、快速变化。PHP就是一个例子，只不过PHP结构实在太差，java们一直看不上眼，而ROR实现的MVC却相当正统、严密，框架结构甚至比流行的java框架如ssh作的更完美，这自然引起了java们的广泛兴趣）

看起来，ROR就像一枚银弹，尤其是对咱们这些中国的开发人员
然而实际作起来，你会发现：
1）从语言环境到应用框架都不熟悉，需要不短的一段时间学习和准备
（对于那些看了几天 文档／视频／教程 就敢轮胳膊开干，还说入门简单学习曲线低的，我真要骂人了：不是人您就别在人堆里面瞎炫耀了）
2）动态语言真的很动态，没有编译过程，你可能会犯下一些低级错误，而具体到Rails框架中，因为使用了各种动态的代码生成技术，导致要想搞清楚其中一些bug，可能需要你花费几个小时进行跟踪查找。
3）Rails中的View是基于html的模板技术，这跟jsp类似，你需要自己控制自己，因为没人会阻止你在里面写业务代码。
4）ruby之前应用的还比较少，一些常见解决方案还非常不完善（比如：全文检索，目前最好的ferret，还是有bug经常导致rails意外退出）。
5）Rails的各种插件比较多，但是质量不齐，有些看起来很cool，但是无法深入定制（比如：ROR书里面提到的streamlined，就有点像玩具），具体的调研和选择代价比较大。
6）有时碰到Rails插件的bug或功能缺陷，如果你自己直接改的话，之后的插件升级版本管理上似乎会有点麻烦，需要你手工合并。
7）可能你要自己解决部署后的源代码保护问题，而这个问题对于产品开发无疑是最重要的。
8）动态语言的全面掌握需要比静态语言花费更多时间精力。

呵呵，泼了这么多凉水，其实是想说明一点：要认真地对待ROR技术，不要被一些宣传所蒙蔽。
基本上，在没有熟练掌握ROR、而又需要深入开发的时候，ROR带来的好处（代码量少、开发修改部署快），和他带来的各种问题几乎可以互相抵消，千万别以为能省多少时间。
但是从长远看，代码量少还是非常吸引人的，想象一下，同样的业务逻辑代码，10万行和100万行那个更容易维护？

偶然和一个作过ROR的开发人员有过一次交流，发现大家目前的想法有点相似，ROR更适合少量的高手合作开发，或者私人接活。
普通的团队开发似乎还需要大量探索。

评论

18 楼 java心如止水 2008-06-04  

樓主的話有道理!!

17 楼 liusong1111 2008-06-04  

第一线的感想就是实在，这些抱怨看起来很亲切。不过，通过对比，我觉得它还是有优势。
1，8）ruby还缺一本书，只讲它的最基本语法。个人感觉在学习曲线上，它有点javascript的特点，掌握起来容易精通难。学习曲线有个从平到陡的过程。
如果一个team中没有一两个熟悉的人，肯定会走弯路，这跟学习曲线还是两码事。
是需要一段时间学习才能上手。但如果对比java（它已经沦落到上场就为了被PK的地步），比如action_pack vs struts, layout vs sitemesh, active_record vs hibernate
都会给一致的结论吧。
2）是的。不过，再对比java，比如spring的事务，用cglib加强后，同样不好调试（我感觉ruby比它好多了）
3）是的。rails的表现层我不满意，haml之类的要不太丑，要不性能太低。一个好的表现层模板，对于java来说都很找到，taglib被人批，velocity/freemarker还要学另一门语法。
   ERB不须学习另一门语言，而ruby语法的简炼，也让它比jsp更有优势。
4）是的。
5，6）强烈认同。
7）是的。所以现在多数在互联网应用。jruby之流发展挺快，不清楚可用度有多高。

>> 普通的团队开发似乎还需要大量探索
我的结论却是，普通团队只要有合适的管理和技术负责人，产品成功的可能性要大的多。

只针对pig345的文章说说看法，没时间接后面的讨论了。

16 楼 wutao8818 2008-06-04  

引用

西西，说到搜索，javaeye就是典型，几乎搜索功能为0。

关于全文搜索对ror来说应该不是问题，搜索本来可以得到单独的部署。例如部署solr这样的装备挺好。

15 楼 庄表伟 2008-06-03  

引用

但是，“缺乏技术含量”的纯JSP和servlet很快，快到惊艳的程度。说点伤心话，本论坛上的大伙也许都快忘了怎么写JSP吧。几个JVM过去，JSP的速度可以用飞来形容。很多人的记忆可能还停留在为垃圾回收而烦恼的历史JSP阶段吧，殊不知士别三日，真要刮目相看了。

提起当年，我还用纯JSP，做过一个简单的工作流引擎呢。

一直没好意思说  

14 楼 fujohnwang 2008-06-03  

引用

不是人您就别在人堆里面瞎炫耀了

哈哈，这句话比较有意思

13 楼 lgx522 2008-06-03  

引用

Ruby比Java确实性能差很多，但是RoR和Struts + Spring + Hibernate做的网站性能是在同一级别的。

这还真说到点子上了。前些天仔细测了一下SSH，也就比RoR快个4－5倍罢了。而寄予厚望的Grails，居然只比RoR快3倍左右。至于Seam，不说了，也许是本人还未掌握部署方法吧......。以这些状况而言，运用开发效率高的RoR并不冤枉。

但是，“缺乏技术含量”的纯JSP和servlet很快，快到惊艳的程度。说点伤心话，本论坛上的大伙也许都快忘了怎么写JSP吧。几个JVM过去，JSP的速度可以用飞来形容。很多人的记忆可能还停留在为垃圾回收而烦恼的历史JSP阶段吧，殊不知士别三日，真要刮目相看了。
说句不中听的，曾经我们这群自以为了不起的Java fans，早已是framework中毒太深，离了framework就好像天要塌下来。可惜，framework的确是性能杀手。不但是Java，PHP一上那些个framework，也好不到哪里去。

JE做得很好很贴心。可全中国都在用Discuz，要求低，速度快啊。

这些天注意力放在性能上，缘于接触到许多上线的实际工程中出现了不少的中间层性能问题，有感而发。不是有意跟JE唱反调，而是想提醒大家，用framework是有很大代价的。我们这个时代的程序员，并不是只需看如何好写好改，而不必考虑性能问题了。
开发项目之前，一定要把性能和系统容量问题考虑清楚，再选择适合项目的技术体系，否则图一时之快，早晚还是要还的。

12 楼 QuakeWang 2008-06-03  

引用

DB再瓶颈，执行大多数SQL也低于几毫秒（还不提天生就带缓存的Oracle这类高级DB）。也就是说，DB大体上一秒钟可以处理500－ 1000个SQL命令。大家再测一下自己的中间层rps，看看达不达得到这样的水准。即使做proxy_balance，apache、lighttpd 又撑得住多少？

但是一个request不是只执行一个数据库操作，一个request含有10~20个sql是很常见的，这样框架本身的RPS就不会是瓶颈了。
其实JavaEye本身没有在RoR性能优化做特别大的力气，只有一台web+一台数据库服务器，可以轻松应付目前每天80~90W的动态请求，乐观估计目前的服务器资源能够应付200W每天的动态请求（不过在到达200W前，目前托管机房的网络带宽会是一个瓶颈）
就算以后web服务器撑不下去了，加一台服务器才1~2万，成本还不够2个开发人员一个月的人力成本，而RoR和Java/PHP在做这样一个网站上的开发以及维护时间相差就远不止2个人月。
Ruby比Java确实性能差很多，但是RoR和Struts + Spring + Hibernate做的网站性能是在同一级别的。

11 楼 robbin 2008-06-03  

你这样说就没劲了，还是拿数据来说事吧。Friends for sale每天超过1000万页面访问量，6台PC应用服务器跑Rails支撑起来1000万的流量，前端用nginx跑的欢着呢，目前瓶颈在数据库上面。

10 楼 lgx522 2008-06-03  

JE对RoR性能问题乐观的立足点在于“数据库瓶颈”。
乍一看是有道理，仔细一琢磨还是不对。
毕竟，持久层的问题还是要由持久层来解决，不论是拆库拆表，还是干脆用文件，或者是其它手段。总之是“解铃还须系铃人”。

不论是Java、RoR、PHP还是.NET，始终是在做中间层的事情。中间层就要把中间层的事情解决好，不能借口说是因为持久层不行，所以中间层也可以不行。
说得不客气一点，事实上当前大多数系统的“瓶颈”还往往是出在中间层，大家不服气可以实事求是考察一下当今所谓的“三层”系统。
DB再瓶颈，执行大多数SQL也低于几毫秒（还不提天生就带缓存的Oracle这类高级DB）。也就是说，DB大体上一秒钟可以处理500－1000个SQL命令。大家再测一下自己的中间层rps，看看达不达得到这样的水准。即使做proxy_balance，apache、lighttpd又撑得住多少？
可喜的是，如果不用framework，JSP、PHP、ASP和.NET都是快过DB的，所以这时候DB是瓶颈；用上framework，比DB慢得多，这时候中间层反倒成了瓶颈。
加机器，加几台才够？加到软件proxy_balance都受不了，还是得拿硬件做均衡。

9 楼 fly_hyp 2008-06-03  

做一种语言的设计是不容易的。很多新的技术都有这样的问题。用熟悉的技术解决问题才是硬道理。

8 楼 QuakeWang 2008-06-03  

上次把rails升级到2.0.2以及相关的插件升级，差不多花费了3天的时间，主要时间花费在了集成测试(controller/view)上， 没有用自动化的界面测试工具录制测试脚本，所以比较耗时。model/helper/lib因为有单元测试代码做保证，发现错误就很容易

我觉得是否有静态编译支持，对于Rails的代码风格来说帮助不大。举个例子，rails/plugin习惯用hash传递参数，一升级，结果它接受的hash key名字改变了，或者多了一个key
换成类似写法，在静态编译支持语言（如Java）里面用map，也无法帮你找出这种错误，还是得靠单元测试代码来保证。

性能的问题不在于Rails，而在于Ruby语言，只要不是基于Ruby做大规模运算，用Rails做常见的应用，需要优化的瓶颈都会在数据库操作上。

7 楼 robbin 2008-06-03  

Rails框架每次大的版本升级基本上都不向下兼容，的确会给项目升级框架带来一些麻烦，但从我个人的角度来说，我欣赏这种不提供向下兼容的勇气。因为只有这样做才能保证Rails框架没有历史包袱，永远锐意创新，不必受老版本的限制。

反过来说，如果一个项目稳定运行的话，你可以把Rails框架打包到项目的verdors目录下面，绑定Rails版本，不必升级。

Ruby的性能是很差，只不过做web应用也够用了。

6 楼 pig345 2008-06-03  

to lgx522
越严重的性能问题，我相信改进的余地也越大。
不过真的这么差么？具体还真没对比测试过，不过javaeye似乎一直在强调ROR性能不错，呵呵。

5 楼 pig345 2008-06-03  

to Quake Wang
动态语言毕竟有许多不同，对于实际生活中碰到的大多数开发人员来讲（甚至连语法简单、静态类型的java，尚不能完全掌握），要达到基本熟练（而不至于每天在一些低级错误上绕）是有一个门槛的。这就导致了作ROR的开发人员不大可能太多。
ROR的框架的升级，其实有许多api接口有变化。我曾经在javaeye的升级问题贴里提到过，可惜被蛮横的评为差贴。

引用

javaeye作了这件事（升级Rails）以后，应该能体会到这种动态脚本语言的弊端了：框架的升级，肯定存在少量的接口参数的改变（有可能只是对参数的类型限制更加严格了），而这些改变导致的bug是不能由机器来检测的（没有编译过程），只能凭借人肉测试，这个比较怕人的，如果是个封闭软件，测试不够的话可就很麻烦了。

4 楼 QuakeWang 2008-06-03  

西西，说到搜索，javaeye就是典型，几乎搜索功能为0。
你可能经常逛论坛，不太留意其他频道，每个频道我们都提供了搜索功能
全站的搜索功能在上方导航条最右边：
http://www.iteye.com/search

3 楼 lgx522 2008-06-03  

楼主和我的经历非常相似，今后可以多多交流。

RoR除去上面所说的问题之外，其实最大的缺点是性能太差。
不要以为可以靠多进程和多台机器解决问题。能用一两台机器解决的问题，千万不要指望拿几十台去解决。毕竟绝大多数应用不是要搞Google所谓的“云计算”，何况Python的性能是非常好的，比Java慢不了太多。

在实际测试中，同样一台机器，RoR性能几乎不到Java的十分之一，这就是个大问题。
开发起来再怎么爽，改起来再怎么贴心，也还是程序员舒服。系统最终还是要用的，用起来太慢，用户始终是不满意的。用户不满意，就没有市场。

以前的EJB，任凭Sun、IBM、BEA再怎么吹，开发慢、运行慢总是事实，最后大家还是不买帐；现在的RoR，程序员玩DSL虽是满意了，但解决不了性能问题，始终还是上不了台面。

2 楼 ray_linn 2008-06-03  

西西，说到搜索，javaeye就是典型，几乎搜索功能为0。

1 楼 QuakeWang 2008-06-03  

我和你的开发经历很类似，也是从Java转到RoR的，对你说的1,2,8 这3点，我觉得还好
3. Rails自带的erb 确实不太好，特别是语法像jsp，会令人想起恐怖的jsp hell，呵呵
5,6 插件的良莠不齐和升级确实是很大问题，前者需要花费时间在评估上，后者体现在rails升级和插件升级带来的问题，我从ralis 1.2.X升级到rails 2.0.X，花费时间最多的就是测试这些插件兼容性上了。

引用

偶然和一个作过ROR的开发人员有过一次交流，发现大家目前的想法有点相似，ROR更适合少量的高手合作开发，或者私人接活。
普通的团队开发似乎还需要大量探索。

做ROR的开发还是太少，等多起来了，团队开发的一些最佳实践经验自然也会出来，这点我倒是不担心。