为什么 Hasor 的设计强调模块？

为什么80%的码农都做不了架构师？>>>   

    前段时间公司组织旅游再加上国庆放假，基本上一个月等同于懒散状态也就无心照料 Blog ，今天算是打起精神继续写这一系列博文把，欢迎大家继续板砖。这篇是承接《轻量级 Java 开发框架 设计》系列Blog文的后续文章。

    提起 Java 开发框架，我想在座的一定会在脑海里第一时间跳出 Spring JFinal 之类的成型产品。所以我也不在多说废话了。

    在上一篇文章中提到了一些有关这个框架的设计要求，在这里顺便在详细说一说。其中绿色字体标出了我们公司的框架变迁。而 “Hasor” 是以我们公司框架为雏形进行重新设计的。

    首先 “Hasor” 这款框架的定位是比较宽泛的，它不光可以用在 Web 上开发，而且可以用在 非Web 应用程序开发。 “Hasor” 的设计原型是原于公司的内部核心架构体系，同时加上了许多通用化的改良才得以成型。否则也难得称得上通用化。它的设计也是经历了多个版本搬迁才得来现在的面目，现在回想起来差不多也有个把年头了。而目前我们公司的新架构体系也与 “Hasor” 的主体结构相当。正因为如此，我觉得 “Hasor” 的架构应该还算是比较成熟稳定的，应该是经得起考验的。

    一个架构设计必然有孕育它的历史背景，同时也有它的适用场景。下面就来将讲一讲我们的血泪史：

    在我刚刚加入目前这家公司的时候开发还比较传统，多个人之间协同开发仅仅靠着维护 Svn共同签出的同一个项目。开发人员彼此之间很容易受到对方不完整的递交而受到影响，不过这在当时都是小事。

    不仅如此，在这个项目中每个开发人员都负责了一个方面的业务，而这些业务有时会被独立的方式部署出去、有时会以打包连同其它业务程序一同打包部署。而在当时要想拿出一个完整的业务平台需要所有开发人员在完成手中任务之后，等待统一部署才在继续接下来的开发任务。而这在当时是不可能的，谁要想得到一个稳定版本那是痴人说梦。

    这时候我们的系统架构只需要包含（Action、Ioc、Aop、Freemarker、JDBC）即可支撑整个开发。在当时我们维护者一个自己的微框架，这个框架可以说比先下流行的任何开源框架都要轻量级。不过它可以支撑我们的所有开发需求。

    随着业务规模不断增大，重复打包部署。由于重复打包而引发的反复修改同一个 Bug 的现象开始大面积出现。传统的开发方式貌似已经无法承载目前的开发需要了。因此将一个项目拆解成多个小项目变得非常重要。

    接着我们决定按照业务模块对老旧项目进行分解，通过建立不同的子项目来容纳不同业务的代码。彼此在通过项目关联的方式来引用对方资源。这样一来至少我们可以出一个稳定版本供测试人员测试了。同时通过更新依赖也可以避免反复修改同一个以解决的 Bug 问题。

   但是我们又遇到了另外一个问题，被拆解的项目不能以独立 Web 应用的方式存在。如果分离出来的业务程序独立成为 Web 应用，将会导致整个业务系统分崩离奇，无法成为一整个业务平台。而我们的业务模块往往可能 “独立部署” 也可能 “同其它业务系统联合部署”。

    于是我们的应用程序架构需要变得与业务程序一点关系都没有，并且要在运行时自动感知已经存在的业务模块。并且去处理这个模块。就在这个时期架构体系中第一次出现了 “业务模块” 这一概念。

    虽然具备了 “业务模块” 这个概念，但是在核心框架中并没有产生多大的影响。无外乎在扫描类路径时多扫描了几个Jar包、在加载 Xml 文件内容时多扫描几个 Jar 包中相同的配置文件而已。架构本质并没有太大变化。

    此时我们利用 Maven 做项目管理，它可以很好的帮助我们解决 “业务模块” 依赖问题。并且可以有效的帮助我们选择。与其相匹配的运行业务平台。而这一切都只需要在最终部署项目上的pom里添加几个依赖即可。比方说要部署 “A B C” 三个业务系统，这三个业务系统选用1.0版本业务平台，然后将这个部署项目打成 war 包即可。

    到了这个时候我们的很多问题算是得到了根本性的解决。这也为后面架构架构大优化做了很好的铺垫。很多的时日里开发上几乎没有遇到太多的问题，业务继续增长。在这期间偶尔还有裁剪掉的业务系统也不会影响到整个开发。

    但是突然有一天，来了一个全新的系统开发需求。面对这个全新系统，我们需要从已有的框架技术储备中摘取需要的部分组成一个新的业务平台。而这一过程又变得比较痛苦。这好比于你一砖一瓦的构建了一个 “帝国大厦” 但是现在让你使用已有技术构将另外一个 “双子塔”。

    光抱着一个业务平台去开发已经不能满足我们的需要，这时候我们又面临 “如何快速构建开发框架，并且可以从方便的从已有技术储备中移植技术” 这样的问题。

    由于在这个时期我们已经积累了大量工具模块（Xml常量字典、权限访问控制、业务日志、缓存拦截器、类路径资源加载、页面装饰器、通用权限管理系统、消息、任务、规则引擎、Socket等等。。。）这其中有很多是和业务有关也有很多是纯技术性的，但是无论如何将这些模块从一个业务平台搬到另外一个业务平台就变得不那么顺心。

    通常拷贝一段代码并不能完成功能的迁移，而拷贝过来的代码还需要很多整合性的代码才可以在新的业务平台中使用。为此我们的架构开始尝试设计一种插件机制让这些模块可以有机的结合起来，方便搭建新平台。到这里这才有了框架的第二次改造。也就是后来的 “Hasor” 雏形。

    我一直觉得 Spring、OSGi 这两款框架是非常优秀的，并且不断的学习它们。虽然我实际使用它们的次数并不多，但是也不能阻止我从这两位前辈身上挖掘点有价值的东西。

    考虑到 非Web 环境兼容 和 轻量化设计，最终选定 Spring 作为参考原型。将我们已有的框架进行二次升级改造。

    至于为什么没有直接选用 Spring 作为技术选型主要还是从以下三个方面考虑：
1）延续原有技术形态，避免较大的技术变迁。
2）Spring 及其相关组件的异常堆栈是在深长，不敢恭维。
3）对于 Spring 很难切入改造使其架构融合到我们的架构中，这会迫试我们已有架构体系发生巨大变化。

--------------------------------------------------------------------

    在新的框架中，设计了专门的模块接口。应用程序在启动时会拜访这些接口的特定方法。这样有助于不同模块的初始化启动需要。此外模块在正式启动之前还有一个排序的过程，以保证模块之间正确的启动顺序。

    参考了 Spring Context 的设计我们基于 模块 接口为所有模块设计了从初始化到销毁的整个生命周期，并且通过一个 Context 接口去管理它们。

    同样的，作为 Java 应用轻量级开发核心 Ioc/Aop 是必不可少的利器。这两个支持方面我们我们继续沿用 Guice 3.0 作为 DI 支持。使用 Guice 的好处是开发灵活性高，可以方便架构的设计。并且 Guice可以说是污染率极低的一款 DI 容器，这要比 Spring 强太多了。

    虽然，网上流传各种版本不需要配置文件的框架。但是在实际开发中经验告诉我们，这是不可能的。就好比没有哪个用到数据的应用程序不需要配置数据库连接的。因此我设计了一款轻量化读取 Xml 配置的工具（Settings），通过这个工具解析自定义配置文件不需要写任何 Xml 解析器。

    在业务开发中我们经常遇到一组业务的处理要牵扯到好多类，而对于这些类和其入口程序之间通常耦合度非常高。为此设计了 同步事件/异步事件 的机制来为业务与业务之间进行解耦。

    由于 Guice 3.0 并不像 Spring 那样为每一个 Bean 都要求有一个 ID。因此当需要延迟 创建不确定类型对象 的时候，我们可以通过 名称创建 Bean对象。这个设计是源于 Spring 。

    等等不在一一述说....

----------------------------------------------------------------
目前的开发代码存放于（包括Demo程序）：
    Github：    https://github.com/zycgit/hasor
    git@OSC： http://git.oschina.net/zycgit/hasor

非常感谢您百忙之中抽出时间来看这一系博文。可以通过Maven 中央仓库网站  http://search.maven.org/ 搜索 Hasor 下载 hasor 的相关代码。

转载于:https://my.oschina.net/ta8210/blog/173266