关于国人项目Douyu的初步分析

中午吃饭时大略分析了一下Douyu的业务实现过程，趁着没人偶赶紧发上来……由于该平台尚未开源，分析可能存在某种程度的误差，对与不对有赖读者自辨……

咳， 经过一段相当漫长的钻研，偶得出如下结论： 

就目前所见，Douyu项目由com.douyu.config，com.douyu.engine，com.douyu.engine.core，com.douyu.engine.db，com.douyu.engine.dialect，com.douyu.engine.http，com.douyu.engine.http.buf，com.douyu.engine.http.fileupload，com.douyu.engine.http.session，com.douyu.engine.http.util，com.douyu.engine.log，com.douyu.engine.util，com.douyu.http(不理解为什么不同com.douyu.engine.http写一起……)，com.douyu.main，com.douyu.security，com.douyu.sql，com.douyu.tree，com.douyu.util等包组成。

由于重写了javac的部分java编码，Douyu可以“表面上”直接读取Java文件，也就是Douyu可以不需手动编译即可令Java文件被执行，也可以动态增删java文件内容，但与常见的java字节码修改不同，Douyu的动态特性依赖于添加相应字符串到java文件对应内容后的重新编译。

在Douyu的engine.core包下有两个非常重要的组件，堪称是Douyu的核心所在，一个是调用com.sun.tools.javac包的javac类，一个是真正用于处理Douyu中javac命令的CleverCoder类（在com.sun.tools.javac.main.JavaCompiler与com.sun.tools.javac.comp.Enter中被调用），应该说，javac只是一个调用数据的马甲，而核心在于CleverCoder。至于CleverCoder对于java文件的处理原理，则与jsp生成servlet的原理相类似（顺便说一下，前天偶提到Douyu只能加载静态页面，现在看来并不确切，应该是Douyu可以将view层转义为Java文件，再编译执行转义后的文件并反馈到页面中去，由于Douyu中存在ViewEntry，view数据也会经由updateView函数进行逐行分析后处理并反馈，其与jsp转servlet过程大同小异，但对其运行效率保留意见……）。

Douyu加载java文件与类使用自定义的ResourceLoader，其继承关系如下：URLClassLoader->LibClassLoader->ResourceLoader。

ResourceLoader内部依赖Javac，以ConcurrentHashMap缓存数据，Douyu在每次loadResource时都会判断目标对象是否存在，存在则调用已有对象，不存在则调用异化后的javac生成该对象。纵观整个Douyu平台对ResourceLoader的调用，显而易见Douyu中ResourceLoader重点不是用于加载class。与标准ClassLoader相比，ResourceLoader更像一个javac命令的缓存与执行器，它之所以存在，实际上就是要加载java文件本身，类加载功能反倒其次。

目前来说，ResourceLoader处理不同功能的函数接口并不统一，针对不同功能需要分别调用对应函数，例如在其DefaultContext中out时尚需要分别调用loadClassResource与loadStaticResource，而在Database的MetaData类中又需要调用compileClass（内部会调用findClassOrClassResource查询指定类，有类加载，没有则调用javac编译java文件后加载），到了http包下属的Connector里又得加载loadResource来匹配类与PrintWriter中数据。

Douyu目前涵盖有http请求与反馈、db操作、security验证等主要功能，但实现程度普遍较低。比如数据库方言仅支持mysql、oracle、sqlserver三种，而且只有mysql与oracle实现了不同的limit与非常少的操作优化，sqlserver部分暂时看还是空壳。security中的rule还只有一个接口，没有看到具体业务逻辑与调用，能够被checkPermission函数处理的Permission实现也非常有限。http协议部分虽然拥了有最基础的协议解读能力，但也仅仅是最基础的能力而已，比如目前我即不能向Douyu服务器要求对目标资源进行gzip压缩，Douyu也不可能根据浏览器判定此要求是否可行，更不要说反馈数据了，诸如此类的不足还有很多（仅以偶07年在各大小说网站刷票得到的http协议应用经验看），建议作者去找一份http1.1协议文档逐一比对并分别实现。没办法，谁让Douyu是个孤立的平台，开发难度自然大些（不过都写上的话，性能又会大打折扣，照目前的业务逻辑完全补足协议与相关功能后，我断言Douyu效率比不上Tomcat6，所以系统尚待优化）……

综上所述，窃以为Douyu平台在技术上存在可行性与创新性（如果作者有闲钱的话，可以考虑在国内申请个技术新型专利，最起码摆着好看），只是业务功能暂时不足，部分领域有待分工与优化，尚不具备很强的实用性，希望作者响应国父“革命尚未成功，同志仍需努力”号召，持续发展，与时俱进，吾辈就以观后效了……

以下拣选了两张分析代码时生成的Douyu关系图（感觉比较散啊，侵入性太强了……）：

【原文来自： http://blog.csdn.net/cping1982/archive/2009/11/18/4828513.aspx】