V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
lixyz
V2EX  ›  Java

maven 项目生成的 war 太大,该如何优化?

  •  
  •   lixyz · 2020-11-18 22:38:49 +08:00 · 3267 次点击
    这是一个创建于 1244 天前的主题,其中的信息可能已经有所发展或是发生改变。

    做 Android 开发的,没写过后台

    最近自己写了一个小玩意儿,于是看了下 springboot,写了下服务端的东西

    用到的依赖是用 maven 来处理的,用阿里云出的那个插件部署到服务器上

    但是遇到的问题是生成的 war 文件很大,每次部署上去都花好长时间

    搜了一圈,都是复制来复制去

    大家开发中是怎么解决这个问题的啊

    能不能给个关键词,我去搜搜学习一下

    感谢

    第 1 条附言  ·  2020-11-18 23:43:24 +08:00
    update----------------------
    javacv 会把 android,linux,windows 等平台的 jar 包都下载下来。。。

    所以造成体积变大

    搜了一圈,只保留需要的就好了

    问题解决。。。

    感谢大家
    boris93
        1
    boris93  
       2020-11-18 22:41:15 +08:00 via Android
    依赖的 jar 多,最后整合进 war 包里,当然大啊
    ashes1122
        2
    ashes1122  
       2020-11-18 22:43:46 +08:00
    war 有多大
    你的阿里云在内地还是香港。
    lixyz
        3
    lixyz  
    OP
       2020-11-18 22:45:17 +08:00
    @boris93 我知道是因为这个原因,但是该怎么解决呢?

    我是想着,有没有什么方法,可以只把更新的代码上传到服务器,然后编译工作放到服务器上来进行

    没接触过这方面的东西,有些懵逼

    @ashes1122 服务器在国外,war 700 多 M,也是一脸懵逼。。。
    Cbdy
        4
    Cbdy  
       2020-11-18 22:49:32 +08:00 via Android
    多大?
    Cbdy
        5
    Cbdy  
       2020-11-18 22:51:35 +08:00 via Android
    700M+,不太正常
    正常 web 工程,所有依赖打成一个大 jar,一般不会超过 100M
    GuuJiang
        6
    GuuJiang  
       2020-11-18 22:53:35 +08:00 via iPhone   ❤️ 1
    第一种,不要打成 fatjar,而是打成 thinjar,也就是依赖包独立出来的那种,这样如果依赖没变的前提下每次更新只需要更新主 jar,不需要再更新依赖
    第二种,在传文件时使用 rsync 传,因为 war 包本质是 zip,rsync 的增量更新机制能发挥作用,实测大概能提速 10 倍
    lixyz
        7
    lixyz  
    OP
       2020-11-18 22:55:35 +08:00
    @Cbdy @GuuJiang

    没有接触过服务端开发,加了一个视频处理的功能,包体积一下蹭蹭涨,我是想着有没有什么方法,可以将编译打包这个操作放到服务器上去进行?
    liprais
        8
    liprais  
       2020-11-18 23:03:58 +08:00
    你在本地怎么打包的就在服务器上怎么打包不就完了
    Sharuru
        9
    Sharuru  
       2020-11-18 23:08:03 +08:00 via Android
    700M 着实不太正常,是不是把什么用不到的测试项目或者示例文件打包进去了?

    如果短时间内无法排错的情况下,可以参考楼中的建议,快速了解下各种 web 容器(比如 Wildfly )之类的,把依赖的 jar 包固化在服务器上,每次只部署主程序的代码。

    另外一种,可以参考持续集成、投递的思想,在服务器上直接拉取代码并编译,部署。减少网络传输的开销,虽然不太正规。
    lixyz
        10
    lixyz  
    OP
       2020-11-18 23:13:56 +08:00
    @Sharuru 多谢多谢,我去了解下你说的这些
    xuanbg
        11
    xuanbg  
       2020-11-19 08:28:35 +08:00
    依赖太多了呗,试着删除一些依赖看看。有用的被删除会报错,没用的删掉不影响。
    v2orz
        12
    v2orz  
       2020-11-19 08:36:34 +08:00
    5L 说全了,thinjar,依赖包第一次放到服务器上,后面只更新自己的代码,一般不会超过 5M
    boris93
        13
    boris93  
       2020-11-19 08:56:25 +08:00 via Android
    @lixyz #3 700 兆太不对劲了.....看看你是不是引用了太多不需要的依赖
    Nillouise
        14
    Nillouise  
       2020-11-19 09:11:00 +08:00
    spring boot 生成的不是 jar 吗?怎么是 war ?
    Martin9
        15
    Martin9  
       2020-11-19 09:36:44 +08:00
    是不是加了很多没用的依赖,正常不可能几百兆的
    10Buns
        16
    10Buns  
       2020-11-19 09:43:25 +08:00
    @Nillouise packaging 设置了 war 吧
    lrvinye
        17
    lrvinye  
       2020-11-19 10:45:52 +08:00 via iPhone
    @lixyz 可以试下 coding 这类的 devops 平台
    cco
        18
    cco  
       2020-11-19 11:09:33 +08:00
    把不用的依赖包统统剔除掉。
    hantsy
        19
    hantsy  
       2020-11-19 11:29:13 +08:00
    依赖太多了,一般 Web 程序可以控制在 50M 内。
    jaoyina
        20
    jaoyina  
       2020-11-19 12:53:48 +08:00 via iPhone
    你自己写的小玩意怎么也不需要 700M 吧我们一个大型 web 应用,依赖 200 多个 jar,打出来也不到 300M 。看下包里的内容,曾经听说有人打了个星际争霸硬盘版进去,运行好几年。
    someonedeng
        21
    someonedeng  
       2020-11-19 16:09:34 +08:00
    700m 你是怎么打出来的= =
    ArJun
        22
    ArJun  
       2020-11-19 16:12:03 +08:00
    用 go 拆分,拆分成微服务
    passerbytiny
        23
    passerbytiny  
       2020-11-19 16:28:02 +08:00 via Android
    对于非专业运维人员来说,最简单的方式是不要打 war 包,拆开之后,哪里改了重新上传那个。

    然而你这个包不应该这么大的,看你补充的内容,是把操作系统平台 jar 包都依赖了,服务端明显不需要这些东西。严格的说,服务端和 Android 端的 Java 是两套语言,有些工具你不能直接套过去用,需要换掉,比如 Gson 换 Jackson 。
    关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   我们的愿景   ·   实用小工具   ·   3998 人在线   最高记录 6543   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 38ms · UTC 10:23 · PVG 18:23 · LAX 03:23 · JFK 06:23
    Developed with CodeLauncher
    ♥ Do have faith in what you're doing.