大家在平时开发的过程中,经常会在Aone上部署自己的应用进行功能验证,可能都会遇到应用在Aone上部署非常慢性,其中花在打包上的时间就差不多有7-8分钟,非常影响开发效率,下图就是一个非常典型应用在aone上部署构建一次所花的时间:
长期这么下去,肯定会是有问题,主要有如下两个方面的问题:
1. 应用打出的War包会越来越大,部署一次所花的时间会越来越长;
2. 新的需求,会不断升级已经的jar包和引入新的jar包,每个jar包会随着时间的推移,各个版本依赖深浅不断的变化,导致同一个应用中同一个jar包真正依赖的jar的版本不同,有时会出现莫期妙的问题,例如
图中honolulu-common,现在看是依赖的最终版本是1.0.2,也许明天又有一个新人依赖进来,间接依赖了honolulu-common,如果版本高,最终依赖的版本就高,这是只maven依赖深度不同而已,平时我们接触到的其它应用提供的二方包,比这种情况要复杂得多,这恐怕才是导致我们的业务系统依赖的jar包越来越多,间接依赖的jar包版本不断变化,应用打出的war包越来越慢的根本原因,下面就来分享一下自己在这段时间对应用的jar包进行排除来提升应用打包速度所做的工作:
1.安装idea插件Maven Helper
如果发现自己的idea没有安装,就安装Maven Helper
安装Maven Helper插件以后,重启Idea, 随便点击项目中任意一个模块的pom.xml,如果左下角出现Dependency Analyzer,说明插件安装成功,如下图所示:
点击Dependency Analyzer, 如下图所示:
输入你想要排除的jar包,点击右键,出现Exclude,再点击Exclude即可排除该包的的依赖
2. 二方包&客户端jar包排除:
二方包&客户端jar排除相对比较容易,基本的原则是: 不影响二方包打包发布成功的jar都可以排除掉,拿lafite这个应用的二方包来说,除了latour-client, commons-lang3和slf4j-api 这三个jar以外,其它的二方包都用不上,都可以排除,排除以后,发现lafite-client打包的速度超超快, 如下图:
排包后:
打包前:
对比打包前和打包后,我们发现,排包后,打包的速度差不多提高了近3倍左右,提速还是非常明显
经验:
1. 二方包依赖的jar 包越小越好,去掉一切无用的Jar包,判断的标就是打出的二方包不出错,即可,当然这么做会有风险,但一般的二方包都不是特别复杂,在打包的时候,基本上都能判断出来
2. 最好用maven3.0+以上的版本打二方包,不到万不得已,不要用maven2.2.1版本打二方,这会坑了其它依赖你二方包的开发同学,导致其它用依赖用maven2.2.1版本打出的二方包无法做Maven升级
3. 应用本身二方包排除:
应用本身的二方包排除要稍微复杂些,首先要确认那些jar包对应用来确实无用,这个确认的过程比较长,可以用一个定时任务来确认,方法如下:
1. 在应用的各个环境的脚本文件setenv.sh中,找到下面这一行:
CATALINA_OPTS="{CATALINA_OPTS} -Dhsf.publish.delayed=false", 然后在这一行加上下面这一行: CATALINA_OPTS="{CATALINA_OPTS} -XX:+TraceClassLoading"
如下图所示:
这样每个类在加载的时候,详细的加载信息会在tomcat_stdout.log这个文件中打出, 部分信息如下图所示:
图中包含每个类加载,以及这个类来自那个jar包,例如:org.apache.catalina.util.LifecycleBase 这个类被加载时,是来自catalina这个jar包,/opt/taobao/install/tomcat-7.0.59.3/lib/catalina.jar
2. 在应用中添加一个定时任务检测类:
myju中的定时任务检测类是com.taobao.ju.my.performance.CheckNoUsedJarsJob, 代码如下:
/**
* 检查无用jar包
* desheng.tds
*/
public class CheckNoUsedJarsJob implements SimpleJobProcessor {
private static Logger logger = LoggerFactory.getLogger(CheckNoUsedJarsJob.class);
@Override
public ProcessResult process(SimpleJobContext simpleJobContext) {
try {
File tomcatStdoutLog = new File("/home/admin/myju/logs/tomcat_stdout.log");
File jarDir = new File("/home/admin/myju/target/myju.war/WEB-INF/lib");
String[] fileNames = jarDir.list();
BufferedReader bufferedReader = new BufferedReader(new FileReader(tomcatStdoutLog));
String line = null;
Set<String> sysJars = new HashSet<>();
Set<String> lines = new HashSet<>();
List<String> noUsedJars = new LinkedList<>();
while ( (line = bufferedReader.readLine()) != null ) {
// System jar包
if (line.startsWith("[Loaded") && line.contains("from")
&& line.contains("taobao-hsf.sar") && line.contains("/opt/taobao/install")) {
int index = line.lastIndexOf("]");
String sysJar = line.substring(0, index);
index = sysJar.lastIndexOf(" ");
sysJar = sysJar.substring(index+1);
if (sysJar.endsWith("!/") && sysJar.length() > 2) {
sysJar = sysJar.substring(0, sysJar.length() - 2);
}
index = sysJar.lastIndexOf("/");
sysJar = sysJar.substring(index+1);
sysJars.add(sysJar);
}
if (line.startsWith("[Loaded") &&
line.contains("from") &&
!line.contains("taobao-hsf.sar") &&
!line.contains("/opt/taobao/install")) {
int startIndex = line.lastIndexOf("/");
int endIndex = line.indexOf(".jar]");
if (startIndex >= 0 && endIndex>0 && endIndex + 4 <= line.length())
line = line.substring(startIndex+1, endIndex + 4);
lines.add(line);
}
}
for (String fileName : fileNames) {
if (!lines.contains(fileName) && !sysJars.contains(fileName)) {
noUsedJars.add(fileName);
}
}
for (String fileName : noUsedJars) {
File file = new File("/home/admin/myju/target/myju.war/WEB-INF/lib/" + fileName);
String strLen = null;
long len = file.length()>> 10;
if (len > 1024) {
strLen = (len * 1.0 /1024) + "MB" ;
} else {
strLen = len + "kB";
}
logger.warn("fileName=:{}, size={}", fileName, strLen);
}
} catch (Exception e) {
logger.warn("[CheckNoUsedJarsJob.process] error e={}", e);
}
return new ProcessResult(true);
}
}
代码的逻辑比较简单:在应用的war包WEB-INFO/lib目录中检查应用在启动和运行过程中不需要的jar包,一般依赖的war包的jar目录是"/home/admin/应用名/target/应用名.war/WEB-INF/lib/,例如myju应用的jar目录是:"/home/admin/myju/target/myju.war/WEB-INF/lib/,当然有些jar包是来自JDK和Pandaro容器,这部分jar最好也不要排除
3.添加任务检测任务的日志
myju中日志配置如下:
<appender name="CheckNoUsedJarsJob_LOG" class="ch.qos.logback.core.rolling.RollingFileAppender">
<file>${ju.my.loggingRoot}/myju_check_no_used_jars.log</file>
<encoder>
<pattern>%d{yyyy-MM-dd HH:mm:ss.SSS} - %m%n</pattern>
<charset>GBK</charset>
</encoder>
<rollingPolicy class="ch.qos.logback.core.rolling.TimeBasedRollingPolicy">
<fileNamePattern>${ju.my.loggingRoot}/myju_check_no_used_jars.log.%d{yyyy-MM-dd}</fileNamePattern>
<maxHistory>7</maxHistory>
<timeBasedFileNamingAndTriggeringPolicy class="ch.qos.logback.core.rolling.SizeAndTimeBasedFNATP">
<maxFileSize>5000MB</maxFileSize>
</timeBasedFileNamingAndTriggeringPolicy>
</rollingPolicy>
</appender>
<logger name="com.taobao.ju.my.performance.CheckNoUsedJarsJob" level="info" additivity="false">
<appender-ref ref="CheckNoUsedJarsJob_LOG"/>
</logger>
即检查任务的日志每天打印在myju_check_no_used_jars.log文件中
4.启动任务,可以看到日志文件中有打印出的相关无用jar和大小
myju中如下图所示:
这些无用的jar基本上都可以排除掉,排除掉以后,打出的war包会小很多:
下面是排包前后,打出的war包大小对比:
排包前:
排包后:
对比排包优化前后发现,war包的大小由340M左右减少到160M左右,整整减少一半以上,当然这160M中还包含了近200个被检测无用的jar包,如果把这200个左右的jar包也排掉的话, 估计最终打出的war包会更小;
5. 建议:
1.
提前把这个定时任务在线上加了,只有程序运行的时间越长,才能够更加确定那些jar包是无用的,这个时间一般要2-3周的时间,如果中间有一个大促会是再好不过了,不明确的地方,找熟悉的人进行功能回规,实在没有人熟悉的功能,就只能通过线上beta了,当然风险一定要可控,一般情况下,是发布了一个新版本,一定要及时拉一个新分支,随时应对jar包排错的风险
2.
优先排掉比较的无用而且比较大jar包,这样排包的效果会更明显;
3.
同一个jar包的不同版本,尽量排掉依赖更深的依赖,在不好处理的情况下,加直接依赖,然后再把间接依赖全部去掉,减少了间接依赖,有利于打包速度的提高,同时还可以防止jar间接升级导致的不可控的问题;
4 优化效果:
排包优化之前:
排包优化之后:
排包优化前后,打包构建时间整整减少一半以上,打包构建速度整理提高了100%以上
文章中有不足或没有写清楚的地方,欢迎大家指出纠正,一起进步成长
后面会介绍如何监控一个应用中启动比较慢性的Bean,以及在公司内部,如何优化这些启动比较慢性的Bean