酝酿已久的 Hasor2
酝酿已久的 Hasor2
哈库纳 发表于4年前
酝酿已久的 Hasor2
  • 发表于 4年前
  • 阅读 353
  • 收藏 1
  • 点赞 0
  • 评论 13

标题:腾讯云 新注册用户域名抢购1元起>>>   

    自从2014年1月份更新了一个版本之后,Hasor的更新一直处于沉静状态。这段时间内因为工作变动、搬家等原因。导致Hasor的更新变慢了。 尽管这样,Hasor仍然在进行开发。新版Hasor,暂定名为 Hasor2。新版本变化非常大。

一、Hasor不再强制依赖Guice

    虽然Guice作为Hasor的默认DI引擎非常理想,但是Guice和Spring之间的协调变并不是很容易。在Hasor 1 中 Hasor提供了Bean注册机制,这个机制会交给位于更下层的Guice。正因为这样Spring作为一个独立的Bean容器其实是很难与Hasor融为一体。这也就使得Spring与Hasor的整合只能趋向于表面。

    于是新版的Hasor内部构建了一套全新的 Bean 绑定机制,通过这套机制Hasor有了自己的Bean注册API。所有注册的Bean信息最后都会通过 RegisterInfo 接口进行描述。新版Hasor正是通过这一点完成了不再强制依赖Guice的美好愿望。

    Hasor为什么前后这么纠结?

    Hasor 的架构其实是我在前任公司里做过的一个基础框架的开源实现。两套架构有很多相似的地方,但是完全不一样。同时Hasor也是为了技术练手开发的一个框架。

    开源之后,来自OSC的朋友问道,如何与Spring集成?其实从一开始来说Hasor并没有打算支持Spring。但是如果作为开源软件独立发展的话,Spring已经集成了众多优秀的框架。如果Hasor失去Spring,将意味着Hasor的生态圈变得非常狭窄因此Hasor开始在接下来的新版中尝试剥离Guice。不再强依赖某一个技术框架,Hasor还是尝试拥抱更多的选择。

二、Hasor2 弱化了模块概念,强调插件

    在Hasor1中Hasor还是十分强调(模块、组件化、生命周期、模块依赖)这些概念。从新版Hasor开始将不再强调这些概念,转而支持插件化。

    原因1(学习曲线陡峭):在Hasor1中Hasor的扩展功能是以模块形式通过Module接口组织进入的,Module接口给出了init、start、stop三个方法。这三个方法分别对应了模块的三个生命周期。因为Hasor1强调模块开发,所以开发者在使用Hasor的时候除了要理解Hasor模块声明周期之外,还要了解Hasor依赖体系。这样一来开发Hasor的扩展功能的学习曲线比较大的。

    原因2(不实用):作为Hasor的作者,在开发Hasor模块过程中我发现其实扩展Hasor主要还是围绕在Hasor的init阶段。start、stop两个阶段的设计基本是没什么用的。

    于是便有了HasorPlugin接口,通过HasorPlugin开始简化Hasor模块的开发。到最后Hasor发展了14个内置插件,也都是通过HasorPlugin接口完成的,跟Module几乎没什么关系。这样一来原本设计的(模块体系、生命周期)最后通过简化的Plugin体系完全取缔了。

三、Hasor的目标重新定位

    最初打造Hasor的目的是想创造基础Java开发框架,这个框架上可以安装各种不同的功能模块。每个模块提供了不同的功能,通过这些这些功能组成一个适用于项目的开发环境。

    但是由于先天Hasor采用了模块化的概念进来,导致Hasor很多扩展都要围绕着模块进行,而这个模块概念又泛生出(依赖、生命周期)这样重量级的东西。因此很多朋友会直接联想起 OSGi。虽然Hasor已经力争与OSGi划清界限。但是依然有着重量级的影子在里面(虽然经过实践证明Module是一个鸡肋....)。

    Hasor还曾经试图打造一个容器框架。为这个远景而大力发展 Hasor的模块概念,通过加入ClassLoader等机制来完善 Hasor 本不完善的 Moduel。这样一来 Hasor 从预期上更加趋向 OSGi。如果继续发展下去,Hasor 的价值就被做掉了。

    Hasor2 开始放弃 Module,拥抱插件。重新回归轻量化基础框架行列。使用Hasor2,可以用过插件扩展期功能正如Hasor在一开始提到的“微内核+扩展”。

四、不再打造大平台

    其实Hasor的先前版本有一个特性就是任何一个基础组建包都会携带一大堆内置插件。这样的设计初衷是提供一个完备的基础环境,开发者引用了 Hasor 之后很多功能都可以通过 Hasor 直接提供。

    这样的想法本身就是有问题的,在实际开发中很难提供一个高度完备的开发环境。如果真的做到了会由于集成了太多东西而变得笨重,失去了轻量化、高灵活性的特征。

    新版Hasor扭转这种想法,只提供一个最轻量级的内核,所有扩展插件将会被全部被剥离出去。

五、更加透明、灵活

    Hasor 1 之前 Hasor 通过注解化的方式提供了很多便捷的插件,注解在Hasor1中是一个核心元素。推行注解化开发会给开发这带来很大的灵活性,但是由于注解的支持已经被深深植入Hasor内部。这样一来Hasor对于开发者相当于一个黑盒。使用Hasor提供的API虽然可以提供各种有用的插件,但是并不能帮助同学了解工作原理。这也就导致Hasor框架的可制定性大打折扣。

    Hasor2开始,只提供核心接口方法,内置插件将被剥离出去,成为Quice项目。如果有需要快速开发的同学可以直接使用这个项目来快速开发从而省去制定的麻烦。这样一来可以让更多同学可以对 Hasor 做出更多特色的制定,从而满足不同的业务场景需要。

标签: Hasor 新版
共有 人打赏支持
哈库纳
粉丝 929
博文 81
码字总数 149803
作品 4
评论 (13)
路小磊
不再打造大平台,非常赞同这样的想法。毕竟大平台会让框架越来越庞大复杂,而且封闭。
哈库纳

引用来自“路小磊”的评论

不再打造大平台,非常赞同这样的想法。毕竟大平台会让框架越来越庞大复杂,而且封闭。
是的,做框架如果不开放会把自己做死。提供一个开放的生态圈系统很重要。
狂暴的蜗牛君
我还没有看过1 所以不知道你怎么管理插件的
我的猜想是 一个插件就是一个jar包 一个统一的模块去加载卸载这些jar包
我说的对么?我自己尝试写了一个
http://git.oschina.net/zengweigang/plugin-server.git
望指点
狂暴的蜗牛君
有三个模块目前
一个core 这个就不用说了
还有一个plugins 下面就是一些模块
server 这个就是负责启动管理这个plugin的
哈库纳

引用来自“蜗牛君”的评论

我还没有看过1 所以不知道你怎么管理插件的
我的猜想是 一个插件就是一个jar包 一个统一的模块去加载卸载这些jar包
我说的对么?我自己尝试写了一个
http://git.oschina.net/zengweigang/plugin-server.git
望指点
指点算不上啦,互相交流下 在 Hasor 里插件是通过接口表现的,一个Jar包中可以有多个插件,要想Hasor自动加载插件只需要配置一个注解就可以。 思路上是一样的。 在设计Hasor2时候曾经想过用ClassLoader去装载模块,后来决定轻量化就放弃了这个想法。 不知道你有没有想过,如果已经装载的插件一旦被使用可能卸载不干净的问题。如果在重新装载会不会引发冲突?
哈库纳

引用来自“蜗牛君”的评论

有三个模块目前
一个core 这个就不用说了
还有一个plugins 下面就是一些模块
server 这个就是负责启动管理这个plugin的
plugin-server 项目已经关注了, 你也是采用的 Guice 呀。 Hasor 在 1 里面也是用的 Guice 。 Guice 确实是个好东西。
狂暴的蜗牛君

引用来自“蜗牛君”的评论

我还没有看过1 所以不知道你怎么管理插件的
我的猜想是 一个插件就是一个jar包 一个统一的模块去加载卸载这些jar包
我说的对么?我自己尝试写了一个
http://git.oschina.net/zengweigang/plugin-server.git
望指点

引用来自“哈库纳”的评论

指点算不上啦,互相交流下 在 Hasor 里插件是通过接口表现的,一个Jar包中可以有多个插件,要想Hasor自动加载插件只需要配置一个注解就可以。 思路上是一样的。 在设计Hasor2时候曾经想过用ClassLoader去装载模块,后来决定轻量化就放弃了这个想法。 不知道你有没有想过,如果已经装载的插件一旦被使用可能卸载不干净的问题。如果在重新装载会不会引发冲突?
各个插件(jar)之间完全独立,不存在互相引用。如果A插件需要B插件提供服务 B插件可以提供一个http的接口作为服务。如果这样的话 不知道会不会出现卸载不干净的问题。 我卸载jar包的方式是: JarURLConnection url =加载jar的时候的url对象; url.getJarFile().close(); 如果你要卸载一个插件 你是怎么做的呢?因为你一个jar里面有多个插件 肯定是不能卸载jar的,而且各个插件之间又有相互引用。
狂暴的蜗牛君

引用来自“蜗牛君”的评论

我还没有看过1 所以不知道你怎么管理插件的
我的猜想是 一个插件就是一个jar包 一个统一的模块去加载卸载这些jar包
我说的对么?我自己尝试写了一个
http://git.oschina.net/zengweigang/plugin-server.git
望指点

引用来自“哈库纳”的评论

指点算不上啦,互相交流下 在 Hasor 里插件是通过接口表现的,一个Jar包中可以有多个插件,要想Hasor自动加载插件只需要配置一个注解就可以。 思路上是一样的。 在设计Hasor2时候曾经想过用ClassLoader去装载模块,后来决定轻量化就放弃了这个想法。 不知道你有没有想过,如果已经装载的插件一旦被使用可能卸载不干净的问题。如果在重新装载会不会引发冲突?
我卸载一个插件=卸载一个jar包
狂暴的蜗牛君
一个插件我这边定义为一个业务单元 ,例如 用户管理和角色管理就是两个插件(jar),在生产环境中 可以在不重启整个服务端的前提下 更新某个插件 。这些只是脑子里面的想法 还有通过严谨验证^_^ 什么时候出新版 观摩观摩
哈库纳

引用来自“蜗牛君”的评论

我还没有看过1 所以不知道你怎么管理插件的
我的猜想是 一个插件就是一个jar包 一个统一的模块去加载卸载这些jar包
我说的对么?我自己尝试写了一个
http://git.oschina.net/zengweigang/plugin-server.git
望指点

引用来自“哈库纳”的评论

指点算不上啦,互相交流下 在 Hasor 里插件是通过接口表现的,一个Jar包中可以有多个插件,要想Hasor自动加载插件只需要配置一个注解就可以。 思路上是一样的。 在设计Hasor2时候曾经想过用ClassLoader去装载模块,后来决定轻量化就放弃了这个想法。 不知道你有没有想过,如果已经装载的插件一旦被使用可能卸载不干净的问题。如果在重新装载会不会引发冲突?

引用来自“蜗牛君”的评论

各个插件(jar)之间完全独立,不存在互相引用。如果A插件需要B插件提供服务 B插件可以提供一个http的接口作为服务。如果这样的话 不知道会不会出现卸载不干净的问题。 我卸载jar包的方式是: JarURLConnection url =加载jar的时候的url对象; url.getJarFile().close(); 如果你要卸载一个插件 你是怎么做的呢?因为你一个jar里面有多个插件 肯定是不能卸载jar的,而且各个插件之间又有相互引用。
是的卸载会有问题,所以我没有做卸载,只做了一个 start , stop 两个生命周期。其实即使jar之间完全隔离运行用 rpc 等方式互相调用,也不是很完美。毕竟类的 静态代码快可能还有一些已经打开的资源无法被回收。 采用 HTTP提供插件服务是一个办法,但是程序内部调用效率会遇到问题把?
哈库纳

引用来自“蜗牛君”的评论

一个插件我这边定义为一个业务单元 ,例如 用户管理和角色管理就是两个插件(jar),在生产环境中 可以在不重启整个服务端的前提下 更新某个插件 。这些只是脑子里面的想法 还有通过严谨验证^_^ 什么时候出新版 观摩观摩
方法是可行的,实际应用时候我遇到的情况是一般都是整体做更新部署。 所以后来在新版中干脆放弃这种思想了。 插件管理我想还是单独拿出来独立搞一个容器去做比较有针对性。
心灯
没有使用过,不过模块化是未来,通过模块化可以使用编程相对有保证些。
准备看看作者的源码,另OSGI有接触过一段时间,在WEB方面应用 起来还是不太习惯,基本上和之前的编程方式会有不同,另外就是OSGI的曲线太长,开发工具还是有些问题(使用过BND).可能这些都是借口,真正的还是自己没有深入进去。
哈库纳

引用来自“心灯”的评论

没有使用过,不过模块化是未来,通过模块化可以使用编程相对有保证些。
准备看看作者的源码,另OSGI有接触过一段时间,在WEB方面应用 起来还是不太习惯,基本上和之前的编程方式会有不同,另外就是OSGI的曲线太长,开发工具还是有些问题(使用过BND).可能这些都是借口,真正的还是自己没有深入进去。
Hasor2只是理想达到的一个目标,真正实现起来还需要进一步的验证。目前Hasor的最新版还在开发中...
×
哈库纳
如果觉得我的文章对您有用,请随意打赏。您的支持将鼓励我继续创作!
* 金额(元)
¥1 ¥5 ¥10 ¥20 其他金额
打赏人
留言
* 支付类型
微信扫码支付
打赏金额:
已支付成功
打赏金额: