写点什么

Spring 应用合并之路(一):摸石头过河

  • 2024-10-28
    北京
  • 本文字数:2143 字

    阅读完需:约 7 分钟

作者:京东科技 李君


公司最近一年在推进降本增效,在用尽各种手段之后,发现应用太多,每个应用都做跨机房容灾部署,则最少需要 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 应用合并之路(二):峰回路转,柳暗花明

发布于: 刚刚阅读数: 4
用户头像

拥抱技术,与开发者携手创造未来! 2018-11-20 加入

我们将持续为人工智能、大数据、云计算、物联网等相关领域的开发者,提供技术干货、行业技术内容、技术落地实践等文章内容。京东云开发者社区官方网站【https://developer.jdcloud.com/】,欢迎大家来玩

评论

发布
暂无评论
Spring 应用合并之路(一):摸石头过河_京东科技开发者_InfoQ写作社区