Java依赖冲突高效解决之道(2)

发表于:2022-2-08 09:10

字体: | 上一篇 | 下一篇 | 我要投稿

 作者:阿里技术    来源:网络

#
Java
分享:
  四、通过maven调整依赖jar解决依赖冲突
  1.升降级jar包解决依赖冲突
  上一章节中的第一个例子中,最简单的情况,如果发生冲突的jar包高版本是完全兼容低版本功能的情况下,只需在pom中简单升级jar包版本即可。
  但如果冲突 jar包高版本不兼容低版本,且应用依赖不是很复杂的情况下,可以分析升级冲突jar包后会对哪些业务有影响,具体做法推荐通过IDEA Maven Helper 插件查找冲突jar包有哪些业务依赖(此处不推荐"mvn dependency:tree",目前本人见过的大部分Maven工程都有多个Module,比如*-dal,*-Service,*-Controller,这类工程结构如果module未单独打包上传Maven仓库,"mvn dependency:tree"是不能完整分析依赖关系的),记录下来。如下图所示:
  然后升级冲突包,通过回归测试受到影响的二方库对应的业务点。
  如果应用依赖非常复杂(例如冲突包有几十个二方库依赖,或者依赖冲突包的二方库是个基础包,业务系统中无法清晰枚举出使用受影响二方库的业务点),这种情况下,如果要通过升级jar包解决依赖冲突,必须完整回归整个应用功能。笔者有几次因为回归不全面引发故障的惨痛经历,希望大家不要重蹈覆辙。通过这几次事例,笔者深刻理解到我们这个时代最伟大的计算机科学家Dijkstra大神“简单是可靠的先决条件”这句至理名言,深深的体会到如果一个系统复杂到你完全无法理清楚他错综复杂的依赖关系的时候,那说明你该重构你的系统了,否则系统维护将会逐步变成噩梦。
  当然不是所有情况都可以通过升降级jar解决冲突,举个例子:
  如上图假设应用系统同时依赖A.jar,B.jar,而A.jar,B.jar都依赖protobuf-java,系统运行时都会分别用到A.jar,B.jar中protobuf部分的功能,而且A.jar,B.jar依赖的protobuf版本无法通过升高降低版本调整到一致。由于protobuf-java3.0版本序列化协议,类内容各方面都不兼容protobuf-java2.0版本。这种情况无论如何调整依赖都无法解决冲突的问题,要解决这种冲突,请继续往下看,第五第六章内容。
  2.排除jar包解决依赖冲突
  上一章节中第二个例子,主要原因是容器启动时加载到的类不是预期spring-beans-4.3.5.RELEASE.jar中的类,而是spring-2.5.6.SEC03.jar包中的类,如果spring-2.5.6.SEC03.jar排除对业务无影响,可以通过排除spring-2.5.6.SEC03.jar来解决冲突。与上一节例子类似,可以通过IDEA Maven Helper 插件确定spring-2.5.6.SEC03.jar是由哪个jar间接依赖进来的,判断业务的影响范围,此处不在赘述。与上一节一样,类似的情况不一定都可以用排除jar解决。
  五、通过pandora自定义插件解决依赖冲突
  第四章中有讲到,如果一个应用中要同时运行两个不兼容版本的jar包,是无法通过Maven调整依赖关系解决的。第二章讲解依赖冲突原理时有提到,Pandora通过类隔离机制实现了集团各个中间件之间的隔离,Pandroa同时也支持业务方按规范创建一个可以运行在Pandora容器中的插件,容器帮业务方实现加载隔离。
  联盟一淘团队就将类似IC、卡券这种核武器级存在的二方包根据自己业务的需要进行裁剪包装后,制作成Pandora插件来避免依赖冲突,取得了很好的效果。
  用Pandora插件确实能在不对应用做很大调整,不影响性能的情况下完美解决依赖冲突问题。
  但也有一些问题就不太适合用局部方法解决了,比如:
  当维护的应用依赖过于复杂,每个应用依赖外部三四十个二方库时。这种重量级应用就会严重影响生产效率。
  如上图所示,早期本人负责联盟用户平台时,就遇到两个巨无霸应用,adv(6w+代码)、pub(12w+代码)。
  一方面因为依赖多,基本每周都会遇到集团各种升级,安全问题,各种小修小补,不断的上线。一方面业务发布需求也较多。
  导致需要频繁发布,比如有一年个人就发布了566次。此时庞大的依赖导致部署效率,影响评估回归都会很难,此时就不应该从局部解决冲突这种视角去看,应该考虑优化应用架构,进行依赖治理,尽量避免冲突。
  六、通过依赖架构治理解决依赖冲突
  1.复杂依赖标准化、简化治理
  首先,依赖本身就是一种复杂的业务。大部分依赖背后都有较深的业务领域知识 或者 技术领域知识。
  比如我们查询搜索。
  业务领域知识方面,光销量就有交易成交笔数,成交件数,搜索销量【有些订单不计入搜索销量】等。
  技术领域知识方面,主搜索,联盟广告搜索引擎有时是配合使用的,比如商家未入驻广告前给商家展示货品信息就需要查主搜索,而入驻后投放下行时则需要用广告引擎。不同引擎的调用方法,结果都不一样。
  如下图所示,如果我们每个业务应用都各自实现,那么各应用开发同学就要消化大量搜索客户端相关的业务、技术领域知识。成本是很高的。
  面对这种情况,如果我们将这类复杂的依赖,由专人owner进行统一包装标准化【专人干专事】,会大大提升组织协同效率。如下图所示。
  我们通过对主搜索,联盟引擎的统一封装。对检索条件,返回结果的标准化封装。大大降低了同学们的接入成本,以往要熟悉一个引擎的接入大概要2天,用标准化封装后的wrapper,在专人,规范文档的指导下仅0.5天就可以,大大提升效率。
  2.重量级依赖代理服务化
  第五节中有讲到,应用依赖的jar包过多会导致应用启动很慢,因此如果一个依赖引入jar包超过30个以上时,务必要警惕,这种依赖引入几个,就会逐步导致你工作效率大大下降。比如IC,TP,优惠中心的二方包就是典型的例子。
  目前我们针对这类依赖,是直接封装一个标准代理服务,避免应用被这种巨无霸二方包拖慢。
  经过以上综合治理手段,取得了很好的效果。目前联盟很少再需要大家去解决冲突问题。

  本文内容不用于商业目的,如涉及知识产权问题,请权利人联系51Testing小编(021-64471599-8017),我们将立即处理
《2023软件测试行业现状调查报告》独家发布~

关注51Testing

联系我们

快捷面板 站点地图 联系我们 广告服务 关于我们 站长统计 发展历程

法律顾问:上海兰迪律师事务所 项棋律师
版权所有 上海博为峰软件技术股份有限公司 Copyright©51testing.com 2003-2024
投诉及意见反馈:webmaster@51testing.com; 业务联系:service@51testing.com 021-64471599-8017

沪ICP备05003035号

沪公网安备 31010102002173号