WildFly的模块化系统

436 查看

WildFly,前身是JBoss AS,从V8开始为区别于JBoss EAP,更名为WildFly。Wildfly 8主要具备如下特性:

  • Java EE7的参考实现(2013年7月止尚未得到Java EE7兼容认证)
  • 启动速度更快,占用内存更少
  • 模块化(JSR294)设计
  • 统一配置管理
  • 分布式domain管理

本文主要讨论一下WildFly 8的模块化系统。

WildFly之所以启动很快,模块化组件jboss-modules功不可没。作为OSGi和Jigsaw(JSR 294 http://jcp.org/en/jsr/detail?id=294)“夹击”之下的衍生物,与jboss-msc成为WildFly的全新内核。

jboss-modules解决什么问题

JBoss Modules就是解决传统的层级机制的ClassLoader所带来的Jar Hell问题:

  1. JAR被加载后不使用导致资源浪费。

  2. 同名JAR包的不同版本混在导致依赖冲突。

JBoss Modules使所有的jar都打包成为模块,一个jar再也不会看到依赖中有版本冲突的类,或者加载到一个不需要加载的资源。同时,按需加载模块可以明显地提高大型应用的启动时间。

与Jigsaw(JSR 294)的关系

Jigsaw已经被延迟到Java SE 9。JBoss Modules会与JSR294兼容,如果Jigsaw项目能够稳定,并且成为OpenJDK的一部分,JBoss承诺将维护JBoss Modules的兼容性。

与OSGi的关系

个人认为是互补的关系,通过Jboss-modules进行模块化的应用服务器,使得OSGi的Bundle形式不再成为模块化的唯一方式,更加灵活。另外它更为小巧,没有OSGi的Sevice层,或者其他OSGI提供的更高层次的功能,它只做一件事情,就是模块化。

注:上图中的Subsystems没有列全,full-ha Profile的子系统如下图:

接下来简单与Oracle的Java EE 7的RI,GlassFish V4.0做一个简单的架构对比

笔者观点】GlassFish与WildFly在架构实现上最大区别在于模块系统的构成。

  • GlassFish的做法

    采用OSGi的模块化作为GlassFish的模块化系统/基盘;用HK2替代了OSGi的服务层。

  • WildFly的做法
    鉴于Jigsaw的难产,JBoss推出自己的模块化实现并作为WildFly的模块化系统/基盘;将JBoss MSC(Module Service Container)作为其服务容器。默认情况下将OSGi排除在WildFly系统栈之外(从8.0.0.Alpha3开始OSGi子系统已经从WildFly移除,今后将提供以add-on的形式与Wildfly集成。https://issues.jboss.org/browse/WFLY-1638),该点与GlassFish不同(GlassFish与OSGi运行时是紧耦合的)。

排除厂商利益因素,笔者更喜欢JBoss的设计,原因以下:

  1. 通过JBoss Modules将WildFly与OSGi解耦,并且兼容Jigsaw。设计上更为优雅,且更具远见。

  2. OSGi在Java EE开发领域并没有被广泛接受(如下图,来自于zeroturnaround),离真正落地尚需时日。JBoss的设计理念更贴近开发人员。

by 吴杰 via ifeve


2018 - 知识虫 - 我的知识库 渝ICP备16002641号-2

渝公网安备 50010702501581号