关于打包速度慢的一次线上问题分析

问题背景：
分销模式下的app推广，用户安装或注册后，需要带上推广渠道和sdk版本等重要信息。
在不借助于open install等第三方平台的情况下，我们自己采购机器，在母包的基础上进行二次打包。实现不同的推广人员，具备不同的推广包。

image.png

接着上面的话，需要打包机器，黑苹果一台和普通的服务器一台，是部署在内网环境，会存在跨网的情况，这个容易解决。
要紧的是，在推广人员多的情况下，某一款游戏的分包也就变多，打包一个游戏的本身速度是快，但是考虑到打包机器的内存，磁盘空间，cpu是有限的情况，必须调好同时构建打包的并发数。

程序优化不能忽略cpu，内存，磁盘，网络带宽。
1、触发打包分为普通打包和高优先级打包。高优先级打包适用于临时紧急的打包任务。保证在推广人员去递推app前，我们都有打好的渠道包，只是版本非最新。

继续优化：
2、内外网之前是通过http请求触发打包，后修改为mq消息机制。内网打包机器收到触发打包的消息后，开始打包；打包完成后，发送消息给外网机器告之已打包。
3、针对打包的具体步骤，首先优化网络带宽问题。

image.png

如果母包不存在，则优先从内网ftp/svn等下载，其次是云上下载。需要注意的是下载会出现并发问题，加文件锁(FileChannel和FileLock)。

4、打包过程，起始就是解压缩的过程。受机器的磁盘和内存以及cpu的限制。
这里我们需要根据机器不同配置，去调试并发打包数。也就是mq的消费数量，spring.rocketmq.consumeThreadMax=5
spring.rocketmq.consumeThreadMin=1
5、上传渠道包，优化最见效的就是增加带宽。
6、清除工作，是指删除掉本地的打包文件，防止磁盘空间不足。
7、由于黑苹果机器，我们目前只有一台，在包体比较大且并发打包数过多的情况下，容易出现cpu的计算超负载。使用top命令可见。