【业务功能篇09】Springboot多环境多数据源的配置、DS注解失效解决方案

通过再resources资源目录--config目录，我们分成了开发 生产 测试三个，不过一般我们都是测试环境进行测试数据库，本地开发环境就是连接测试环境  根据三个不同的环境，注意命名规范：

application-xxx.yml，这样在我们的app配置文件就可以指定后缀这个值xxx就表示要运行哪个环境的配置，一般不同环境，就是分数据库不同 测试和生产的数据库各一套进行验证

多环境配置
我们在开发Spring Boot应用时，通常同一套程序会被应用和安装到几个不同的环境，比如：开发、测试、生产等。其中每个环境的数据库地址、服务器端口等等配置都会不同，如果在为不同环境打包时都要频繁修改配置文件的话，那必将是个非常繁琐且容易发生错误的事。

对于多环境的配置，各种项目构建工具或是框架的基本思路是一致的，通过配置多份不同环境的配置文件，再通过打包命令指定需要打包的内容之后进行区分打包，Spring Boot也不例外，或者说更加简单。

在Spring Boot中多环境配置文件名需要满足application-{profile}.properties的格式，其中{profile}对应你的环境标识，比如：

application.properties：默认配置
application-dev.properties：开发环境
application-test.properties：测试环境

步骤一、创建多个配置文件

application.yml      #主配置文件
application-dev.yml  #开发环境的配置
application-prod.yml #生产环境的配置
application-test.yml #测试环境的配置

  步骤二、applicaiton.yml中指定配置
在application.yml中选择需要使用的配置文件（当选择的文件和application.yml文件存在相同的配置时，application.yml中的配置会被覆盖掉）

spring:
 profiles:
   active: dev #需要使用的配置文件的后缀

POM文件：添加依赖

        <dependency>
            <groupId>com.baomidou</groupId>
            <artifactId>dynamic-datasource-spring-boot-starter</artifactId>
            <version>3.5.2</version>
        </dependency>

POM文件： 添加多环境配置 （该方式可以剔除 是另外一种）

   <profiles>
        <profile>
            <!-- 生产环境 -->
            <id>prod</id>
            <properties>
                <SpringProfilesActive>prod</SpringProfilesActive>
            </properties>
        </profile>
        <profile>
            <!-- 测试环境 -->
            <id>test</id>
            <properties>
                <SpringProfilesActive>test</SpringProfilesActive>
            </properties>
        </profile>
        <profile>
            <!-- 本地环境 -->
            <id>dev</id>
            <properties>
                <SpringProfilesActive>dev</SpringProfilesActive>
            </properties>
        </profile>
    </profiles>

 我们在 application.yml 应用配置文件中 通过spring.profiles.active:指定环境，从而去应用对应的一个环境的配置文件 application-xxx.yml，那么程序运行时就会根据对应配置文件配置的参数去运行

配置多数据源：通过对应的环境配置文件去设置

比如在application-prod.yml 生产配置文件：

默认主数据源是mysql      

spring:
  datasource:
    dynamic:
      primary: mysqldb # 默认数据源
      datasource:
        mysqldb:
          driverClassName: org.mariadb.jdbc.Driver
          url: jdbc:mysql://xxx:3306/xxx?useUnicode=yes&characterEncoding=UTF-8&useAffectedRows=true&allowMultiQueries=true&autoReconnect=true&failOverReadOnly=false
          username: ENC(xxx)
          password: ENC(xxx)
        gaussdb:
          driverClassName: org.postgresql.Driver
          url: jdbc:postgresql://xxx:8000/xxx
          username: ENC(xxx)
          password: ENC(xxx)

其次还需要在启动类中，去排除DataSourceAutoConfiguration.class  他默认会帮我们自动配置单数据源，所以，如果想在项目中使用多数据源就需要排除它，手动指定多数据源。

该注解的作用是，排除自动注入数据源的配置（取消数据库配置），在springBoot中使用多数据源时，启动类加上@SpringBootApplication(exclude={DataSourceAutoConfiguration.calss})

如何使用次数据源：

在dao层mapper接口中 需要的方法位置上加入注解@DS 切换指定的数据源名字

@DS("gaussdb")

或者说在调用的service层实现类的方法上加该注解也可以

import com.baomidou.dynamic.datasource.annotation.DS;

@Mapper
public interface kMapper {

  
    @DS("gaussdb")
    void test(@Param("codes"));
 
}

• 注意下面这种情况，如果说一个dao层接口方法查询的sql中，是包括主数据源和备数据源的，那么就需要在service层注解时，需要加上requests_new的事务传播方式，不然spring默认还是会取主数据源，而不会切换数据源
• 查询的那个Service可以不加事务注解，但如果它的上层调用使用了事务，那么这个查询Service也会被纳入事务管理。这个时候：如果查询service需要使用别的数据源，那么就要新建事务。
• REQUIRES_NEW 传播机制，就是当上层调用有事务的时候，也就是自己这个方法会重新创建一个自己的事务进行执行，这样新的事务才能切换成我们@DS注解的备数据源，因为外层的事务是配置的默认的数据源，所以需要单独起一个备数据源的事务才能访问到备数据源

总结：

1.当前我们有两个数据源，要切换备数据源，通过@DS('备数据源名称')，注意该名称是在yml配置数据源配置的

2.@DS('备数据源名称') 可以放在接口，类，方法上，如果放在接口上那么接口的全部方法都是切换到备数据源的，类同理。  当然，最好是把需要切换备数据源的统一都写到dao层的接口，直接对接口上加注解，统一管理， 你也可以在service层某个方法调用到某个dao层接口(备数据源)，再在该方法上面加注解@DS，适用于当切换数据源的情况较少的时候可以这么多，如果多的话，统一放dao层接口比较好维护

3.什么情况下@DS会失效？ 也就是前面说的，如果上层也就是servic或者其他层都可以，只要调用了我们需要切换数据源、加@DS注解的具体方法(建议统一写到dao层接口下统一管理)，而且上层调用中存在了@Transactional事务，那么@DS就会失效，可以理解为上层创建了一个事务，那么这个事务默认的数据源就是yml配置的默认数据源比如mysql, 那么在这个事务下，就不能切换访问到备数据源了，所以我们需要在该具体的dao层接口的方法中，加上事务@propagation = Propagation.REQUIRES_NEW, 注意这个传播方式，是上层方法有事务，那么当前新创建事务，把上层挂起，这样另起一个事务就可以访问到对应的备数据源了，也就是@DS+@propagation = Propagation.REQUIRES_NEW搭配使用才能成功访问到备数据源

4.优化： 如果切换到备数据源只是查询操作，我们可以不起事务去查询，传播方式是NOT_SUPPORTED， 也就是当上层调用有事务，将事务挂起，当前以非事务状态进行； 但是如果你的操作是增删改的，那么建议肯定是用requests_new，这个模式

//方式一：可以统一放接口，接口下全部方法都是访问备数据源的
@Mapper
@DS("gaussdb")
@Transactional(propagation = Propagation.REQUIRES_NEW)
public interface SMapper extends BaseMapper<Dto> {

  @Select("select x from x where ...")
  List<DTO> getQuery();

  void insert(@Param("Code") String code);
}



//方式二：无法统一，可能是再某个默认数据源接口下 仅少数切换数据源访问
//只能对应的具体方法上加注解进行切换
@Mapper
public interface SMapper extends BaseMapper<Dto> {
    @DS("db")
    @Transactional(propagation = Propagation.NOT_SUPPORTED)
    String query(@Param("Code") String code);

    @DS("db")
    @Transactional(propagation = Propagation.REQUIRES_NEW)
    void insert(@Param("Code") String code);
}

补充： 

进过验证，@DS注解加到mapper接口、service接口、service方法里都不生效，获取的还是默认的主数据源。猜测是由于spring的aop切面机制导致拦截不到@DS注解，进而不能切换数据源，正确的做法是添加到service实现类或者实现类里具体的方法上。

在事务方法内调用@DS注解的方法，@DS注解同样不生效，原因是spring只能拦截到最外层方法的@Transactional注解，此时加载该事务的数据源，在事务方法内即使调用了@DS注解的方法，获取的是外层事务的数据源，导致@DS失效。

在同一个实现类中，一个非DS注解的常规方法里调用@DS注解的方法，同样存在@DS失效的情况，原因同2，是由spring的aop机制导致的，如果确有这种业务需要，可以将该DS注解方法定义在不同的类中，通过bean注入的方式调用，就不会出现这个问题