中间件多版本冲突的4种解决方案和我们的选择

背景

在小小的公司里面，挖呀挖呀挖。最近又挖到坑里去了。一个稳定运行多年的应用，需要在里面支持多个版本的中间件客户端；而多个版本的客户端在一个应用里运行时会有同名类冲突的矛盾。在经过询问chatGPT，百度，google，github，和各位大佬的文章后，进行了总结。大概有以下几种解决方案

业界方案1----更改类路径

低版本客户端，更改类路径；然后重新打包编译客户端；这样不同版本客户端，使用的类名就不同了

此解决方案
优点

1、适合简单的小项目：无需编写新代码

2、可能是最快的一种方式；只需要把代码下载下来；更改clients下的类路径，重新编译即可；属于不怎么费脑力，但有点费体力的方式。

缺点

1、遇到版本升级，需要把步骤2的过程重新人肉再来一遍。这个比较的那啥。。。。。。

2、不同版本客户端，可能也会依赖不同版本的三方jar包。这个也是蛮棘手的

此种方式适合小项目或者外包等一锤子买卖

解决方案2 -----自定义ClassLoader

使用ClassLoader进行类的隔离；不同版本客户端和依赖三方包，用不同classLoader进行加载和隔离；完全杜绝版本问题

此解决方案

1、属于自研；对ClassLoader的类加载机制需要有一定的了解

解决方案3------业界开源方案 sofa-ark

sofa-ark是动态热部署和类隔离框架，由蚂蚁集团开源贡献。主要提供应用模块的动态热部署和类隔离能力

提供功能：

1、包冲突的解决（能解决现有项目遇到的多版本问题）

2、合并部署：多个项目分工程开发，但可以合并部署；还支持静态合并部署和动态合并部署

资料传送门：

github.com/sofastack/s…

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的机制还蛮熟