1. Project background
Spring Cloud builds spring boot projects, refines the levels of each project, and achieves the purpose of reducing coupling. The projects are based on restful communication.
During the process of packaging the project, use the spring-boot-maven-plugin plugin to package it, and the fat jar is generated. If the jar package is unzipped, you will find that the jar package that the project depends on is stored in the lib folder under BOOT-INF. After analyzing multiple sub-projects, you will find that the same jar package accounts for the vast majority. Then, each time it is deployed in an online environment, the common jars of each system are actually repeatedly shelved on the server. Therefore, you will naturally think of whether there is a way to extract the common jar package or the jar package that is not often modified, sort out a separate copy, and then use external loading to achieve the purpose of losing weight by fat jars.
2. Fat jar slimming
After the above analysis and reviewing relevant information, we sorted out the following steps to make jar-package slimming:
1. Each project configures the spring-boot-maven-plugin plugin (official document) to generate the jar package retained in the fat jar
<plugin> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-maven-plugin</artifactId> <configuration> <layout>ZIP</layout> <!-- <excludeGroupIds> org.springframework.boot, org.springframework.cloud, org.mybatis.spring.boot, tk.mybatis, mysql, com.alibaba, javax.persistence, io.springfox, org.springframework.session </excludeGroupIds> --> <includes> <include> <groupId>xx</groupId> <artifactId>xx</artifactId> </include> <include> <groupId>xx</groupId> <artifactId>xx</artifactId> </include> </includes> </configuration> </plugin>
As with the above code, you can use excludeGroupIds, or include, or other tags, depending on the situation.
2. Extract the jar packages that you do not want to store in the fat jar from the project dependency jar.
Method 1 (recommended): Add maven dependency plug-in to the project pom file (official document)
<plugin> <groupId>org.apache.maven.plugins</groupId> <artifactId>maven-dependent-plugin</artifactId> <version>3.1.1</version> <executions> <execution> <id>copy-dependents</id> <phase>package</phase> <goals> <goal>copy-dependents</goal> </goals> <configuration> <!-- <outputDirectory>E:/lib</outputDirectory> --> <excludeGroupIds> <!-- Remain in fat groupId attribute value (multiple, separated) of jar package in jar --> </excludeGroupIds> <overWriteSnapshots>true</overWriteSnapshots> </configuration> </execution> </executions> </plugin>
Check the official document for the specific meaning of the tag.
When using maven to package a project, use the maven command:
mvn clean install -Dmaven.test.skip=true -DoutputDirectory=E:/lib (-DoutputDirectory=E:/lib is the path exported by the jar package that the project depends on dynamically. If the label value of outputDirectory is specified in the project, this dynamic path will be overridden)
After the configuration plug-in executes this command, except for the jar package configured in the excludeGroupIds tag, the rest of the project will be imported into the specified directory, and the excess jar packages in the fat jar will be extracted.
Method 2: Do not add maven dependency plug-in to the project, and directly use mvn to copy the commands that depend on the jar package for the project. This method requires the dependency copying of each sub-project one by one, and few sub-projects can be used.
mvn dependency:copy-dependencies -DoutputDirectory=E:/lib (If there is no directory specified dynamically, the dependency directory will be generated by default in the project's target path)
Put the dependency jar packages exported by each project into a folder, remove duplication, and delete the dependency jar packages reserved in the fat jar, and then complete the removal of the excess jar packages in the fat jar.
3. Place the extracted jar package in a certain path of the server, configure the project startup script, and load it externally.
nohup java -Dloader.path="xx/lib" -jar xx.jar
-Dloader.path is the external loading address.
After slimming down, you can see in the jar package after the project is packaged. In the lib under BOOT-INF, there are only the required jar packages, which greatly reduces the size of the fat jar.
The configuration of pom can be used in the microservice system to form a unified configuration, and the jar package dependencies in each project are changed depending on the specific situation.
3. Problems encountered and solutions
In the process of slimming, it was not smooth sailing. When I thought the work was done and started the project, I found that the startup failed and the jar conflicted.
1. Resolve jar package conflicts, analyze the dependencies of jar packages through the mvn command, and find the conflicting jar packages, and unify the version.
In eclipse, I created a new Maven Build. At the beginning, I tried mvn dependency:tree, and analyzed the jar package dependency as a whole, but did not find the dependency of the problem jar package. Then I tried mvn dependency:tree -Dverbose, and analyzed all indirect implicit dependency as a whole and still did not find the dependency of the problem jar package.
At this point, I suspect that there is no jar package in the project. After repeated packaging, I see that this problem is indeed in the project dependency, but it is hidden too deeply. Therefore, only analyses can be performed for a single jar package:
mvn dependency:tree -Dverbose -Dincludes=xx:xx:xx(xx:xx:xx corresponding to jar package groupId:artifactId:version)
After using Dincludes, the dependency relationship of the corresponding jar package is found, and the jar package is excluded in the project. After packaging again, the project starts successfully and the problem is solved.
2. During the packaging process, some sub-projects did not use the spring-boot-maven-plugin plugin, but used maven-jar-plugin to directly package it into a runnable jar. After combining the fat jar slimming configuration, it was found that the jar that could have relied on interoperable ones has now failed. Since fat jars are slimming, only the jars of projects whose code is frequently changed are left, and the dependencies are not passed in runnable jars, so you need to explicitly depend on the jar package of the required project in this project to ensure the completeness of the project.
The above is all the content of this article. I hope it will be helpful to everyone's learning and I hope everyone will support Wulin.com more.