背景
在小小的公司里面,挖呀挖呀挖。最近又挖到坑里去了。一个稳定运行多年的应用,需要在里面支持多个版本的中间件客户端;而多个版本的客户端在一个应用里运行时会有同名类冲突的矛盾。在经过询问chatGPT,百度,google,github,和各位大佬的文章后,进行了总结。大概有以下几种解决方案
业界方案1----更改类路径
低版本客户端,更改类路径;然后重新打包编译客户端;这样不同版本客户端,使用的类名就不同了
此解决方案
优点
1、适合简单的小项目:无需编写新代码
2、可能是最快的一种方式;只需要把代码下载下来;更改clients下的类路径,重新编译即可;属于不怎么费脑力,但有点费体力的方式。
缺点
1、遇到版本升级,需要把步骤2的过程重新人肉再来一遍。这个比较的那啥。。。。。。
2、不同版本客户端,可能也会依赖不同版本的三方jar包。这个也是蛮棘手的
此种方式适合小项目或者外包等一锤子买卖
解决方案2 -----自定义ClassLoader
使用ClassLoader进行类的隔离;不同版本客户端和依赖三方包,用不同classLoader进行加载和隔离;完全杜绝版本问题
此解决方案
1、属于自研;对ClassLoader的类加载机制需要有一定的了解
解决方案3------业界开源方案 sofa-ark
sofa-ark是动态热部署和类隔离框架,由蚂蚁集团开源贡献。主要提供应用模块的动态热部署和类隔离能力
提供功能:
1、包冲突的解决(能解决现有项目遇到的多版本问题)
2、合并部署:多个项目分工程开发,但可以合并部署;还支持静态合并部署和动态合并部署
资料传送门:
www.sofastack.tech/projects/so…
此解决方案:
优点
1、功能强大不仅能执行类的隔离;还能静动态的热部署;还能进行插件的热插拔;能解决现有工程遇到的问题;文档也挺齐全的
2、性能,稳定性,易用性,应该是所有保障的,毕竟蚂蚁内部也在使用;
缺点
1、虽号称是轻量级,但那是和OSGI这种重型框架相比,在sofa-ark里,也还有蛮多概念比如:Ark Container,ark包,插件包,biz包;如何打ark包,如何打插件包等等;有一定的学习成本,好在文档齐全能降低一定的入门门槛
2、需要对现有工程进行改造,以符合sofa-ark的规范;打包和部署上还需要遵循其规范。对于小公司主打的就是一个“自由”这种状态来说;有一点点束缚和被迫学习了,因为我们都比较的“懒”
此种方式适合大型项目;大型项目开发人员和开发应用众多;而sofa-ark制定了相应的biz包和插件包的开发规范;在代码复杂性,模块化开发,扩展性,项目维护,应用运行期等都进行了综合考虑。
解决方案4------OSGI
属于比较重型解决方案
OSGI 作为业内最出名的类隔离框架,自然是可以被用于解决上述包冲突问题,但是 OSGI 框架太过臃肿,功能繁杂。为了解决包冲突问题,引入 OSGI 框架,有牛刀杀鸡之嫌,反而使工程变得更加复杂,不利于开发。
我们的选择
解决方案这么多,我们该选择哪个方案了?
我们选择方案2。为什么了?
先说说为什么不选择其它方案
方案1: 此种方式不一定是最快的方式;因为后续考虑到每增加一个版本,或者社区有更新,都要去做一次,更名,打包等。还是挺麻烦,不太自动化,属于不费脑子费体力。
方案3: 功能强大:在模块化开发,类隔离,热部署等功能性上无比优异;性能和稳定性也有大公司在背书;但我们目前是个小公司,遇到的业务场景和技术场景,没有那么复杂,强大的功能给我们,我们不一定能用的上,用的不好可能还会被反噬;由于公司技术人员对该框架缺少实际使用经验;并且对该框架的实现原理也没人懂属于需要现学;使用后万一后续出现什么问题,问题定位和维护也挺麻烦;对小公司来说还是“太重”了;并且还需要对现有工程进行改造
方案4: 就不用在详说了,比方案3还重的解决方案
为什么方案2适合我们?
实现难度上: 对我们小公司来说虽然要自己写代码实现;但经过评估大概几百行代码就能搞定,技术上不是那么的高不可攀;
技术熟悉度: 团队内大家对ClassLoader的机制还蛮熟悉