一个应用为什么要拆成多个jar包,并且包要有版本?
都说应用大了就要拆,有人建议拆成多个应用并构成分布式系统,有人建议维持一个应用但拆成多个包(指jar包,不是package);本文讨论的是后一种分拆法。
?
下面从多个方面来讲述分包的好处。我将主要使用“反证法”,论述大应用如果不分包可能导致的后果,反过来证明分包的合法性。 本文的观点和论据大部分来自于Robert C. Martin的《敏捷软件开发》,有兴趣的朋友可以细阅这本书的第20章-“包的设计原则”
?
?
从软件开发的多个方面看待分包问题:
?
?
系统的可理解性
?
?? 分包可以提供模块化的视图,帮助了解系统的组织结构
?? 如果一个大公司没有分部门,你是不是很难说出这家公司哪些人有哪些职能? 如果一个系统的java代码都堆在一起,你是不是也很难说清这个系统大概有哪几块??如果系统的结构不清晰,对大家理解系统、系统架构的未来规划都有很大的坏处。
?? 而系统分包就是系统模块化的过程;结合包依赖图,可以帮助了解系统的组成部分以及模块之间的依赖关系
?
编译
?
???a. 分包可以避免一次编译所有代码,减少编译时间
?
???如果代码不分包,则意味着每次编译都要编译整个应用;对于一个大的应用,这个编译时间会很长;如果应用是c/c++写的,这个编译时间可能会达到无可容忍的地步。
?? 分包之后,大部分代码已经编译掉、作为jar文件引入了,此时你要编译的代码只是你正在改的那一小部分。这种情况下,编译时间可大大缩短。
?
?? b. 分包后,服务提供者的接口变更不会立即导致消费者代码编译失败
?
?? 如果代码不分包,且大家都在同一份代码库里开发,会有这样一种场景:A写完FooService准备提交时,发现它依赖的BarService已经被删掉了! 这时A就没办法提交代码了。如果A是一个冒进的人,他在提交之前不会更新代码库,而是直接提交FooService,然后下班;比他下班晚的人如果签出最新代码,就会发现代码无法编译。
?
?? 如果大家各搞一个私有分支,可以避免这种问题;大家在各自的分支里进行开发,最后再合到一起。但最后合并的工作量可能很多,因为要解决的代码冲突可能会很多或者很难搞,上面说的BarService被删掉的问题就很难搞;应用越大,这种冲突的概率就越高。
?
?? 把应用拆成带版本的jar包可以解决这个问题:把BarService放到bar-1.0.jar里,FooService依赖bar-1.0.jar. 如果BarService被删掉,删它的人会打出一个bar-1.1.jar; FooService则仍然使用bar-1.0.jar,不会出现编译问题。
?
3.代码的正确性
?
?? 分包后,服务消费者不必使用服务提供者的最新版本,避免出现未经验证的代码组合
?
?? 如果大家都在同一份代码库里开发,A写完FooService自测并提交,然后B把它依赖的BarService改掉,FooService和新的BarService共同运行时可能就会导致错误的结果,因为对于这个Foo+Bar组合,还没人测过。
?
?? 把应用拆成带版本的jar包可以解决这个问题:把BarService放到bar-1.0.jar里,FooService依赖bar-1.0.jar. 如果BarService被修改,修改它的人会打出一个bar-1.1.jar; FooService依赖的仍然是bar-1.0.jar,不会出错。
?
4.代码的安全性?
?
??分包后,每个包独占一个代码库,方便用作权限控制的单位
??有些代码只准某些人修改,这种控制一般要依托版本控制系统(VCS)实现。 如果整个应用的代码都放一起,想对某部分代码做权限控制,意味着要对代码库里的某些子目录进行权限控制,VCS在这方面的支持往往不好,或者配置起来不那么简单。把应用拆成多个jar包后,每个jar包的代码库对VCS来说都是一个独立的代码库,这时再做权限控制会容易的多。
?
5.架构
?
??分包体现了防卫性设计,可以保证层次之间及模块之间的单向依赖
?
? 如果整个应用的代码都放在一起,难保不会有人用DAO调Service, Service调Servlet; 也难保不会有人让一个基础应用调用一个易变应用,比如UserService里调用GoVocationBiz
?
??把代码分成包后,通过maven/ivy等包际依赖管理工具,可以明确定义好包之间的依赖关系,避免上述事情发生; 如果开发者试图让user-service.jar依赖了vocation-biz.jar,他会在review时被阻止,因为这种级别的代码变动往往需要团队里的资深成员介入review
?
6.项目进度
?
? 分包后,服务提供者的升级项目和消费者的升级项目可以错开进行
? 整个应用的代码放在一起时,如果BarService的接口改了,依赖它的FooService也得跟着改;当BarService发布时,FooService也得跟着发布,即使FooService团队正在忙于其它的项目,也不得不抽出时间内重构FooService并盯着它和BarService一起发布; 如若不然,则BarService只好搁置自己的升级计划。
?
? 有的团队会把BarService打成包(出于防卫性设计考虑),却不使用版本机制;在这种情况下,FooService总是使用BarService的唯一版本,也就是BarService的最新版本,此时,进度捆绑问题仍会发生。
?
? 如果把代码分包并引入版本机制,当BarService升级后,FooService仍可以使用老的BarService版本继续运行;等FooService团队有空了,再另开项目使FooService适应BarService的新版本。 BarService的升级项目和FooService的升级可以分开做