背景

使用了Gitlab CICD+Docker+K8s的方式来打包构建项目，由于组员反馈，项目打包构建速度过慢，再加上服务过多，导致影响了测试服的发布效率，考虑到测试服每天要进行几百上千个流水线操作，每个流水线平均耗时可能都要6min以上，大大的浪费了开发/测试的验证时间，故下达了一个优化打包的额外需求分配给组员完成，期限一周，一周将至，看着组员最终硬着头皮和我说没搞定，我有点懵，询问它这个地方有什么难度吗？组员：我搞了一个私服，但好像并不能提升打包构建的速度... 当然他是利用额外工作时间去搞的，我也不能责怪于他，只能亲自手把手教他优化。

组员优化过程

1. 实际目标:优化打包效率，组员理解目标:优化打包效率=搭建私服
2. 私服调研：采用nexus3
3. 根据教程在自己的机器上安装配置好后，开始准备部署测试服
4. 部署测试服过程发现需要创建容器，组员没有实操使用过，又研究了一下如果在k8s上创建容器
5. 创建时遇到了问题，我当时顺手指导了一下，完成容器创建，测试服可正常使用Nexus私服
6. 使用了Nexus私服，配置了所谓的阿里云，华为云等加速镜像，却发现打包构建速度对比以往甚至更慢了
7. 组员一脸懵逼，最终无奈告知我无法完成

优化失败原因分析

nexus的仓库类型主要有三种，hosted/proxy/group

• hosted:本地存储/本地私库
• proxy:代理仓库，可以配置其他仓库的代理
• group:组合仓库，组合多种类型仓库提供服务

组员在maven的settings.xml文件中，配置了group仓库，策略是 hosted>proxy,但是发现hosted私库中并未上传对应的依赖包，则意味着每次都会走代理仓库，如果这样那还不如不走私服直接走对应代理仓库的地址下载依赖不就好了？

开始接手优化

打包流程分析

由流程图可知，主要打包部署流程拉取镜像>执行打包脚本>下载依赖

Gitlab打包log耗时分析

Build总时长非常夸张

继续往翻日志发现，竟然要build 54个project？？？

dockerfile文件分析

FROM xxxxx/common-images/maven:3.8.4-jdk-8 AS builder
copy ..

这两行行命令拉取maven公共镜像并Copy到本地根据log发现耗时也花费了一分钟

mvn -f ./ clean install -U -DsipTests

这行命令把所有的依赖包都install了，我们项目所有的project依赖有54个，每个project下面又有对应的pom依赖...

优化切入思路

1. 在Docker拉取镜像的镜像层做一层Cache
2. mvn install的方式必须改变install的范围，不能一股脑把所有依赖都install
3. mvn install是否支持多线程并发install？
4. 拉取依赖速度慢可能是由于公共仓库和本身带宽限制所致，不可改变外因，能否提升内因？加带宽？有无加的必要
5. mvn 拉取依赖是否是多线程的？能否让其改成多线程拉取依赖？
6. 能否将Nexus私服服务器与打包服务器放在同一网络机房，走内网？

优化过程

1. 多线程拉取依赖

配置 maven.artifact.threads 属性，可以使用多个线程并行执行解析操作，这有助于提高构建性能，特别是在处理具有大量依赖项的项目时。

将 maven.artifact.threads 属性设置为较高的值并不总是意味着会获得更好的性能。适当的线程数取决于系统资源和项目的特性，可以根据自己的实际情况进行调整。

2.只构建特定项目和模块

我们都知道在微服务中,不同微服务之间有很多相互的api依赖,rpc依赖,sdk依赖等，我们当然不会手动一个个依赖去按照严格顺序构建，使用maven工具的 -pl命令可以帮助我们构建当前项目所需的所有依赖项

mvn -pl <module-identifier-1>,<module-identifier-2>,...

3.多线程构建

在 Maven 中，-T 是一个用于指定并行构建的命令选项。

使用 -T 选项，您可以控制 Maven 在构建过程中并行执行的线程数。这对于大型项目或具有大量模块的项目可以提高构建性能。

mvn -T <thread-count> ...

我们来看下修改优化后的dockerfile

4.加带宽能否提升速度？

我们目前开启了多线程去拉取外部依赖，是否会受到打包服务器自身的带宽影响呢？猜测是没用的，我们看下打包服务器的带宽使用情况

我们打包服务器的峰值带宽是10M,可以看到在上班时间频繁的打包构建操作带宽也在频繁的波动， 但多数时候并未超过带宽峰值，而出现超过峰值的情况大概率是因为我们单个服务内加了多线程拉取依赖，而多个服务同时构建的情况下必然是倍数增长，只能说加了带宽可能会提升在多个服务一起打包的情况下的速度，但目前来看并不是一个瓶颈，秉承着降本增效的理念，不决定加！

优化结果

原打包耗时

优化后耗时

总结

1. 此次优化组员未完成有一半是因为我的问题，与其目标对齐不一致所致
2. 组员分析解决问题思路存在问题，需要其自我反思和总结
3. 还可考虑再将pom.xml中的不常变动依赖打包成镜像，每次打包时先拉取镜像再一次性install,预计速度还能提升50%以上