谈谈Grails，以及Ruby on rails

Grails顾名思义groovy on rails，一个用groovy模仿Ruby on rails的project，昨天刚刚发布了0.1版本，0.2版本正在紧锣密鼓的开发中。今天花了点时间看了看grails的文档，基本上完全模仿ruby on rails的开发模式和架构。grails底层实际上使用的是Hibernate3.1/Spring IoC/Spring MVC/Sitemesh/Dynamic Tag/AJAX(prototype, rico, YAHOO.js)这样的架构，但是通过groovy对底层进行了封装，提供了简单的，高度近似rails的编程模型，同时使用annotation和CoC方式消除了XML配置文件的存在。

Groovy了解了一下，最近三个月开发变得非常活跃，似乎要在JavaOne上面有所动作。目前来说，grails还比较初级，还需要耐心等候项目的成熟和完善，不过我个人对grails的编程方式相当感兴趣，愿意去尝试grails。

另外一个感觉是，脚本语言的编程方式和编译语言非常不同，如果使用Grails，你会感觉到Eclipse无用武之地，似乎还不如UltraEdit更适合开发。因此，即使是你从spring/hibernate的Java编译语言开发方式转向到封装spring/hibernate的Grails，我仍然认为是一个巨大的开发方式的跨越，而Grails到RoR开发方式上则相当接近。

目前Grails相比RoR的弱点：

1、项目成熟度差得比较多，RoR已经1.1了，而Grails才0.1，从时间上来说，落后两年

2、groovy从语言级别上面来说，相比ruby还是有差距的，诚如potian所说。

3、我认为开源项目的成败往往取决于开发者本人的才华。RoR的作者DHH感觉上比grails的作者有才华。


不过RoR也有自己的弱点：

1、ruby目前在第三方开源库方面积累还很不够，相比Java开源库的信手拈来，还显得异常寒酸，需要几年的积累。这是Java目前相比RoR，甚至相比dotnet的一大优势(这也是Grails的优势)

2、我始终坚持认为没有VM，RoR是不可能进入企业应用的。potian说ruby2.0会引入VM，和JVM相比，理论上不存在性能差异。不过这里有两个疑问：
1) 一旦引入VM和对象生命周期管理，RoR还能不能保持目前的简洁易用，以及动态部署能力，值得观望；
2) RubyVM就算理论上可以不比JVM差，但是JVM我认为并不是开源项目容易成功做出来的，目前比较好的JVM，像Sun Hotspot，BEA JRockit都是商业JVM，而开源JVM性能都差强人意，RubyVM想达到JVM那么广泛的平台支持，没有强力商业支持，恐怕难以实现。

从将来来看，应用项目开发的主流编程语言应该是动态面向对象的脚本语言，比如说ruby，python，groovy什么的，这种趋势就像当年Java取代C++成为应用项目的主流一样，以后的若干年，Java也会面临同样的发展趋势。

当然，哪种动态脚本语言将来应用会更广泛，似乎现在看不出来，RoR现在风头最劲，但是ruby也是最缺乏VM支持的语言，groovy有JVM，python有zope。

总之，当大家把目光投向RoR的时候，也不妨关注一下Grails。

对了，看了Grails，我可以forget rife了。

oh no...jsp tag...why not freemarker? why? why? why?

简单看叻一下，的确是仿RoR，不过Java的代码看起来就是比RoR亲切啊~~~开玩笑地说，说不定哪天就又冒出来一个PHP on Rails，呵呵

如果说RoR不能进入企业应用，那么Grails相比RoR最大的优点就是它天生是可以进入企业应用的。我完全可以拿Grails来做开发，将grails war产生的war包直接放到app server里去。

不过，单纯地模仿RoR并不是正道。我感觉J2EE开发者喜欢RoR并不是因为RoR带来的开发快感，而是厌烦叻J2EE开发过程中本身的那一系列无聊的固定动作。从古老的EJB（怎么恶心我就不说叻吧，大家都知道），到现在的WebWork2/Spring/Hibernate/FreeMarker，建立一个新功能全都是要走一个固定的流程，建立domain object、写DAO并且完成最基本的CRUD操作、写Service、写Action、写页面。。。每次都大同小异。

所以，我认为，J2EE开发者需要的是对WebWork2/Spring/Hibernate/FreeMarker/Sitemesh/OSCache/AJAX/...等等这些优秀框架的再高一层的封装，哪怕只是提供一个scaffold，一些脚本（无所谓用什么脚本语言，哪怕是DOS batch都行），一个爽快的开发环境，足矣！

我狠难说服自己去使用RoR/Grails，但是我却一直非常想将它们的思想转化为适合我自己的开发工具。

也许，我能够做一个提供给开发者建立自己的X/Rails的框架的框架？

Rails的主要威力来自于Ruby语言，所以很奇怪会出来那么多XXXails，特别是静态类型语言的clone，我觉得真是缘木求鱼了

“企业级软件"恐怕是越来越少了，而除了极少数的系统之外，和Web程序相比，真正的企业级软件的用户都是封闭的、数量很少的，性能要求远远低于公共的Web系统，包括单个用户响应速度和支持并发用户访问数量两个方面都是如此。
虽然对于一个简单的部署,VM方式和进程式的系统有比较大的区别，但是在系统要求伸缩到一定程度的时候，很多问题都是共同的，例如：

1. 进程间session共享的问题

当需要集群的时候，J2EE应用程序也需要在多个进程间共享。rails可以用分布式内存共享如memcache，而J2EE一般采用session复制。而另外一种方式都可以用数据库和分布式文件系统实现


3。进程和线程的问题
目前很多操作系统对进程管理已经相当优化，譬如Linux已经支持数百个进程，而一个繁忙的VM内部通常也会有数百个线程，我很怀疑这之间的性能会有多大的差距。我们目前有一个项目是一个要求大用户并发量的网络服务器，已经从原先的线程模型改变为进程模型，采用IPC进行通讯。另外单个进程的崩溃不会造成整个系统崩溃也是一个很重要的原因。

4。 VM内部的多线程共享对象
我很怀疑这是一种反模式，无法达到伸缩性的要求，譬如用户验证（及权限缓存）在伸缩性要求比较高的情况下必定需要一个单独的服务器。在不同的框架下都可能有不同的表现

5. 数据库连接
虽然进程式需要在进程级别上开始和释放数据库连接，但典型的J2EE也需要在请求开始时获取连接，在请求结束时释放连接，在性能要求和多服务器参与的伸缩要求下，缓存池虽然减轻了一定的负担，但作用有多大我也持有怀疑。

进程式已经被证明适合伸缩性要求极高的情况，并积累了丰富的经验。例如web上部署最大和用户并发要求最高的系统基本上都采用这种方式。我不认为VM方式在这上面具有多大的优势

虽然我不是很具体地理解你讲的意思，但这正是JVM不适合Ruby的重要原因之一，但Ruby 2.0不可能达到hotspot这样的性能。


分布式VM的研究虽然没有得到多大的应用，但是在单机器上的VM发展已经历经大约40年的时间，从最早的Lisp到Smalltalk，Java只不过是得到了真正的流行而已。最早出现、最长时间的虚拟机恰恰都是函数型或者动态类型的语言。

从性能上来看，目前我了解的一些问题是RVM比较关心的：

1。机器模型，RVM还是采用堆栈型计算机，现在关于堆栈型和寄存器型有不少争论，并且通常认为寄存器型的性能更高，但是开发、维护更加复杂，目前RVM采用和Java一样，用stack machine，但是parrot采用的是寄存器型，另一个Rubyforge的项目正在parrot上实现Ruby

2。解释方法，Ruby1.0采用的是遍历语法树进行计算，有了虚拟机编译为字节码以后，RVM可能采用selective inlining 的direct threaded 和superoperator的方法解释并执行字节码，并通过优化的 Indirect Branch Prediction提高速度。


3。垃圾收集：早先Ruby1.0采用的是标准的mark-sweep算法，Java则采用分代式的垃圾收集，但是最近的研究在内存分配上的认识有很多变化，从而影响到垃圾收集的算法实现，Java采用的方式可能在很多时候是多此一举，而作为新作的RVM，在集中某一些应用领域的情况下，在借鉴Java分代式的基础上，完全有可能利用最新的研究成果。

4. JIT: 这一块目前还没有被真正考虑实现，但只是时间问题，有很多经过实践的理论和做法。


Ruby的新作VM可以从Java、CLR、ML等等虚拟机的发展借鉴很多东西，特别是Java的虚拟机有很多概念来自Sun的一个研究项目Self，而Self里面有很多点子至今还没有挖掘完。另外IBM的研究项目Jikes Research VM也有很多很好的创意。据我所看过的论文和文章，并没有显示出RVM采用的技术在理论方面落后于JAVA，这是我所说的理论上没有问题的原因。

另外，Robbin提到的问题是在一定程度上存在的。但是Ruby被越来越多的人接受已经成为事实，如果集全世界Ruby爱好者之功，集中精力去提升一个RVM,我想情况可能会和每个商业公司或者很多个开源组织各自实现自己JVM的有很大的区别。

关于Ruby的第三方库，其实已经经过了很长时间的积累，但是和Java、Perl这些语言相差甚远。这里也可以分两方面来看，一方面Rails对框架的要求可能不需要这么复杂，甚至有时候没有那么多选择。这固然有一定的问题，但是也会有好处，大家可以集中精力把每一块发展好，而不是变成Java那样东一斧头，西一锤子，另外一方面，目前Rubyforge上的发展趋势非常迅猛，登记的新项目非常多，很多Java和CPAN的库正在被不断移植过来，可以想象一样未来的趋势，我感觉只是时间问题。

同意Robbin的才华说，一直有关注grails的CVS，感觉她的开发速度实在太慢太慢且势单力薄，从去年夏天到现在，9个月过去了。

   如果Grails能解决人手问题，的确很有机会与RoR一拼。
   Ruby社区10年了才只有Rails一枝独秀。访问rubyforge.net，除了ror，都找不到别的太有用的东西，最基本的，报表呢？quartz呢？jms呢？so ...很多J2EE里的名词还找不到对应。可能近期内ror都还只适合做做web2.0的网站(如果单做网站，又要和php的成熟应用 PK一番呢），与企业应用不沾边，除非企业应用属于最简单那种CRUD的MIS.

   最后，很八卦的发现，grails和springside的首页，居然copy from same template, 好好玩阿。

   http://www.springside.org.cn
vs
    http://grails.codehaus.org/

寒一个先（果然够八卦）

白衣大哥，加入动态语言写业务的例子怎么样？考虑考虑

没有啊，我就想把某些适合的类改为用动态语言写而已。

Spring2.0 与动态语言的结合，SpringSide的Web Servervice Client已经作了demo。

   然后很郁闷的发现一个现实， Spring 与动态语言写的类的交互，是interface base的。 也就是，动态语言写的类必须实现一个接口，显式实现接口定义的所有函数，并且参数和返回值的类型都必须显式定义。

   本来发现那个web service client的实现超整齐，还以为是Goorvy的MOP，也就是Ruby的missing mehtod 大发神威的地方，可以一次定义N个方法。

晕，ws那块一直没看，星期一就打算在项目中加入的。
一会就看看。

不过后面一点似乎会很不爽，一直看着missing method眼馋

1、session的问题算是好解决的。

3、Linux kernel2.6之前，线程是用轻量级进程模拟的，确实差别不大，但自从2.6的NPTL之后，线程性能提升极大，我测试过同版本Hotspot JVM在升级kernel前后的数据(这个论坛企业版帖子里面就有)，性能提升有5倍之巨。进程模型是稳定，但是性能，还有IPC通讯开销恐怕不能凭感觉吧。

4、这确实是的，不过那种规模的应用应该比较少。

5、这个我还是比较有经验的，因为我有非常丰富的PHP/Java互联网站运营经验(2000-2001年)，不使用PHP长连接，和Java连接池差距差不多在5-10倍之间(Oracle数据库)，使用长连接，性能差距缩短到2倍左右，但是保持大量数据库连接，对Oracle压力非常大。RoR的FastCGI方式和PHP的Server module方式是一样的，我想RoR不会比PHP更好。

另外企业应用和互联网应用确实挺不一样的。企业应用不谈那种OA的，有很多行业应用(银行的票据业务，电信的账务，物流等等)负载量还是非常大的。

之所以没有强调互联网应用，是因为互联网应用往往并发压力更高，不管Java，还是PHP/RoR的，都必需采用前端页面缓存代理，后端数据库群集，两者的差异反倒不明显了。

不过还是被potian说的动摇了，准备先放下grails了，时间放在RoR上面先。

其实线程也有很大的问题，每个进程的线程数目都会受到限制，即使不限制也会因为线程的频繁切换而造成系统极度颠簸。所以需要支持非常大数量的服务器采用进程加少量线程(或单个线程）的事件模式是比较好的选择（C10K problem），lighttpd，lightspeed是比较好的例子。对于PHP/rails这些程序来讲，其实Web服务器就是他们的应用服务器。

除了上述考虑之外，为了提高PHP本身运行的效率，PHP推荐的使用方式也应该是单线程服务器，http://www.php.net/manual/en/faq.installation.php#faq.installation.apache2。因此，即使是在多线程的情况下，PHP也推荐使用FastCGI这种模式。但是Apache的FastCGI支持非常之差。而如果采用Fork或preforked模式，每个请求就需要一个Apache服务器进程实例,其中的每个PHP module就是一个PHP解释器，以及Apache附带的其他module,则会大大消耗系统的资源。

采用FastCGI以后，每一个PHP进程只需要PHP解释器，大大降低了内存和其他资源的消耗，甚至所有的PHP实例可以放在另外一台服务器，成为专门的“应用服务器”。

因此，单线程服务器+FastCGI是一种比较高性能和伸缩性较好的部署方式。PHP/Ruby进程的数目的配置也可以大大减少就可以支撑大量的用户请求，但这方面我没有很具体的数据。

而如果这种方式如lighty+FastCGI方式构成假的应用服务器，虽然他们需要通过IPC进行通讯，但对应J2EE服务器的多线程处理模式处理极高用户并发造成的系统颠簸，需要综合两方面的因素，很难说谁能够胜出。当然这只不过是我的感觉，但是要测试的话，就需要针对不同的体系结构配置合理的部署。我不是很清楚Robbin的测试是否公平:)

但是在企业级应用负载真的比较大，需要集群的情况下，这些差距将会进一步缩小，而对于Web程序来讲，Rails的页面缓存、部分缓存基本上和J2EE应用程序所能采用的方式一样了，而且Rails本身内建了这些机制，使用起来非常方便。