再谈谈Play!框架
Play!也一直在关注，包括最新的1.0.1和1.1 branch。
在View层、缓存、测试这三方面Douyu跟Play!要实现的东西和采用的套路都差不多，
比如Play!内置的模板引擎也是先把模板文本转化成Groovy代码然后再运行，
Douyu现在也是先转化成Java代码然后编译再运行(跟JSP一样)。
在开发阶段，这种先编译后运行的方式通常比Velocity或FreeMarker这种动态解析的方式要慢。
但是在部署阶段因为模板文本已经编译过了就比动态解析的方式要快一点。
Play!新加入了“Japid template engine ”，无非也是要提高view层模板的渲染速度，
具体实现技术我还没去研究。
Douyu现在也正尝试Velocity或FreeMarker动态解析的方式，
这在开发阶段很有用，如果熟悉JSP的话，只要JSP页面代码量稍大一点，
每次改JSP代码然后刷新浏览器一般需要1.5到2秒的响应时间，
1.5到2秒在开发阶段还是不能承受的，只有响应时间不超过1秒才不会感觉到有延迟。
缓存方面Douyu跟Play!现在也是直接整合一些流行的缓存框架
Douyu目前整合了Ehcache和OSCache，
Play!目前整合了Ehcache和Memcached
测试方面Play!现在要比Douyu强一些
Douyu只是整合了JUnit，可以进行单元测试和功能测试。
Play!除了能进行单元测试和功能测试外，还集成了selenium，
可以进行Selenium测试，这是Douyu目前未实现的。
老实说也曾想过看看能否把Douyu跟Play!整合一下，
但是除了上面说的三点相似外，内部的核心架构完全不同，
比如最简单的一个例子在Play!中每个控制器类要继承play.mvc.Controller，
而Douyu的控制器类不采用继承方式，
Play!的render是采用抛异常的方式来结束Action的执行的，
一个Action只能render一个模板，而且每个Action方法都是静态的，
而Douyu不抛异常，一个Action能render任意多的模板。
动态编译方面更加不同，Play!是从编译后的字节码下手，
而Douyu是先从Java源代码下手。
Play!目前在Modules开发方面比较活跃，
这些并不属于核心架构的东西，
在Play!上能运行的Modules，只要那个Module的开发者愿意，
其实很容易就能移植到Douyu。
Play!在1.1 branch中要加入对Scala语言的支持，
Douyu并不打算支持Scala语言，Scala语言学习门槛太高，
近期内要普及还是件难事，所以我想Douyu应该先把时间放在其他更实际的问题上。
另外，Play!还加入了Grizzly、Netty的支持，
我觉得这些都不是很大的亮点，中小规模的应用Tomcat足够了，
大点的应用Apache加Tomcat集群也能应付，
Grizzly、Netty这类http服务器处在一个不上不下的位置，
普及性也很低，所以Douyu目前也不打算支持Grizzly、Netty。
Play!在Model层还没看到什么大点的变化，跟Douyu的实现方案也很不同。
当然还有很多的不同，这里就不再细说了，
所以我想以后Douyu跟Play!应该不会走merb跟rails合并的路，
谁好谁坏就留给开发者去选择吧。
import douyu.mvc.*;@Model( type = ModelType.VO )public class User {private String name;private int age;//这里也不用写setter或getter方法，编译器会自动生成，//甚至在其他类中可以直接用user.age()这样的形式来访问age字段}
然后调用ModelManager接口中的方法(比如insert、update等等)
就可以把User存储到任何地方(比如关系数据库、硬盘文件或其他非关系数据库)，
存储到哪里取决于ModelManager接口的实现类，开发人员也不用关心实现类是什么，
对4种Model的操作都统一使用ModelManager接口，
在运行时由Model的类型来确定实际的ModelManager实现。 8 楼 ZHH2009 2010-02-25 Arden 写道至于Model我倒是觉得CQRS(axonframework)这样的框架更好，比如：http://code.google.com/p/axonframework/
这个东西不了解，你可以简单说说它好在哪里。 9 楼 Arden 2010-02-25 ZHH2009 写道Arden 写道至于Model我倒是觉得CQRS(axonframework)这样的框架更好，比如：http://code.google.com/p/axonframework/
这个东西不了解，你可以简单说说它好在哪里。
可以参考下这两往篇文章：
http://www.jdon.com/jivejdon/thread/37891
http://www.jdon.com/jivejdon/thread/38007 10 楼 Arden 2010-02-25 另外还有一个非常重要的一点就是部署到生产环境之后，我如果修改了模版文件（就改一下页面上的东西）最好能够做到自动加载，而不是还要重启应用才行，目前Play!就有这个问题，我改点页面上的东西都要重启，这对于Web网站来说很痛苦，因为Web网站有时候变化太频繁了~~ 11 楼 Arden 2010-02-25 这位朋友你有没有QQ号，能不能方便告诉我？ 12 楼 ZHH2009 2010-02-25 Arden 写道另外还有一个非常重要的一点就是部署到生产环境之后，我如果修改了模版文件（就改一下页面上的东西）最好能够做到自动加载，而不是还要重启应用才行，目前Play!就有这个问题，我改点页面上的东西都要重启，这对于Web网站来说很痛苦，因为Web网站有时候变化太频繁了~~
这个需求有点矛盾，既然已部署到了生产环境，那就意味着模版文件不会修改了，
这样服务器就不用每次请求这个模版文件时都去检查模版文件的修改时间(相当于一次小型的IO操作)；
如果修改了模版文件必须自动加载那实际上又回到了开发环境，
如果模版文件是被编译成class文件的，
要完成自动加载实际上还得动态替换先前装载这个模版class文件的ClassLoader，
否则像模板继承、include这样的情况会失效。
Velocity或FreeMarker不用把模版文件编译成class文件，
但是在生产环境也不会去检查模版文件的修改时间(当然如果不在乎性能开销，也可以开启它)。
我觉得你这个需求对于小网站来说比较合理，
因为并发量小，在生产环境启用自动加载功能也影响不大。
其他中大规模的系统，不可能动不动改了个文件就上传到服务器的。
13 楼 ZHH2009 2010-02-25 Arden 写道这位朋友你有没有QQ号，能不能方便告诉我？
有，我可以站内短信发给你，但是上QQ的时间不多，通常有事时才上。 14 楼 Arden 2010-02-26 ZHH2009 写道Arden 写道另外还有一个非常重要的一点就是部署到生产环境之后，我如果修改了模版文件（就改一下页面上的东西）最好能够做到自动加载，而不是还要重启应用才行，目前Play!就有这个问题，我改点页面上的东西都要重启，这对于Web网站来说很痛苦，因为Web网站有时候变化太频繁了~~
这个需求有点矛盾，既然已部署到了生产环境，那就意味着模版文件不会修改了，
这样服务器就不用每次请求这个模版文件时都去检查模版文件的修改时间(相当于一次小型的IO操作)；
如果修改了模版文件必须自动加载那实际上又回到了开发环境，
如果模版文件是被编译成class文件的，
要完成自动加载实际上还得动态替换先前装载这个模版class文件的ClassLoader，
否则像模板继承、include这样的情况会失效。
Velocity或FreeMarker不用把模版文件编译成class文件，
但是在生产环境也不会去检查模版文件的修改时间(当然如果不在乎性能开销，也可以开启它)。
我觉得你这个需求对于小网站来说比较合理，
因为并发量小，在生产环境启用自动加载功能也影响不大。
其他中大规模的系统，不可能动不动改了个文件就上传到服务器的。
要么有个机制，能够在不重启服务器的前提下，通过手动来重新编译加载，但不影响上线正常使用的业务，如通过一条命令什么的，如：douyu rebuild等。 15 楼 Arden 2010-02-26 Arden 写道ZHH2009 写道Arden 写道另外还有一个非常重要的一点就是部署到生产环境之后，我如果修改了模版文件（就改一下页面上的东西）最好能够做到自动加载，而不是还要重启应用才行，目前Play!就有这个问题，我改点页面上的东西都要重启，这对于Web网站来说很痛苦，因为Web网站有时候变化太频繁了~~
这个需求有点矛盾，既然已部署到了生产环境，那就意味着模版文件不会修改了，
这样服务器就不用每次请求这个模版文件时都去检查模版文件的修改时间(相当于一次小型的IO操作)；
如果修改了模版文件必须自动加载那实际上又回到了开发环境，
如果模版文件是被编译成class文件的，
要完成自动加载实际上还得动态替换先前装载这个模版class文件的ClassLoader，
否则像模板继承、include这样的情况会失效。
Velocity或FreeMarker不用把模版文件编译成class文件，
但是在生产环境也不会去检查模版文件的修改时间(当然如果不在乎性能开销，也可以开启它)。
我觉得你这个需求对于小网站来说比较合理，
因为并发量小，在生产环境启用自动加载功能也影响不大。
其他中大规模的系统，不可能动不动改了个文件就上传到服务器的。
要么有个机制，能够在不重启服务器的前提下，通过手动来重新编译加载，但不影响上线正常使用的业务，如通过一条命令什么的，如：douyu rebuild等。
其实我觉得这个应该不矛盾，至少以前写j2ee应用的时候，虽然开发的时候要重新编译启动，但至少项目上线后改个jsp什么的不用重启服务器，因为这个需求确实存在，项目上线后由于各种原因必须得改下页面上的调整~~ 16 楼 ZHH2009 2010-02-26
Arden 写道
要么有个机制，能够在不重启服务器的前提下，通过手动来重新编译加载，但不影响上线正常使用的业务，如通过一条命令什么的，如：douyu rebuild等。
你的理解有一些误区，
修改模板文件后自动加载，并不需要重启整个服务器的，
只是动态替换原有的旧的模板文件。
检测模板文件是否修改一般有3种方式:
第一: 启动一个新的线程用来定期(比如两秒钟)检测所有的模板文件是否修改，
如果发现有修改过的模板文件就重新加载。
第二: 无需启动新线程，只在真正要访问某一个模板文件时才检测。
第三: 无需启动新线程，服务器提供额外的配置管理功能，
比如提供一个界面让用户上传修改过的模板文件，然后异步通知运行时系统重新加载模板文件。
前两种方式实现起来很简单，在生产环境中还可以禁用模板文件自动加载功能，
比较适合于模板文件部署后就不会再修改的情况。
在生产环境中禁用自动加载功能实际上只是为了避免重复的"File.lastModified()"调用，
可以想像一下假如网站有100个模板文件，一秒钟内每个模板文件有100次请求，
那么在这一秒钟内就调用了1万次"File.lastModified()"，
"File.lastModified()"的调用涉及到文件系统的IO操作，这会加大服务器的负担。
第三种方式对于那种部署完应用后还经常修改模板文件的场合比较有用，
目前Douyu还未实现这项功能，但是会考虑加上去。
Arden 写道
其实我觉得这个应该不矛盾，至少以前写j2ee应用的时候，虽然开发的时候要重新编译启动，但至少项目上线后改个jsp什么的不用重启服务器，因为这个需求确实存在，项目上线后由于各种原因必须得改下页面上的调整~~
JSP也是分开发模式跟产品模式的，
比如在Tomcat中可以在conf\web.xml中配置
org.apache.jasper.servlet.JspServlet的"development"参数，
"development"参数的默认值是true，默认是开发模式，
Tomcat中每个JSP页面都对应一个JasperLoader(URLClassLoader的子类)，
当JSP页面修改了以后只是重新替换掉原有的JasperLoader，而不是重启整个Context。
如果"development"设为false,那么在部署完应用后修改JSP是不起作用的。
实际上JSP采用的方式与上面所说的第二种方式类似，
只不过它可以另外设置一个"modificationTestInterval"参数。
17 楼 Arden 2010-02-26 引用第三: 无需启动新线程，服务器提供额外的配置管理功能，
比如提供一个界面让用户上传修改过的模板文件，然后异步通知运行时系统重新加载模板文件。
其实我觉得能够提供相应的命令来实现就差不多了，比如：douyu rebuild a.html(显示重新加载某个文件), douyu rebuild a.html b.html（显示重新加载指定文件列表),douyu rebuild aa*bb.html(通过正则表达式重新加载指定文件), douyu rebuild /app/view/home(显示重新加载指定目录下的所有模版文件）。 18 楼 Arden 2010-02-26 Arden 写道引用第三: 无需启动新线程，服务器提供额外的配置管理功能，
比如提供一个界面让用户上传修改过的模板文件，然后异步通知运行时系统重新加载模板文件。
其实我觉得能够提供相应的命令来实现就差不多了，比如：douyu rebuild a.html(显示重新加载某个文件), douyu rebuild a.html b.html（显示重新加载指定文件列表),douyu rebuild aa*bb.html(通过正则表达式重新加载指定文件), douyu rebuild /app/view/home(显示重新加载指定目录下的所有模版文件）。
不一定非得要后台，因为很多时候开发人员开发的时候都是用的ftp或者ssh来上传同步文件的~~ 19 楼 ZHH2009 2010-02-26 Arden 写道Arden 写道引用第三: 无需启动新线程，服务器提供额外的配置管理功能，
比如提供一个界面让用户上传修改过的模板文件，然后异步通知运行时系统重新加载模板文件。
其实我觉得能够提供相应的命令来实现就差不多了，比如：douyu rebuild a.html(显示重新加载某个文件), douyu rebuild a.html b.html（显示重新加载指定文件列表),douyu rebuild aa*bb.html(通过正则表达式重新加载指定文件), douyu rebuild /app/view/home(显示重新加载指定目录下的所有模版文件）。
不一定非得要后台，因为很多时候开发人员开发的时候都是用的ftp或者ssh来上传同步文件的~~
这种方式也可以，只是把文传上传的事交给了其他软件去完成。
然后用"douyu rebuild a.html b.html"这样的方式通知运行时系统有文件修改了。
实际上跟我说的第三点一样，只不过一个是命令行方式，一个是采用图形方式，
采用图形方式可以一步到位，文传上传完成就自动通知。 20 楼 zxc005 2010-03-01 ZHH2009 写道
我最近在做Douyu跟Apache的集群开发工作。
建议考虑一下nginx和lighttpd，这两年他们已经蚕食了不少Apache份额了，单就性能而言，他们也确实比Apache爽得多。
21 楼 ZHH2009 2010-03-01 zxc005 写道ZHH2009 写道
我最近在做Douyu跟Apache的集群开发工作。
建议考虑一下nginx和lighttpd，这两年他们已经蚕食了不少Apache份额了，单就性能而言，他们也确实比Apache爽得多。
Douyu跟Apache的整合是基于AJP1.3协议的，在Apache端还是使用目前的mod_jk，
而在Douyu端的做法跟tomcat一样(实际上只是把tomcat的对应功能移植到Douyu)。
nginx现在还不支持AJP1.3协议，
不过我查过一些资料，nginx可以跟tomcat做集群(通过代理的方式)，
理论上说，如果nginx能跟tomcat做集群，自然也可以跟Douyu做集群。
lighttpd支持AJP1.3协议
http://redmine.lighttpd.net/wiki/1/Docs:ModProxyCore
只要支持AJP1.3协议，理论上说也是可以跟Douyu做集群的。
nginx与lighttpd我都还没具体去配置过，不过我会去尝试的。
现在我还在研究MongoDB的java驱动源代码(mongodb-mongo-java-driver)，
Douyu还会支持像MongoDB这种非关系型的数据库，
所以，Douyu将适用于分布式计算、存储的场合。 22 楼 Arden 2010-03-29 引用动态编译方面更加不同，Play!是从编译后的字节码下手，
而Douyu是先从Java源代码下手。
我看play用的是eclipse compile(jdt)来实现动态编译的，scooterframework用的切是标准的javac来编译，scooter跟douyu应该差不多~~ 23 楼 ZHH2009 2010-03-29 Arden 写道引用动态编译方面更加不同，Play!是从编译后的字节码下手，
而Douyu是先从Java源代码下手。
我看play用的是eclipse compile(jdt)来实现动态编译的，scooterframework用的切是标准的javac来编译，scooter跟douyu应该差不多~~
经你的提醒刚下了看看,确实用了javac，不过只是用了com.sun.tools.javac.Main，
也瞄了下JavaDoc中的api，我不去试了，你有兴趣你去研究吧，我没什么兴趣。
