升级基础组件的升后感之项目依赖包

雨翔河

首页列表关于

升级基础组件的升后感之项目依赖包

2019-10-08 13:11

目前为止在这边总共升级过三次基础组件，第一次是kafka的客户端，全面涉及到的20+个项目全部升级，第二次是升级spring组件，也是所有项目升级，第三次是json组件升级。

在升级基础组建的过程中发现了一些很麻烦很严重的问题，项目的包依赖问题，因为每次基础组件升级需要涉及到20+个项目，可以说几乎都是‘微服务’，说‘微’其实也不‘微’，一个项目一百多M，启动要一分钟以上，本地启动需要2分钟以上，当然本地一次能不能启动就两说了。。。

我在这之前是没有在工作中用过spring的，所以对spring是很陌生，说来也很惭愧，SSM或者SSH三大框架都没在工作中用过，最早是公司自研的一套web框架，后来在小牛这边是在大数据部门接触多是多线程高并发问题和破解方面的技术问题，不过我在学生时代就听闻spring的大名已经很久了，一直没有机会接触。

现在这边用的spring还是比较老的版本，升级的时候真是痛苦，第一是我们用的spring的版本简直是乱，包依赖关系连我自己都屡不清。当然这种现象不仅仅是spring组件，其他组件也一样是这个情况，只是这个比较典型。

很多公司企业喜欢给应用戴上‘微服务’的帽子，就如同几千万的数据就敢称大数据。服务间互相调用是需要给对象提供接口包的，但是开发人员不注重的话会导致这种api类的包提供出去居然存在大量spring包的依赖在里面，明明一个微服务非常的小的应用，加上依赖打包出来能达到150M大小，且api类的包携带大量的中间件的jar包导致依赖关系十分复杂，在升级组件的时候需要各种 `execution`，还得考虑兼容性，简直是噩梦。

一个应用在开发的时候就应该管控好所有依赖包的质量，不仅仅是依赖包，包括所有的基础配置和基础组件的版本都应该管控好，当组件升级的时候可以很舒服的升级上去，不需要为了升级一个组件，改动多处的依赖关系。

项目间的依赖关系有时候很复杂，RPC互相调用的关系图，跟蜘蛛网差不多，当A项目依赖B项目的V1版本的包，假设B项目这个时候做了依赖变更或者接口代码层面的变更，但是没有变更版本号，这样会导致A项目打包好了仍测试环境之后莫名其妙的报错启动失败，这个问题发生了不止一次，影响面很广且难排查。在变更这种接口类的包时候一定要变更版本号，包问题没有解决好，出问题的时候坑的都会是自己人。

>  这让我想起大四那年玩nodejs，那版本升级的速度非常的快，每次更新的时候那一大堆依赖组件，简直就是噩梦，这可能是我不想玩nodejs的原因之一。

类型：工作标签：kafka,nodejs