SpringCloud 多模块部署瘦身包整理流程

Posted 2022-09-08 毕小宝

背景

SpringCloud 的微服务架构的应用程序发布时，多个模块可能会统一部署在一台主机上，那么就面临引用依赖过多，部署包介质过大，占用磁盘空间过多，下载耗时、更新麻烦等问题。

连续对两个项目进行依赖包整理后，本文将总结多模块单机部署时瘦身包整理的基本思路。

分析依赖包

首选，模块瘦身打包。 各模块依赖的包单独打到特定目录，编写脚本打印出各模块的依赖。

其次，找出所有模块都共有的包。 Shell 计算交集感觉有点复杂，简单的方法是用 Java 的集合来计算，用第一步打印的各模块的依赖文件，Java 读取文件到列表后走集合的 retainAll 计算出公共文件。

第三步，其他纯功能的依赖包抽取到一起。 在用 Shell 将各个模块的纯功能的 jar ，如 commons-lang、mybatis、okhttp、Spring-Cloud 等依赖移动到特定公共目录中。

第四步，启动参数配置。 按各模块的引用情况，调整启动脚本，加上 -Dloader.path 参数，注意，它不能与 Java 的自身的参数 -Djava.ext.dirs 一起用，因为是冲突的。

第五步，启动脚本支持输出控制台日志。 初期验证时，需要对各模块逐个启动，难免会报错，所以可以对启动脚本的控制台输出进行存储，通过参数控制：

if [ -n "$1" ] ;then
  echo 'print console log when test. '
  nohup java -Dloader.path=$loadPath -jar myapp.jar >out.log 2>error.log &
else
  echo 'ignore console log when product.'
  nohup java -Dloader.path=$loadPath -jar myapp.jar >/dev/null 2>&1 &
fi

启动脚本参数控制，测试的时候就可以看到启动问题了；生产的时候关闭控制台日志，减少磁盘空间的浪费。

微服务项目实践总结

瘦身包部署，最重要的是依赖包的版本统一，最好能在项目搭建的时候就统一在父工程中统一管理版本，保证各模块中相同库的版本一致，这对共享 jar 包提供了安全，可以减少包冲突的风险。

如果一开始没有做好版本管理，那么整理依赖包时，有两种思路：

第一，保险的抽取公共包的方法是按 jar 包的功能抽取，除了特殊依赖自动注入的包外，引用该包对模块不会有影响。缺点是，各自模块自身还有依赖，存在一部分冗余。

第二，激进的方法是，所有模块的 jar 包一股脑放在一起，这个方式适合各模块依赖几乎一致的情况。优点是，全部依赖放在一起，没有冗余，最节省空间。

所有模块的依赖都放在一起，存在不可控因素，所以选择的是第一种按功能包的方式，大概将一个包含十个模块的包从 2G 多降到了800MB 左右。

启示录

这个抽取公共依赖的过程，是通过 Shell 脚本完成的，期间又温故了 Shell 编程的知识，对依赖包的冲突和兼容问题也有了一些新知。

1. nohup忽略脚本的控制台输出 >/dev/null ，注意这个字符串之间不能有空格，否则会提示：nohup: 重定向标准错误到标准输出。
2. MyBatis 的高版本的 3.4.0 的 Orderitem 不兼容低版本 3.2.2 的方法，但是低版本倒是可以兼容高版本，挺不可思议的。
3. 抽取公共包时，自动创建包目录 mkdir -p 参数，比起手动创建各目录方便多了。
4. slf4j-log4j12-1.7.31.jar 和 logback-classic 里面有配置冲突，需要删掉一个。
5. lang-mustache-client-6.8.6.jar 属于 ES 的依赖包被 spring-boot-autoconfigure.jar 引用了，抽取 elasticsearch 的时候还需要加入这个包。
6. logback 包版本问题，logback.xml 配置文件中的 M 单位不识别，是区分版本的，低版本的识别 M 或 MB ，但是高版本的不识别M，只能识别 MB。

总之，多模块共享部署包，需要逐个模块启动验证依赖是否有问题，最好能在项目初期做好版本控制，而不是等到发部署包时才去瘦身依赖。