做一个自己的AppServer-JDStream

做一个自己的AppServer－JDStream(一)构想一直以来总是有一种紧迫感，想尽力去弥补那些逝去的岁月。可是知识可以积累，经验就没那么容易积累了，另外人都有惰性，上班的时间可以十分投入，一旦下班往往就没了状态。所以我总是给自己业余时间定个目标，有了目标，就有了方向，就可以逼迫自己坐下来去深入技术，再慢慢进入状态，形成良性循环。最开始给自己定的几个目标都没能坚持下来，一方面是那时自己很多技术确实没有太多概念，另外与工作也基本无关，所以研究了一段时间后也就不了了之了。就在多半年前深入了解了下公司的一个底层RPC框架，主要就是一个包括数据库连接池、模块池、类似mina的socket模块、rmi同步和异步调用这些功能的开发包。在使用中发现该框架存在不少问题，远程调用比较麻烦，没有一个统一的调用接口，同时和业务程序耦合比较严重，每次都要写启动程序。于是就稍稍去研究了下JBoss，将公司的Jar包做了进一步包装，写成服务器的形式，自定义了ClassLoader来加载业务程序，用动态代理统一了远程调用接口，自己写了个Annotation解析器来解析业务程序中自己定义的注释。这些完成后是比原来方便了些，但随着对AppServer研究的深入，发现现有框架仍有非常多的不足，不是修修补补就能解决的了，于是就决定重新写一个AppServer。目的不在于能否写一个多牛的服务器，而是给自己定一个目标，来研究这些技术，希望通过这个能使自己的技术提升一个高度，同时附带着做一个自己用着顺手并且可以完全控制的AppServer出来。用了将近一个月的时间囫囵吞枣的读完了《JBoss架构分析》，同时粗略的阅读了JBoss4和JBoss5的启动源代码，对AppServer的实现有了个具体的概念，发现自己以前项目中的应用程序完全可以挂在JBoss下面，但现在的目标是写一个相对轻量级的、可以自己控制的、以IOC为容器而非JMX为容器的、偏重与处理业务数据流的支持高并发的AppServer。出于偏重于数据流处理的需要，所以准备暂时将之名称定为JDStream（JAVADataStream）。做一个自己的AppServer－JDStream(二)选型文章分类:Java编程关键字:appserver服务器分布式JBoss4及其以前的版本主要是用JMX做为系统总线来管理插件，好处是显而易见的，可是随着IOC的发展，JMX作为容器插件也有很多不足，比如JMX作为容器过于复杂，与业务程序耦合过多，不够POJO，所以JBoss5有所改进，它用JBossMicrocontainer作为IOC插件容器，同时通过JMXKernel将JBoss4的内核连接进来，把本属于JMX管理的bean的生命周期委托给Microcontainer管理，但由于JBoss过于庞大，并没有从根本上解决问题，Microcontainer虽然从内在上管理了Bean的生命周期，但很多插件外壳还是由JMX来管理的，需要构建mbean，和Jboss过于耦合。所以JDStream采用IOC完全管理插件，但又不像Spring那样托管所有Bean，它只需要管理插件入口的Bean，方便拆卸同时又不会产生很多烦人的配置，另外还需要管理业务代码中的一些Bean。JMX作为插件和业务模块的配置和监控容器，尽量减少它的使用。由此IOC框架和JMX实现作为两个最基础的框架需要优先考虑，此次构建JDStream的最大目的在于磨练技术，不需要一切从头来，这两个框架都采用开源的，在需要的时候对他们进行扩展甚至修改。IOC框架可供选择的大概有下面几个：Spring、JbossMicroContainer、PicoContainer和JFox。Spring过于庞大，更适合做外层框架，不太适合将它集成到别的程序里面；JBossMicroContainer从使用上来说是个比较不错的IOC容器，轻量且有多级生命周期策略，控制比较细致，但作为单独的IOC容器，在06年的时候已经停止开发维护了，JBoss5嵌入的MicroContainer在原先的基础上有了很大的扩展，同时和JBoss5的程序耦合在了一起，很难分离出来，所以不太合适；JFox的IOC容器同样和框架耦合在了一起，同时也过于简单，用起来可能要做很多扩展；PicoContainer短小精悍，生命周期虽然只有start、stop和dispose，但基本够用，如真不够使用可随时扩展，最新的版本增加了monitor，可实现对bean的监控，唯一问题是它没有XML解析器；综上所述，决定采用PicoContainer作为IOC容器，XML解析器自己写。JMX实现比较了JBoss的实现、JFox实现和MX4J后决定用MX4J，这个主要是前两个很多实现是为自己的框架定做的，而MX4J作为一个独立的JMX实现比较符合需要。两个基础框架定下来后下面就是要集成的插件了：JNDI：自己实现，以便于集群；AOP：自己用动态代理和CGLib写个简单点的；数据源模块：自己封装JDBC，支持事务；socket：集成mina；JMS：用JCA集成Activemq，支持事务；Webservice：集成axis2或xfire，没想好呢；cache：集成memcachedjava客户端和BerkeleyDBjava版；任务调度：集成quartz；rmi：修改公司的rmi异步调用框架，提供同步和异步RMI工厂，支持JRMP和IIOP；监控：集成telnet监控，通过telnet来和JDStream交互，了解服务器运行状况；httpServer:集成tomcat或jetty；camel：还没了解太清除，有可能的话也集成；集群：用JGroups，关联到JNDI、socket、JMS、webService、cache和rmi插件，也是个基础插件；线程池：鉴于业务模块的热部署，线程将被集中管理；业务模块部署器:实现业务模块的动态加载，Annotation解析；Annotation解析器：支持自定义Annotation。其它：有可能的话加上安全和事务方面的；做一个自己的AppServer－JDStream(三)IOC容器文章分类:Java编程关键字:appserver服务器分布式Guice和PicoContainer的比较感谢mineral在此系列博客的上一篇当中推荐的IOC容器Guice，没来得及看源码，初步了解了一下，发现Guice确实有自己的独到之处，它和Spring的最大区别应该是构造够轻量，设计够巧妙，配置够简单，但它也有很多自己的不足（个人观点）。上一篇博客站在JDStream使用的角度简单的比较了Spring、JBossMicroContainer、PicoContainer和JFox优缺点，决定采用PicoContainer作为JDStream的IOC容器。由于以前没有接触过Guice，今天看了些介绍后就Guice和PicoContainer做个比较，不足之处希望能得到各位大侠的指教。1、Guice有三种注入方式：Field、contructor和setter；PicoContainer同样也有这三种注入方式；2、Guice使用Inject注释根据业务接口来注入Bean，如此减少了XML配置的繁杂，同时又不像其它IOC的Annotation注入那样繁琐，任何Bean的注入只需@Inject即可。但对于一个业务接口有多个实现的情况，单凭接口并不能够定位到相应的Bean，Guice需要以下辅助配置来定位：A：通过在业务接口上添加@ImplementedBy注释来指定实现类；B：通过实现Module接口硬编码，将实现类绑定到接口，同时用自定义Annotation来作为分支标记或自定义一个字符串作为分支标记；C：可以在@Inject的下面用@Name来指定实现类；同时Guice还可以通过实现Provider接口来动态注入注入；而PicoContainer也可以通过@Inject注入，对于一个接口或超类多个子类的情况也是通过自定义Annotation来区分；3、其它方面PicoContainer有Bean的监视器、生命周期管理、Container父子级联等实现，Guice可能也有这方面的实现，没有做深入的研究。4、Guice有更多的注释，同时又分绑定作用域，这个和PicoContainer的父子级联比较相似，都是实现实例的分割，相当于全局变量和局部变量。而PicoContainer只有Inject、Bind、Cache三个注释，并且都不带参数；由上面的比较基本可以看出PicoContainer有点像Guice的精简版，它更多的是通过Container接口将功能暴露给使用者，在外层并没有做太多的封装，它比Guice更轻量，更适合嵌入其它容器框架。而Guice更适合独立作为一个轻量的IOC框架存在。另外从JDStream的需求来看PicoContainer也更适合被集成于其中，具体原因后面阐述。IOC容器的原理比较了上面两个IOC容器后再看IOC容器的原理：IOC容器其实就是将一个类拆分了后和需要注入的参数及配置的操作缓存起来，大部分的IOC容器都逃不出以下几步：1、根据配置文件找到类名称，用加载器加载；2、用反射从类中分离出Field,Constructor,Method,Annotation,Interface,SuperClass等等分类缓存；3、缓存需要注入的参数；4、根据配置文件配置的操作或其它程序的调用，用Constructor生成Object，注入参数，此实例或缓存，或不缓存，或用弱引用缓存；5、生命周期操作，Annotation操作；从原理上说IOC容器和JMX实现没有太大的区别，JMX其实也算是一种IOC容器。但从实现上来说IOC容器比JMX灵活的多，它不必考虑J2EE规范的限制，完全自由发挥，可以设计的如Spring般繁杂，也可以设计的如PicoContainer般小巧。它可以使自己管理的Bean更加POJO，不必再亲自去实现框架管理接口，而是由框架生成被管理Bean的子类或业务接口的实现类作为代理去实现管理接口，然后一切业务调用都从代理接口传入，再去完成被管理Bean的调用。Spring和EJB就是这样管理的。这中间可以注册监视器来监控Bean的任何状态变化，注册拦截器来监控外部对Bean的操作。IOC容器给人的最大好处就是灵活多变，耦合松散，但这样的结果也是有代价的，首先越灵活配置越复杂，大量的XML和Annotation也会成为灾难，其次大量的动态代理、反射、CGLIB、拦截器、监视器等管理手段的使用，极大的降低了效率，对高并发环境下的应用是不可以接受的。JDStream的一个最重要的设计准则是在高并发通路上尽量避免使用以反射为基础的操作，以此来提高效率。由于JDStream偏向于高并发处理能力的需要，对上面的优缺点做了平衡，那就是插件的入口Bean类和插件内部的某些Bean类（需要对其管理但又不在高并发通路上的）以及业务程序里面的一些Bean类（同样需要对其管理但又不在高并发通路上的）使用IOC容器管理，需要对配置文件热修改以及对内部监控提供视图的Bean类用JMX容器管理，其它的Bean类并不提供框架管理功能。JDStream的IOC容器实现现在说说为什么PicoContainer更适合JDStream。首先JDStream的IOC容器最主要的职责是管理插件入口的Bean类，这些Bean的相互依赖不多，而且都肩负着插件配置参数的输入（如IP地址、端口号等），这些参数在部署后要经常修改，不可能采用Annotation注入，也不可能硬编码注入，只能用XML注入，所以Guice的Annotation就用不上了；其次JDStream的另一个职责是管理业务模块的一些Bean，这些Bean上面将标注属于JDStream自己的Annotation，这些Annotation的解析应该放在Bean的注册过程中，因此扩充PicoContainer更好一点；再次Guice管理的Bean基本上都要实现接口，这点和框