1
缘 起
Maven 作为程序员所熟悉的构建工具,在eBay内部同样被广泛使用。maven-resolver 是Maven的核心组件。它将项目声明的所有依赖 (dependency) 予以解析,算得依赖图 (dependency graph) 并调解冲突,最终整合成项目编译和部署所需的classpath,这个过程叫依赖解析 (dependency resolution)。在eBay开展的 Build Velocity 项目实践中,通过对Maven Build数据进行分解和可视化分析,我们惊讶地发现maven-resolver在解析复杂依赖时存在严重的性能瓶颈。
为突破瓶颈并加速Maven Build,我们对maven-resolver的依赖解析算法作了大幅改造,并实现了一个全新的算法: BF (广度优先遍历) + Skipper 。 其意义是Maven可以无视依赖图的复杂度,甚至有大量循环依赖的情况下,可通过最小运算量计算出项目所需的最终依赖项。经测试,该算法可以让依赖比较复杂的项目的纯build时间缩短 30-70% !
目前该算法已被Apache Maven社区正式接受并纳入maven-resolver v1.8.0 (该组件将随Maven 3.9.0发布)。以下使用说明来自 Maven官方文档:
新算法甫一亮相,来自阿里的开发人员便试用并给出了以下反馈:
目前我们已经应用到5 - 6个需要花长时间build的工程,build时间可以缩短一半,后续我们会把这个算法应用到更多的工程并及时反馈。
这个算法的诞生可谓历经艰辛。从发现问题、解决问题到贡献回社区,每一步都倾注了eBay Applciation Framework 团队的心血。
本文将以算法的起源和演进为轴线,为大家重温个中细节。
注:本文提及的测试数据均基于纯build,指本地Maven repository有full cache并跳过全部测试的情况下跑的Maven Build (mvn clean install -DskipTests),故不涉及任何Maven artifacts下载。
2
发 现
2021年3月,eBay启动Velocity项目,旨在加速开发迭代。 其子项目Build Velocity的设立旨在加速开发周期的重要一环:Maven Build。其前期共60+ pilot 项目参与。eBay Application Framework Team负责技术攻关。
摆在我们面前的问题有两点:一是缺乏数据,二是不清楚Maven Build具体慢在哪里。
工欲善其事,必先利其器。我们首先打造了 Zeus产品 。该产品以一个Maven Extension为核心,实时参与用户build,收集数据并汇总成报表。通过分析报表、诊断热点(hotspot)、开发特性(feature)以解决热点、Extension自我升级并启用特性、再用新收集的数据体现优化效果,至此形成一个可持续运行的调优闭环。
每条数据量化了Maven Build的各个步骤,并统计以下指标:
Zeus应用到上述pilot项目后,我们发现有一个项目跑一次纯build竟然需要 30+ 分钟才能完成。内存配置甚至需要 20G ,否则Maven Build会因内存溢出而终止。我们通过分析收集到的build数据,发现上述依赖解析部分时间(相当于跑一次mvn dependency:tree)几乎 等同于纯build时间 。 通过Zeus报表发现,有不少项目在依赖解析上花了不少时间 ( 5~10分钟 ),虽然没有上述项目严重,但至少说明Maven依赖解析慢是个共同的问题!
3
探 究
Maven 依赖解析过程简介
Maven 依赖的声明使用大家都很熟悉