Without SSH/JSP/Servlet,不走寻常路,Java可以更酷

呵呵，老兄，在下整个帖的回复都是集中在 Douyu这个范畴的啊。
在下很清楚 NIO 是干嘛用的，不是说 NIO 本身不好，而是说 NIO 对 App Server 没有价值。
同样，MINA这个框架对于 Play! 也是没有价值的，还平白无故多引入了一个库。
原因之前已经表达得很清楚了。

而且在下不认为 Jetty、Tomcat 内置的 Http 功能称得上是 Web Server 。
绝对一点，在下打赌基于 JVM ，不可能有够得上 Lighttpd、Nigix、Litespeed 的 Web Server 。
所以有现成的好东西，何必要自己做一个不够好的？

LZ，在下觉得前两次，已经表达得很清楚，总结一句话就是，建议LZ将有限的精力用在刀刃上。

至于哪里是刀刃，见仁见智，在下的经验最后总结一下，仅供参考。

当然这些建议全都集中在 Douyu这个范畴内，不要扩大化。

1.一个实际的 App Server ，真的就是只有最多 20、30个并发网络连接才是常态
  不要凭空创造可能会有成千上万的并发网络连接的需求。

2.重做LZ以前的项目也不错，不过一定要大家都能24小时不间断访问才够真实，也才有意义

（以下建议假设 Douyu的所有部分都有价值，但可以更简单和更有价值）

3.既然在生产模式 Douyu变成静态部署，那么更好的做法是否将 Douyu分成 Hotswap Platform 和 Framework 两部分？
  Hotswap Platform 只在开发模式使用，包括自动编译/加载功能。
  Framework 在开发模式和生产模式都使用，包括 Douyu自己的 MVC、ORM、VIEW、权限、检验、工作流等。
  意思是，在生产模式，只要一个用户已经非常熟悉的 Servlet容器，例如 Tomcat 就可以启动。
  这样，大家就很容易接受 Douyu 应用到实际项目中，从而反过来体现出 Douyu的价值。
 
4.Hotswap Platform 的功能目前有个成熟的实现 JavaRebel
  听说很完美，在下还没有用过，不过非常值得LZ研究一下。
  如果真的很完美，那么 Douyu的 Hotswap Platform 其实就一定要重新实现了。
  （当然，JavaRebel是收费的）

  另外这里有个问题，修改表之后 Douyu是否要重启才能生效？
 
5.Framework 部分，不需要抛弃 Servlet（JSP这种垃圾可以抛弃掉）
  Douyu基于 Servlet ，但是 Douyu的用户不接触 Servlet 。

（以下是在下跟 Douyu 大约有关的一些想法、做法）

6.浏览器刷新即重加载的开发方式效率未必高
  在下需要启动或者重启App Server的次数不多（也就一天几次）。
  关键在于复杂的逻辑用自动单元测试配合开发，简单的CRUD功能用自动集成测试配合开发。
  也就是在不启动 App Server 的前提下，可以跑应用的大部分，并且是自动化的校验。
  连浏览器都不用打开，无需人工测试，这样的开发方式在下觉得效率更高。
  只有在测试 UI 时，目前还是使用人工方式，未实践到比人工更高效率的方式。
  这种方式无关用什么框架，用或者不用框架都实践过。
 
7.复杂还是简单是相对性的
  有更简单的方式可以到达目的，原来使用的就是复杂。
  如果复杂性存在于事物内部，就是必要的复杂，不可避免；如果是人为创造出来的复杂，则是不必要。
  NIO无论原理还是实践，本身都是很简单的技术，但在下仍然认为在 App Server 中是复杂了，因为有更加单的阻塞IO方式。
  NIO在App Server中毫无必要且响应时间和性能都稍低。
  在下以前之所以要用 NIO，是因为做的不是 Http 协议，而且真的要应付数以千计的并发网络连接，又没有象 Lighttpd 等成熟的产品可以使用。
  异步IO在JAVA 1.4成为标准，可算是新技术；但是在 C 上，有数十年历史了，无数人都做过。
  最要命的是以LZ个人之力，更不应浪费时间在这上面。如果是一个团队，在下倒是觉得 Douyu自己实现一个强大的 Web Server 也无伤大雅，还多了个谈资。
  另外，在下不认为操作两个数据库就是分布式。

8.轻量级Servlet容器自身的启动速度已经非常快
  如果不算其他 WEB 框架，就 Jetty6/7、Tomcat6 等本身的启动/重启速度已经非常快，在1－5秒内。
  也就是说他们的 auto reload 功能，已经具备相当的实用性。

9.Douyu的现状
  自动加载不知比起 JavaRebel 怎样。
  Control 比 struts2 总体不具优势，在 Restful 方面劣势。
  VIEW太过简单未可用。
  ORM不是很清楚，光看是还不实用。
  缓存缺失。
  校验、权限不必要，且目前不实用。
 
说这些不是要贬低 Douyu，而是说以LZ的能力，在相同时间内应该可以做得更好！
今天的 Douyu 不应该是一个每样都还差一点的平台！
应该是一个能自动加载免重启App Server，Control、VIEW、ORM 均可实用的平台了！

非常感谢rich提供的建议，
虽然有一些建议我不是很赞同(比如 JavaRebel )，
不过也不用去解释了，
总之我会仔细考虑rich提供的建议。

同时呢，也请朋友们有问题也暂时别问了，
因为我得coding去了...

呵呵~我不太明白Jetty、Tomcat为什么不算web server？愿闻其详。。。

例如Lighttpd+Jetty就是个不错的选择。

关于性能，更多在于架构不在于到底选择什么容器。。。
譬如，GAE一开始用的是Jetty，然后现在是Tomcat


关于Mina，只不过是Play!的一个轻量级选择罢了，它没有很极端从编译下手，而只是换了下class loader，基于Play!的程序可以用play -war命令生成标准的war的。

Play!是一个很中庸的做法，它里面乱七八糟的包够多了，也不差个Mina，对哇？

其实每个框架表象出来的是作者的思想，作为技术决策者，在合适的场合选择一个与自己思想一致的框架才是正确的。如果我要为我服务器开发一个管理portal，我肯定不会用Play!或者Douyu，GWT或许好一点。。。

这里面不存在绝对的对与错。。。

看的懵懵懂懂 ，不过很佩服你 ，加油啊！！！

老兄，你已经说出了答案，Jetty前面要加个 Lighttpd 。
java弱不禁风的 http 容器，比起现成的 Lighttpd们，无论功能、性能、稳定性、CPU/内存占用 都相差得太远了。

好多看不懂，不过还是佩服楼主
可惜robbin和江南白衣不在，不知道他们是怎么看的

呵呵~原来你是这样理解的。okay~

看帖要看完，要不会漏掉许多精彩的
肉饼已经发表过意见了

问一个问题，playframework框架，如果是自己写的类，放在哪个目录会自动编译啊？象Grails直接放在src目录下就行了~~play!好象不行啊~~