公司最近一年在推进降本增效，在用尽各种手段之后，发现应用太多，每个应用都做跨机房容灾部署，则最少需要 4 台机器（称为容器更合适）。那么，将相近应用做一个合并，减少维护项目，提高机器利用率就是一个可选方案。
经过前后三次不同的折腾，最后探索出来一个可行方案。记录一下，分享出来，希望对有相关需求的研发童鞋有所帮助。下面按照四种可能的方案，分别做介绍。另外，为了方便做演示，专门整了两个演示项目：
•
diguage/merge-demo-boot — 合并项目，下面简称为 boot。
•
diguage/merge-demo-web — 被合并项目，下面简称为 web。
一、Jar 包引用
这个方式，可能是给人印象最容易的方式。仔细思考一下，从维护性的角度来看，这个方式反而是最麻烦的方式，理由如下：
1.web 项目每次更新，都需要重新打包发布新版； boot 项目也需要跟着更新发布。拉一次屎，脱两次裤子。属实麻烦。
2.还需要考虑 web 项目的加载问题，类似下面要描述的，是否共用容器：共用容器 — 这是最容器想到的方式。但是这种方式，需要解决 Bean 冲突的问题。不共用容器 — 这种方式需要处理 web 容器如何加载的问题。默认应该是无法识别。
3.
基于这些考虑，这种方式直接被抛弃了。
二、仓库合并，公用一套容器
这是第一次尝试使用的方案。也是遇到问题最多的方案。
1.将两个仓库做合并。
1.将 web 仓库的地址配置到 boot 项目里： git remote add web git@github.com:diguage/merge-demo-web.git；
2.在 boot 项目里，切出来一个分支： git switch -c web；
3.将 web 分支的提交清空： git update-ref -d HEAD，然后做一次提交；
4.将 web 项目的代码克隆到 web 分支上： git pull --rebase --allow-unrelated-histories web master；注意，这里需要加 --allow-unrelated-histories 参数，以允许不相干的仓库进行合并。
5.从 boot 项目的 master 分支上，切出来一个合并分支： git switch -c merge；
6.将 web 项目向 boot 项目合并： git merge --allow-unrelated-histories web；注意，这里需要加 --allow-unrelated-histories 参数，以允许不相干的仓库进行合并。
7.处理代码冲突，完成合并即可。
2.配置文件的合并于归整。为了防止同名配置文件冲突，需要把 web 项目的配置文件调整到一个文件夹下，这里设定为 web 目录。然后，需要把 web 项目的配置文件，让 boot 可以加载到。这个调整相对简单，只需要一个注解即可 @ImportResource({"classpath:web/spring-cfg.xml"})。
3.调整完配置文件，接着遇到的问题就是上面提到的 Bean 冲突的问题。由于两个项目都访问相同的数据库， Dao 及 Service 层很多很多类都是同名的。另外，在 web 项目里，Dao 是基于 iBATIS 开发的，而在 boot 项目里，DAO 是基于 MyBATIS 开发的。所以，只能给 web 项目的相关代码做重命名（严谨一点是给 Spring Bean 的 beanName 做重命名操作）。这又带来了新问题：原来的项目里，注入方式是根据名称注入的，就需要改动大量的代码，给相关的 Bean 变量做重命名操作。这无形中增加了很多的复杂度和不确定性。
经过不断折腾，这种方式被迫放弃。
三、仓库合并，Spring Boot 父子容器
在经过上述方式折腾后，就想到了另外一个方案：可以考虑使用父子容器的方式来搞。接着就查到了这篇文章： Context Hierarchy with the Spring Boot Fluent Builder API。感觉这种方式挺不错，就尝试了一下。
1.代码合并及文件调整，跟上述步骤类似，这个后面就不再赘述。
2.按照文章中的介绍，使用父子容器的方式来加载两个项目。代码如下：
3.原以为，这种方式属于父子两个容器，即使有同名的 Bean 应该也没有影响。但是，经过实践才发现，上面这个猜测是错误的。Spring Boot 在启动的时候，它背后做了检查，如果两个容器有同名的 Bean，它也会报错。也会带来像上述方式那样的大量重命名。折腾一两天，最后还是放弃了这种寄予厚望的方式。
package com.diguage.demo.boot;import org.springframework.boot.WebApplicationType;import org.springframework.boot.builder.SpringApplicationBuilder;import org.springframework.context.annotation.ComponentScan;import org.springframework.context.annotation.Configuration;import org.springframework.context.annotation.ImportResource;/**
* @author D瓜哥 · https://www.diguage.com
*/public class DemoBootApplication {
public static void main(String[] args) {
new SpringApplicationBuilder()
.parent(BootConfig.class).web(WebApplicationType.NONE)
.child(WebConfig.class)
// 如果有第三个项目，可以作为子容器的兄弟容器加载。
// .sibling(SiblingConfig.class)
.run(args);
}
@Configuration
@ImportResource({"classpath:spring-cfg.xml"})
@ComponentScan(basePackages = "com.diguage.demo.boot")
public static class BootConfig {
}
@Configuration
@ImportResource({"classpath:web/spring-cfg.xml"})
public static class WebConfig {
}}
|
|
Spring Boot 背后是否做了检查，这个是根据报错信息的猜测，没有翻看代码，所以这个猜测有一定的不确定性。有机会翻一下代码，查看一下具体原因。 |
革命尚未成功，且听下回分解……
下文： Spring 应用合并之路（二）：峰回路转，柳暗花明
来自 “ ITPUB博客 ” ，链接：https://blog.itpub.net/70037994/viewspace-3042997/ ，如需转载，请注明出处，否则将追究法律责任。
请登录后发表评论
登录
全部评论
