SpringBoot2项⽬中（JPA+Druid）使⽤多数据源SpringBoot项⽬中JPA使⽤多数据源(举例⽤Database和Druid两种配置⽅式注：我仅写Druid的基础数据库配置)
注：代码部分因为影响阅读我将它们折叠起来惹，注意前⾯有⼩箭头的⽂本嗷
本⽂代码篇幅较长，我愿意写，你愿意听看嘛？
技术栈(仅说⼀些必要的，记着要对症下药，避免因为环境不对⽽不能使⽤)
1. mysql-connector-java 8.0.22 // 说真的有了druid之后我有段怀疑有没有必要要这个东西了... 等看明⽩了druid之后我回来再更新
⼀下。
2. druid-spring-boot-starter 1.2.3
3. spring-boot 2.4
4. spring-boot-starter-data-jpa
P.S.
需要的jar包可以直接在MavenRepository⾥搜索下载
这⾥的配置是基于注册中⼼的
业务背景只是些杂谈，具体实现直接跳转到中
预先说明
本项⽬内容我是使⽤Kotlin编写的，如果你⽤的IDE是IJ的产品，那么可以直接复制到Java代码中，IDE会⾃动编译成Java代码，但是不能保证所有的代码都是正确的，所以需要⾃⼰⼿动修复⼀部分，放⼼，不会太多的。
喵的⽤了三天时间才完成这个模块...kotlin害龙不浅呐(⼩声bb)
对于这部分代码我计划加上其它功能后封装⼀下，作为⼀个模版项⽬开源，不过短时间⾥并没有⾜够的时间去做它。
业务背景
在写了对⽅三个管理系统之后，展开了⼀次新的关于数据整合的业务，在这个业务中，我们需要拿到多个项⽬后台的数据集。 在这⾥我想到了两种解决⽅案，分别介绍⼀下其优劣。
以下内容我将跑业务的服务器统称为业务后台，将整合数据使⽤的后台称为数据后台
1. 通过不同业务中的后台中提供相对应的api来获取所需要的数据
1. ★ 可以更快地实现(添加接⼝)⽽⽆需重新配置⼀个项⽬(懒⼈专⽤)
2. ★ 对于数据后台来说能够更好的管理接⼝(通⽤的东西很多，可以很好地实现模块化)
3. ☆ 权限的对接要单独写⼀个模块
4. ☆ 如果图表有更变的话，需要修改所对应的业务，这样会让项⽬变得很乱
5. ☆ 除了查询的⽹络请求延时之外，中间还会再加⼀段⽹络数据请求(⼏乎可以⽆视，除⾮——)
2. ⼀个后台进⾏多个数据库的链接，⾃⼰拉取得所需要的数据
1. ★ 修改时不容易影响到其它的业务(独⽴服务)
2. ★ 减少中间的数据请求过程，让⼯⼚与卖家少⼀层代理(你们都知道代理是要赚钱的吧？)
3. ★ 数据整合统⼀在⼀个地⽅，易于处理，⽅便中间的数据测试(不需要再改⼤量的配置⽂件，不过我确定现在有办法解决这个问
jpa mybatis题，貌似阿⾥的学习套件⾥就包含了test和prod的运⾏环境部署，或者是部署为docker镜像，不过我还没尝试过，暂时)
既然是做了数据的整合，对于多数据库的访问就是必不可少的了，接下来的就是这篇⽂章的正题。
实现过程
SpringBoot配置数据库有两个阶段(2、3)：
1. 配置⽂件中加⼊数据信息(注册中⼼的⽅式配置)
2. DataSourceConfig(⼊⼝ 注⼊⼀些基本信息，类似于对象⽣成)
3. DataBaseConfig(数据库配置 ⽬的在于指定数据库所服务的区域)
在这⾥，分为两个步骤实现，第⼀步实现通⽤⽅法，第⼆步是实现分库配置的⽅法
P.S.
这⾥⾯两个板块的⽅法都是可以直接使⽤的(直接将通⽤⽅法或者定制⽅法的代码全部复制进去使⽤)，定制化的配置相当于通⽤⽅法的添加内容，我会表明哪些是添加的内容，具体⽅便⾃⼰写。
虽然我⽐较讨厌这么做，因为太过冗余...不过我也做过⼀个使⽤者，对于我们⽤户来说，我们更喜欢这样的拿来即⽤的东西。
通⽤⽅法
先上项⽬结构，快速认清局势(为了⽣成⼀个树状图，专门下了个brew，各种恶⼼的问题...)：
origin  # 因为前⾯的⼀堆东西太长，⼲扰视线，所以也就没有加进去了，你们能明⽩就⾏
├── config
│├── DataSourceConfig.kt  # ⼊⼝⽂件，这⾥⽤了Druid
│├── ServiceAConfig.kt  # 业务A使⽤的数据库配置
│└── ServiceBConfig.kt  # 业务B使⽤的数据库配置
├── serviceA
│└── dao
│└── ServiceADao.kt  # 这是个Dao，不⽤我解释了吧？
└── serviceB
└── dao
└── ServiceBDao.kt  # 我记得他们写JPA的喜欢命名为Repository？？
DataSourceConfig.kt
ServiceAConfig.kt
ServiceBConfig.kt
配置⽂件：
└── resources
├── application-dev.properties
└── application.properties
P.S.
这⾥我使⽤的配置⽂件是跑在开发环境的properties，如果你习惯写yml的话可以⾃⼰改过去，关键词相同，只是结构不同了(我其实挺喜欢yml的结构的，主要是想尝试下新东西，嗯)
使⽤dev的配置是在application.properties中的spring.profiles.active=dev
application-dev.properties
通⽤⽅法覆写(定制化配置)
说明：
⼀般情况下，我们需要⽤两种jpa的策略的时候才会⽤到这⾥的内容，否则上⾯的默认配置完全⾜够使⽤。
我举⼀个最简单的可以⽤到这种⽅式配置的场景——业务A的数据库使⽤的是Mysql，业务B使⽤的数据库是Oracle，这个时候就需要把他们的Driver分别配置了。
⽼规矩，先上项⽬结构(M -> Modify)：
└── origin
├── config
│├── DataSourceConfig.kt
M │├── ServiceAConfig.kt
M │├── ServiceBConfig.kt
+ │└── VendorPropertiesConfig.kt
+ ├── global
+ │└── JpaProperties.kt
├── serviceA
│└── dao
│└── ServiceADao.kt
└── serviceB
└── dao
└── ServiceBDao.kt
+ VendorPropertiesConfig.kt
JpaProperties我需要说明⼀下，这⾥我只列举了⼏个我⽤到的配置项，所以只写了四个，你需要以此类推的去写⾃⼰⽤到的选项。
这⾥的格式我参考了Druid的写法。
+ JpaProperties.kt
DataSourceConfig.kt
M ServiceAConfig.kt
M ServiceBConfig.kt
配置⽂件：
└── resources
M ├── application-dev.properties
└── application.properties
properties
JpaProperties.kt
总结(我对总结的定义是：如果将这个内容出成⼀道考题的话，那么这⾥的内容是应该是可以直接解答问题的)
项⽬配置⽂件(.properties or .yml)需要添加上两个数据库的基本信息，两个信息需要能够区分开且不能与原⽣的配置字段冲突DataSourceConfig.kt 数据库配置的⼊⼝⽂件，在这⾥声明DataSourceBuilder()
ServiceA,B,C,D进⾏多个数据源的分发，将数据源分发到对应需要的包下
如果通⽤的配置⽆法满⾜，可以⽤新的配置覆盖掉某个源的配置，需要⽤到VendorPropertiesConfig.kt，同时准备⼀个JavaBean处理注册中⼼注⼊的数据
enjoy coding
⼀些可以的改进时间不允许，所以先将想法记录
对于⽬前的jpa多源，很多东西都是相似的，完全可以对这些代码再次抽象⼀下，做成⼀个多源数据库的动态配置器。
结尾，希望这篇⽂章能够让所有⼈代码⼀次跑成。如果因为这篇博客某个地⽅⾏不通的话，务必和我联系，并说明报错部分，我会在最短时间⾥回复并更正(正常状况下24⼩时内可以回复)
因为写博客的时候是⼗⼀点半，现在已经是早上六点，四点钟的样⼦感觉整条龙都飘了⼀下下...总之，如果有问题务必联系(我不想丢⼀篇错误的博客误导⼈，⽬前为⽌我⾃⼰测试是没问题)
这两天项⽬整合到另⼀个服务器，然后会再写⼀篇Java和Mybatis的多数据库配置，我想那个⼈⽤的会多⼀些的吧...
⼀些未来的⽬标 - 2021-01-01
其实写完这篇⽂章的时候已经是2号了，整个博客期间我将代码封装了⼀次，然后调试，测试就⽤了差不多五个⼩时才算是得到这样的结果。当时这个项⽬项⽬在配置数据库的时候就⽤了⼀天半的时间，很多东西都是新接触的，并不能理解，只是在⾃⼰配置完了回头看的时候才是清晰的。
然后这次的项⽬⾃⼰尝试⽤了⼀次kotlin，写得⼗分费⼒。主要问题还是在不能new对象。。。真的是，把我们我这种单⾝⼈..啊不，龙⼠最享受的事情剥削了。 SpringBoot我倒是没有系统学过，完全凭对其机制的理解瞎摸，基本上试两次就能成。
下⼀个项⽬计划开始⽤RPC开始敲了，⼀点点进步吧，很快后台的所有类型的业务都要摸完⼀遍了，算法和⼈⼯智能的学习也不能怠惰，还有那些罄⽵难书未实现的疯狂的梦想。
争取23之前把所有该学的东西都学完...还有三年，时间不多了。
...说起来——最近好像新法律公布蹲幼⼉园要介⼊刑事责任了

版权声明：本站内容均来自互联网，仅供演示用，请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系QQ:729038198，我们将在24小时内删除。