`
wangxiaohigh
  • 浏览: 1419240 次
文章分类
社区版块
存档分类
最新评论

关于国人项目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关系图(感觉比较散啊,侵入性太强了……):

01

00

分享到:
评论

相关推荐

Global site tag (gtag.js) - Google Analytics