Spring 应用合并之路（一）：摸石头过河 | 京东云技术团队

公司在推进降本增效，在尝试多种手段之后，发现应用太多，每个应用都做跨机房容灾部署，则最少需要 4 台机器（称为容器更合适）。那么，将相近应用做一个合并，减少维护项目，提高机器利用率就是一个可选方案。

经过前后三次不同的折腾，最后探索出来一个可行方案。记录一下，分享出来，希望对有相关需求的研发童鞋有所帮助。下面按照四种可能的方案，分别做介绍。另外，为了方便做演示，专门整了两个演示项目：

•diguage/merge-demo-boot — 合并项目，下面简称为 boot。

•diguage/merge-demo-web — 被合并项目，下面简称为 web。

一、Jar 包引用

这个方式，可能是给人印象最容易的方式。仔细思考一下，从维护性的角度来看，这个方式反而是最麻烦的方式，理由如下：

1.web 项目每次更新，都需要重新打包发布新版； boot 项目也需要跟着更新发布。拉一次屎，脱两次裤子。属实麻烦。

2.还需要考虑 web 项目的加载问题，类似下面要描述的，是否共用容器：共用容器 — 这是最容器想到的方式。但是这种方式，需要解决 Bean 冲突的问题。不共用容器 — 这种方式需要处理 web 容器如何加载的问题。默认应该是无法识别。

基于这些考虑，这种方式直接被抛弃了。

二、仓库合并，公用一套容器

这是第一次尝试使用的方案。也是遇到问题最多的方案。

1.将两个仓库做合并。

1.将 web 仓库的地址配置到 boot 项目里： git remote add web git@github.com:diguage/merge-demo-web.git；

2.在 boot 项目里，切出来一个分支：