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

多数据库事务，半道出错了怎么办？

动态编译，牛！

呵呵，原来LZ也是身经百战，那在下说话也可以放开来了 ：）
直接一点，但绝无恶意，只是个人经验和一些善意的想法。

实际项目经验不足：
1.实际项目在生产中修改逻辑不现实
  特别是JAVA这种静态语言，不预先编译/测试/打包，而是冒着源代码编译出错的风险，在运行时自动编译/加载，恰恰是舍弃了静态编译的唯一优点。
  而在实际项目中，有没有可能不做任何措施，就直接给数据库增加个字段，或者修改源码增加点逻辑？
  实在难以想象如何能保证 数据库修改/源码编译/类加载/视图修改 等等各个环节的同步而不出错。
  实际项目的修改只能是原子性的，要么全改要么全不改。
  （虽然这在 PHP 中可能的，但很大程度基于 PHP的动态性及进程模式，但 JAVA 不是 PHP）

2.实际项目最有可能在生产中就冒险修改的只有视图
  （虽然不提倡这样做，但要视情况而定）
  PHP如果在产生中热修改，往往修改的就是视图部分，而不是逻辑。
  但如果只是视图修改，目前 FreeMarker 等本身就已经支持热修改。

3.App Server并发网络连接数有限
  只要有前端 Web Server 做了静态资源服务及网络数据传输，App Server的并发连接数量有限，通常就是数以十计。
  参看 http://redmine.lighttpd.net/wiki/lighttpd/Docs:PerformanceFastCGI 。
  因此对于 Douyu，无论是出于开发的复杂度，还是实际的性能，都是阻塞IO比异步IO占优。
  前面在下表达的不是 NIO 本身的好坏，而是对于 Douyu来说不必要也不适合，是不必要的复杂。

4.没有将有限的精力用在刀刃上，实现功能的优先级混乱，不知道实际项目最需要的是什么。
  目前 VIEW、数据存取、缓存 明显是 Douyu 生死存亡之软胁，比起锦上添花的 验证、权限 重要得太多。
  很大程度上，在下觉得是因为 Douyu 没有应用到一个实际项目中，而LZ的经验又不足引起的！

一些基本常识欠缺：
1.NIO不能提高性能，但是可以减少资源浪费，特别是内存和CPU占用率。
  NIO可以提高性能这个误解，就像很多人以为多线程可以提高速度一样。
  又如很多人分不清网络传输速度和带宽的区别。

2.Web Server有接口
  Web Server的接口一般不是语言级别，而是通过网络协议实现，例如 Http 、Apr 。
  这方面 ROR 就是例子，用其他 Web Server 做前端，ROR本身是不提供 Web Server 功能的。
  App Server 实现了通过 Http 协议与 Web Server 通讯，与 App Server 自己成为一个合格的 Web Server ，还有十万八千里的差距。

其他一些看法：
1.框架和平台不是设计出来的，是最佳实践真刀真枪拼出来的
  Douyu要得到更好的发展，必须将Douyu立即应用到一个实际项目中，正如 ROR 的发展过程那样。
  如果没有一个特别真实的项目，那可以基于 Douyu ，开发一个 Douyu的官方博客或者论坛。

2.不是够不够强，够不够复杂的问题，而是有没有强的需要，有没有复杂的必要的问题

3.技术本身是否有用，跟是否适用是两回事
  纯粹个人感觉，LZ有些地方是为了应用新技术或者复杂的技术而应用。
  象流行设计模式的时期，初学者恨不得将所有模式全部用在新项目中。

4.使用第三方库未必是坏事，如果有适合的还可能是好事
  纯粹个人感觉，LZ严重排斥第三方库，无论其是否合适，是否做得比 Douyu中相应部分更好。
  例如：
===========================
Play!framework我今天看了大半天，它也是用了编译器，只不过不是Javac，而是JDT，
还用了无数的第三方jar库，连VIEW层都是使用其他实现的，
Douyu目前很小，加Javac一起才1M多点，Play!framework解压后80多M了，
Douyu的VIEW层也是由Javac编译，只是语法没Play!framework强大
===========================

5.PHP、JAVA、C/C++ 都有自己的特性

6.源代码写和看是两个不同但相辅相成的方面，既要写也要看，最重要是有思考

前两天在新闻看到这个框架，当时觉得很像Play!

今天把前面的算是User Guide读了一遍，嗯，想法蛮不错的，楼主毅力我是很敬佩。读过javac的源代码；为Play!贡献过一点点，算是通读他的代码。也挺期待拜读下作者这个框架的代码。。。

Code for fun的心态很好~

发现我发的时候，richy回了几篇。。。

澄清一下，Play!的web server就是Apache的Mina，

http://mina.apache.org/

NIO没什么不好的，java的web server也没什么不好，jetty也是java的。而基于java的web server，NIO是个趋势，jetty6也加入NIO了，当然Mina也是NIO的。既然java可以方便使用NIO框架，何乐不为？

其他，我就不想陷入技术争论了，没什么好争辩的，呵呵~



是个好建议。

虽然言语很犀利，不过我喜欢。



首先必须明确一个前题:

你所说的观点大多数是以"实际项目在生产中"为前题，
而我整篇文章都是以"项目没投入生产，正处于开发过程中"为前题(只是没明确说明这句话)，
说得专业点就是:你指的是产品模式，而我说的是开发模式。

在产品模式下，只要发布部署命令，
Douyu可以做到将所有的Java源文件、模板文件、数据库相关的模型类全部编译成class文件，
把这些class文件再和所有的静态资源(html、css、js、jpg等等)一起打包成一个jar文件后直接发布。

你甚至可以把原来的Java源文件、模板文件全删了。
在产品模式下运行时根本不涉及动态编译问题，全都是静态的。

只有在开发模式下才会检测Java源文件、模板文件是否修改。


如果你上面这两点都是在产品模式下我当然认同，
如果在开发模式下不能直接修改数据库那是很难想像的，
我专门提出PHP并不是说我的项目经验中只用过PHP，
而是说PHP随便就可以写上10万行代码，
当然，我开发Douyu也是受了PHP的影响，
Douyu就是为了要让Java也能像PHP那样改完代码刷新浏览器就能马上看结果，
这就是在开发模式下带来的好处，开发模式时Douyu是动态的，
但是在产品模式下时PHP还是动态的，这就是Douyu比PHP先进的地方，
Douyu在产品模式下又变成静态的了。


还有一点我不认同的你的说法，
在产品模式下为什么修改视图修改数据库，修改源代码就有风险?
难道没有开发测试环境吗，连个测试数据库都没有吗？
先在开发环境测试通过后难道就不能再投入到产品模式下？




我并不是说NIO的性能比阻塞IO高，
我上面说的:

更多是并发量大小的问题，而不是性能问题。
你知道我为什么选了NIO没选阻塞IO吗? Tomcat6中既有Http11Processor(阻塞IO方式)
又有Http11NioProcessor(NIO方式)还有Http11AprProcessor(采用tcnative-1.dll)，
Http11Processor跟Http11NioProcessor的性能优势并不明显，
Http11Processor在并发量小的情况下性能比Http11NioProcessor好些，
但是并发量达到一定程度时Http11Processor间接发起的worker threads(在JIoEndpoint中定义)一下就达到最大值了，这时明显比Http11NioProcessor慢，
但是Http11NioProcessor又有Bug，一直不稳定(所以NIO模式一直都不是Tomcat的缺省值)
Http11AprProcessor的性能最好，
Tomcat6甚至强烈推荐用户安装tcnative-1.dll，
如果你用过Tomcat6，一起动Tomcat6没找到tcnative-1.dll就会发出警告建议你安装这个tcnative-1.dll，
但是这个是本地库啊，还得顺带加入org.apache.tomcat.jni包，我果断把Http11AprProcessor舍弃先了。

最后，我没用Tomcat6的Http11Processor也没用Http11NioProcessor，
自己写了一个NIO的Http链接器，小并发量时性能跟阻塞IO没什么分别，
也能支撑中等规模的并发量。

当然，你的前题也是在App Server前面再加个Web Server，静态请求是少了，
但动态请求就少吗，Web Server能处理动态请求？
最多也只不过先在Web Server把动态请求缓一缓再转发App Server，
除非一个Web Server后面集群了多个App Server，然后负载均衡。

但是并不是每个App Server前面都非得加Web Server不可，
很多中小公司开发项目只使用Tomcat当服务器的多的是，
不然Tomcat那帮人何必还在源码中加那么多处理http协议的代码，
直接叫用Tomcat的人再装个Apache得了。




呵呵，说生死存亡过早了吧，不并急于求成，
Play!framework到现在两年了目前也没见它对SSH有什么冲击，
我才做了不到一年，好东西是要时间摩出来的，
VIEW、数据存取、缓存这些在Java领域内好的东西、成熟的东西也很多，
不可能一下就得超越，Douyu要有自已的特点，比如ORM自动化(包括验证)这是我铁定追求的目标，
不然就没有特色了，比如我花了两天看Play!framework，除了也是动态编译之外，
没发现有什么自己的特色，ORM还是用JPA(通过Hibernate)，
VIEW、缓存也有了，但是都不突出。

我觉得Douyu目前并不急着马上投入实际项目，而是把自己该做的做好，
先要解决一些Bug，让她更稳定可靠，再完善自己的特色，
再完善VIEW、缓存。


关于这点，我还是有自已的看法，NIO不能提高性能并不是绝对的，必须有个并发量大小的前题，
再拿Tomcat来讲，阻塞IO并发量一大，所有Worker线程都阻塞在读取数据上了，
阻塞线程不占用CPU了，但是新请求没法处理了，性能就无从谈起，响应时间也是个性能指标，
现在响应时间要么无限延长，要么服务器拒绝服务。
如果是NIO，只须少量的Worker线程却能处理大量请求，你能说它性能比阻塞IO差？

另外，如果NIO的Selector在select轮询时，如果不注意控制细节，反而会让CPU占用率到99%。




这点应该说是我描述不清，前面我回复说:


上面的AprProcessor名字我没打全，就是指Tomcat6的Http11AprProcessor，
就是你讲的Apr，就是用tcnative-1.dll，
但Tomcat与Apache的通讯协议是专用的AJP1.3协议。

我的意思不是说Web Server没有提供扩展接口，
而是说，如果我仅仅是为了把处理静态资源的那一块小功能分离出去就动用Apr是不值得的，
这也是我没有直接移值Tomcat6的Http11AprProcessor到Douyu的原因，
除非真的要支持集群，否则目前没这个必要。

-我们现在不管热编译还是传统方式编译,都是不敢直接动生产的,而是先在测试环境通过才可以,我觉得这种热修改是节省了程序员的时间...我觉得跟动不动生产没有关系.

NIO也不是什么新技术,只是在IO上面包了一层观察者的模式.rich前辈说得正式.