基于Jar-of-Jars构建Thin War的可行性及优劣对比咨询

方案可行性 #

这个方案完全可行。注意你提到的$CATALINA_OUT是Tomcat的日志输出目录，正确的共享依赖存放路径应该是$CATALINA_BASE/lib或$CATALINA_HOME/lib——Tomcat会优先从这两个目录加载全局共享类库。Thin War只需包含应用自身的业务类、租户专属配置文件（如application-tenantX.properties）、web.xml等部署描述文件即可，启动时会自动从共享库拉取依赖。

对比Fat War的优点 #

• 部署速度暴增：Thin War体积只有Fat War的几十分之一甚至几百分之一，上传、解压、部署的时间直接砍半甚至更多，多租户批量部署时效率提升尤为明显。
• 省磁盘空间：所有租户实例共用同一套依赖Jar，不用重复存储大量相同的第三方库，磁盘占用能减少一大截。
• 依赖版本统一：共享依赖集中管理，所有租户用的依赖版本完全一致，不会出现某个Fat War依赖版本不一致导致的奇怪兼容性问题。
• 运维更省心：要是需要更新公共依赖，只替换共享目录里的Jar包就行，不用逐个重新打包、上传每个租户的Fat War，运维成本直接降低。

对比Fat War的缺点 #

• 依赖冲突难处理：如果某个租户需要特殊版本的依赖，没办法单独调整，只能所有租户一起升级或降级，灵活性太差。
• 环境耦合度高：共享依赖和Tomcat节点绑定，要迁移某个租户应用到其他Tomcat节点，必须保证目标节点的共享依赖版本完全一致，迁移复杂度上升。
• 调试更麻烦：出现类加载异常时，得同时排查共享库和Thin War的类加载顺序，不像Fat War有独立的类加载环境，定位问题要花更多时间。
• Tomcat启动变慢：共享库包含所有依赖，Tomcat启动时要加载的类更多，首次启动或重启的时间可能比部署多个Fat War更长。
• 权限限制多：$CATALINA_BASE/lib一般需要管理员权限才能修改，普通运维人员没法自行更新依赖，流程上更繁琐。

内容的提问来源于stack exchange，提问作者Taco Jan Osinga