在微服务改造和国产化适配这两股浪潮的交叉点上“若依微服务里配 MySQL DM 双数据源”是一个绕不开的经典需求。很多团队在信创环境下拿到一套若依Cloud第一步不是加业务代码而是琢磨怎么在不破坏原有权限体系的前提下让业务模块能同时读写关系型数据。先说清楚这套方案是干嘛的。它解决的问题非常具体默认的若依微服务框架只配置了一个数据源要么全库MySQL要么全库达梦。但实际交付中经常碰到两种情况——旧系统数据留在MySQL里新模块必须落到达梦上或者一套代码要交付给两个不同的最终用户一个要求MySQL另一个指定了达梦。如果直接在代码里硬写两套连接改起来痛苦维护成本更高。用抽象数据源加自定义注解的路子可以做到业务代码无感知请求到达Mapper时自动切换到底层数据库。适合正在做国产化迁移的团队、接手若依二开的开发者以及想搞明白多数据源路由原理的读者。这篇文章我会从整体设计思路开始拆解为什么选注解加AOP方案而不是简单配两个数据源然后给到核心的代码实现、配置项解析再附上我实际踩过的坑和排查思路。所有代码基于常见的若依Cloud版本理论上适配大多数分支。1. 整体设计与思路拆解1.1 为什么不能简单配两个数据源如果只是“能连上两种数据库”Spring Boot自带的配置确实够用——把两个DataSource定义出来注入到不同Mapper里各用各的。但放到若依微服务这种框架里这种思路有几个很现实的问题。首先是事务问题。若依很多Service是带Transactional的如果底层连着两个独立数据源一个业务方法里同时操作MySQL和达梦Spring默认的事务管理器只会管其中一个。数据不一致了排查起来极痛苦表面看是配置问题实际是事务边界失控。其次是代码侵入性。多数据源的硬编码意味着所有Mapper、Service都要指定“我连的是哪个库”一两个模块还好几十个模块就变成维护灾难。团队成员稍不留意新写的Mapper没有指定数据源默认走主库排查起来要命。还有一层是环境迁移成本。交付时如果用户要求换数据库硬编码的方案等于要把所有Mapper的注解全部改一遍。用路由方案的话只需要改配置文件和SQL方言代码层基本不用动。所以我更倾向于“路由式多数据源”——框架只注册一个主数据源入口通过AOP切面和自定义注解动态决定当前线程走哪个数据源。核心思想不复杂每个方法执行前根据注解里的DS(dm)这样的标记把一个数据源标识塞进ThreadLocal方法执行完再把这个标识清理掉。底层数据库连接池是多个但业务代码看到的永远是一个DataSource接口连接是在getConnection()时才被路由到真正的库里。这跟城市里设公交总站很类似线路很多但乘客在同一个站点上车闸机自动把人分流到对应线路。1.2 方案选型自定义注解 AOP 的优势市面上现成的动态数据源组件不少但放到若依里集成还是自己封装更可控。拿内部架构来看若依本身有很成熟的SpringUtils、SecurityUtils这些工具类包装一下不费劲。而且开源动态数据源组件功能很重像分库分表、读写分离这些在项目里根本用不上白白增加复杂度。自己实现也就是一个注解类、一个切面类、一个动态数据源类总共三个核心文件。选择自定义方案还有几层考量一是和若依框架的契合度。若依的Mapper层通常是单参数或实体参数自定义注解在方法级别拦截基本不会跟MyBatis的代理逻辑冲突。切面只需要拦截Service层的公开方法简单又干净。二是权限体系不会被破坏。若依的SysUser权限、Token校验都在网关和SecurityFilter里处理数据源切换只发生在Service层调用链中上层逻辑完全无感知。三是在排错上自己写的代码理得清调用关系。出了问题能直接定位是切面没触发、注解没生效还是数据库连接本身有问题。用开源组件万一兼容性翻车光看组件源码就够折腾半天。1.3 整体结构预览整套方案最终落地是这几个层次配置层application.yml里定义master和dm两个数据源连接信息。路由层DynamicDataSource继承AbstractRoutingDataSource重写determineCurrentLookupKey()方法从ThreadLocal拿数据源标识。切面层DataSourceAspect拦截带DataSource注解的方法执行前设置标识执行后清除。使用层业务代码在Service方法或类级别加上DataSource(dm)注解声明这个业务走达梦。这个结构和“配置中心 路由表 交通指挥员”的模型完全对应核心就是数据源标识的传递和动态解析。2. 核心细节解析与实操要点2.1 自定义注解的设计细节先看注解定义import java.lang.annotation.*; Target({ElementType.METHOD, ElementType.TYPE}) Retention(RetentionPolicy.RUNTIME) Documented public interface DataSource { String value() default master; }注解本身很简单但有两个细节容易出问题。第一是Target为什么要同时声明METHOD和TYPE。这涉及到Spring AOP的继承机制。如果某个Service接口没有注解但实现类上有Spring对实现类做代理时是能识别到的。反过来如果注解标在接口方法上部分代理模式会失效。为了系统严谨我建议用法上统一Service实现类上加注解并且容忍类级别注解的配置。TYPE的声明会让“切面直接检查类上注解”变为可能安全性更高。第二是value的默认值。设为master意味着“不注明就是主库”这很符合框架习惯——绝大多数查询走主库只有明确要求的模块才切到达梦。提示注解名用DataSource比较直观但注意别和某些组件自带的同名注解弄混。实际集成中如果项目里塞了多个动态数据源依赖可能会冲突。出问题时用全限定名导入就能区分。2.2 动态数据源路由核心动态数据源的核心类在Spring里已经现成了就是AbstractRoutingDataSource。看名字也知道这个类设计出来就是干这个事的。import org.springframework.jdbc.datasource.lookup.AbstractRoutingDataSource; public class DynamicDataSource extends AbstractRoutingDataSource { Override protected Object determineCurrentLookupKey() { return DataSourceContextHolder.getDataSource(); } }关键在于DataSourceContextHolder它的本质就是一个ThreadLocal包装public class DataSourceContextHolder { private static final ThreadLocalString CONTEXT_HOLDER new ThreadLocal(); public static void setDataSource(String dataSourceType) { CONTEXT_HOLDER.set(dataSourceType); } public static String getDataSource() { return CONTEXT_HOLDER.get(); } public static void clearDataSource() { CONTEXT_HOLDER.remove(); } }为什么用ThreadLocal因为数据源路由要保证“这个请求走到这个分支就一路用这个数据源”但不同请求之间绝对不能串。ThreadLocal天然把变量隔离在各自的线程里互相不干扰。实际配置DynamicDataSource时AbstractRoutingDataSource里有几个关键方法setDefaultTargetDataSource()默认数据源setTargetDataSources()所有可用数据源的Map映射afterPropertiesSet()初始化时把所有DataSource解析成连接在Configuration配置类里组装Configuration public class DataSourceConfig { Bean ConfigurationProperties(spring.datasource.druid.master) public DataSource masterDataSource() { return DruidDataSourceBuilder.create().build(); } Bean ConfigurationProperties(spring.datasource.druid.dm) public DataSource dmDataSource() { return DruidDataSourceBuilder.create().build(); } Bean Primary public DynamicDataSource dataSource() { DynamicDataSource dynamicDataSource new DynamicDataSource(); MapObject, Object targetDataSources new HashMap(); targetDataSources.put(master, masterDataSource()); targetDataSources.put(dm, dmDataSource()); dynamicDataSource.setTargetDataSources(targetDataSources); dynamicDataSource.setDefaultTargetDataSource(masterDataSource()); return dynamicDataSource; } }这里有个非常关键的细节多个DataSourceBean 存在时必须用Primary标注路由数据源。否则Spring注入时会发现有两个类型匹配的Bean直接报NoUniqueBeanDefinitionException。而且这个Primary加在路由数据源上之后所有依赖DataSource的地方包括事务管理器、MyBatis的SqlSessionFactory拿到的都是路由数据源后续才能实现真正的动态切换。2.3 AOP切面的执行时机与顺序切面类负责拦截注解标记的方法Aspect Component public class DataSourceAspect { Pointcut(annotation(com.example.annotation.DataSource) || within(com.example.annotation.DataSource)) public void dataSourcePointCut() {} Before(dataSourcePointCut()) public void before(JoinPoint point) { MethodSignature signature (MethodSignature) point.getSignature(); Method method signature.getMethod(); DataSource dataSource method.getAnnotation(DataSource.class); if (dataSource null) { Class? targetClass point.getTarget().getClass(); dataSource targetClass.getAnnotation(DataSource.class); } if (dataSource ! null) { DataSourceContextHolder.setDataSource(dataSource.value()); } } After(dataSourcePointCut()) public void after() { DataSourceContextHolder.clearDataSource(); } }切点表达式里我用了annotation和within两个条件这是为了让方法级和类级注解都能被拦截。如果只写annotation类头上的注解不会触发切面这是很多人在实际应用中遇到的坑。切面Before和After的时机也讲究。切面必须在Transactional事务管理器开始之前设置数据源标识否则事务管理器已经通过路由数据源拿到了连接再切换就晚了。好在Spring中Before的执行发生在事务通知之前前提是切面本身没有额外设置低优先级。如果业务里还挂了其他切面建议给DataSourceAspect设置Order(1)这类低数值高优先级。2.4 为什么不用MyBatis原生多数据库支持有些同学会问MyBatis不是本身支持多数据库ID吗直接配置databaseIdProvider不也能区分MySQL和达梦这个思路只解决“同一套Mapper针对不同数据库写不同SQL”的问题比如一个查询MySQL用LIMIT达梦用LIMIT或ROWNUM。但它解决不了“一个Service里两个不同业务模块连不同库”的问题。DatabaseId是在全局层面选SQL方言而数据源路由是在连接层面选数据库。两者解决的问题不同且可以并存——我做完数据源切换照样可以用databaseIdProvider区分方言。达梦有一个点要注意它高度兼容Oracle语法但跟MySQL的差异也不能忽视。自增主键的写法、分页语法、某些字符串函数都有差异。如果要做代码同时支持两种库建议在Mapper里针对不同databaseId写两套SQL或者把复杂的SQL抽出来做方言适配。这个后面实操部分会演示。3. 实操过程与核心环节实现3.1 修改 application.yml 配置实际项目中若依微服务的配置通常放在Nacos里统一管理。新建模块时把application-druid.yml这样的公共配置拉出来看按下面方式扩展数据源部分spring: datasource: druid: master: url: jdbc:mysql://localhost:3306/ry_cloud?useUnicodetruecharacterEncodingutf8serverTimezoneAsia/Shanghai username: root password: root123 driver-class-name: com.mysql.cj.jdbc.Driver dm: url: jdbc:dm://localhost:5236/DMSERVER?compatibleModemysql username: SYSDBA password: SYSDBA001 driver-class-name: dm.jdbc.driver.DmDriver initial-size: 5 min-idle: 5 max-active: 20配置里有几个细节值得展开。驱动类名必须确认。MySQL 8及以上用com.mysql.cj.jdbc.Driver5.x系列用com.mysql.jdbc.Driver。达梦8的驱动类是dm.jdbc.driver.DmDriver。如果写错启动时直接报ClassNotFoundException这个倒好排查一眼就能看出来。达梦的连接URL格式。默认端口是5236DMSERVER是默认服务名实际可能要按安装实例改。注意我写了?compatibleModemysql这是让达梦在语法兼容层面尽量往MySQL靠。达梦官方提供了多种兼容模式如果项目里大量用了MySQL特有的函数这个参数能省很多改SQL的功夫。但还是要提醒兼容模式不是万能的复杂的查询建议还是单独拿到达梦客户端上执行一遍验证。Druid监控配置。若依默认用Druid连接池多个数据源时Druid的监控统计也能配多个。比如spring: datasource: druid: filter: stat: enabled: true web-stat-filter: enabled: true如果生产环境要看每个数据源的活跃连接、慢查询数把多个数据源的DruidDataSource注册到Druid监控页时需要利用StatFilter和WallFilter手动注册。默认情况下监控页只会显示一个聚合值具体单独数据源的状态可以靠Druid提供的DataSourceStatManager查看。这里先不展开想深入的话直接看Druid官方文档关于多数据源监控的部分。3.2 创建达梦数据库表结构连接信息配好之后数据库侧的准备工作不能忽略。达梦一般有两种操作方式用达梦自带的“达梦管理工具”图形化操作或者用disql命令行执行脚本。实际项目里我见过太多人把精力全放在代码上结果库表都没准备好。讲个真实感受某次联调环境上开发说“连接没问题啊能ping通”结果一执行查询就报“表或视图不存在”。因为他在MySQL里建了表但达梦库里还是空的。所以建表脚本一定要提前在达梦控制台上执行一遍。达梦建表时兼容MySQL写法还是有一些细节要注意-- 如果原来MySQL表里有这种自增主键定义 -- 在达梦中需要换成使用序列 CREATE SEQUENCE seq_ry_user START WITH 1 INCREMENT BY 1; CREATE TABLE SYSDBA.RY_USER ( USER_ID INT NOT NULL, USER_NAME VARCHAR(50), STATUS CHAR(1) DEFAULT 0, PRIMARY KEY (USER_ID) ); INSERT INTO SYSDBA.RY_USER(USER_ID,USER_NAME) VALUES (seq_ry_user.NEXTVAL, 测试用户);AUTO_INCREMENT在达梦里可以被部分兼容但最稳定的做法还是显式创建序列。还有字段注释MySQL里是COMMENT 名称达梦里必须用COMMENT ON COLUMN SYSDBA.RY_USER.USER_NAME IS 用户名称;如果原来库很大建议直接用工具迁移而不是手动跑脚本。达梦自带迁移工具可以把MySQL的表结构和数据一键迁过来同时会把AUTO_INCREMENT和COMMENT做适配能省很多事。3.3 在Service层切换数据源配置和表都就绪后使用层就很简洁了。假设现在有个需求用户同步模块走达梦其余模块走MySQL。Service里这样写Service public class SysUserSyncServiceImpl implements SysUserSyncService { Resource private DmUserMapper dmUserMapper; Override DataSource(dm) public ListDmUser selectDmUserList(DmUser dmUser) { return dmUserMapper.selectDmUserList(dmUser); } }这个写法有两个细节要说清。一是DataSource标注在实现类方法上而不是接口方法上。我们切面切的是实现类标注在接口上在某些情况下会失效尤其当CGLIB代理时。统一注解写在实现类上能避免很多诡异行为。二是方法执行完后切面会清理ThreadLocal。如果不清理线程池里的线程复用后会把数据源标识带到下一个任务出现“A请求切到了达梦B请求也跟着去了达梦”的串数据现象。这个可以说是多数据源开发中最容易踩的坑之一。加了After清理之后每次请求都是干净状态。3.4 封装Dm的Mapper支持既然有了独立数据源Mapper自然也要能在这个数据源上工作。直接在若依的Mapper层写是可行的但要建独立的Mapper接口以及对应的XML文件。简单示例Mapper接口public interface DmUserMapper { ListDmUser selectDmUserList(DmUser dmUser); int insertDmUser(DmUser dmUser); }XML里是达梦对应的SQLselect idselectDmUserList parameterTypeDmUser resultTypeDmUser SELECT user_id, user_name, status FROM RY_USER where if testuserId ! null AND user_id #{userId} /if if testuserName ! null and userName ! AND user_name LIKE CONCAT(%, #{userName}, %) /if /where /select注意一个常见的分页问题。若依自带的分页插件是PageHelper它默认会按方言自动识别数据库。多数据源情况下PageHelper识别数据库类型是靠拿到的连接来判断的理论上能正常工作。但要注意PageHelper的dialect参数不要硬编码成mysql否则查达梦数据源时生成的分页SQL不兼容。让插件自动识别即可。至于DmUser实体类字段最好和达梦表保持严格一致。如果两个库都有同一个表可以共用一个实体类但别在实体里加奇怪的联合字段。多数据源场景下实体类越干净Mapper的匹配越省心。4. 常见问题与排查技巧实录4.1 Spring事务导致切换失效现象在Service方法上同时写Transactional和DataSource(dm)发现切面设置了数据源但查询报错“连接指向的还是主库”。原因Spring事务管理器在切面之前就已经获取了数据库连接。更准确地说Transactional的事务通知优先级默认高于切面它在进入业务方法之前就决定了连接归属。事务一旦开启连接上下文已经绑定到当前线程后面再怎么切都晚了。解决思路非事务类操作避免在标记了DataSource(dm)的方法上加重型事务注解。如果事务必须存在把数据源的初始化放在事务管理器创建连接之前比如在配置里就把事务管理器绑定到路由数据源上。另一种做法是在同一个事务内始终使用同一种数据源不要在一个标记了Transactional的大方法内部去切换多个数据源拆分成多个独立Service方法各自指定数据源。变通技巧如果确实要在一个完整事务里同时跨MySQL和达梦简单的Transactional已无法覆盖这是全局事务的问题。轻量级方案是用消息表加最终一致性代替强事务如果非要强一致需要引入分布式事务框架比如Seata但这属于另一个层面的话题至少在若依框架里不建议自己硬写。4.2 异步线程丢失数据源标识现象在Controller里调用了带Async的Service方法方法上标了DataSource(dm)结果异步执行时查了主库。原因Async会把任务提交到线程池执行新线程里没有原来那个ThreadLocal的数据。数据源标识只存在于提交任务的线程异步线程拿不到。解决思路尽量在异步方法内部再次标注DataSource(dm)让异步线程自己设置数据源。或者在异步抛出之前把数据源值作为参数传进去在异步方法内部手动设置。严格来说这不是框架的问题而是ThreadLocal的天然特性。理解这一点后排查起来就快了。4.3 切面拦截不到Service方法现象注解标了切面也定义了但DataSourceContextHolder里始终是空。排查思路先确认代理是否生效。Spring AOP默认用JDK动态代理若依的Service大多是接口加实现的结构如果注解标在实现类方法上理论上CGLIB或JDK代理都能拦截。但如果Service方法被final修饰CGLIB无法增强。另外检查切面类是否被Spring扫描到很多情况是Aspect注解忘了配Component导致切面根本没注册。再检查切点签名。annotation(com.example.annotation.DataSource)这种写法要求注解的Retention是RUNTIME否则运行时反射拿不到。这个坑虽然基础但确实有人踩。最后切面里做的方法判断。如果方法上有注解就直接用方法注解如果方法上没有再看类上是否有。顺序错了也可能拿到不同结果。4.4 达梦连接被Druid回收或连接泄漏现象长时间运行后偶尔报“无可用连接”或者连接池指标异常。原因数据源切换场景下连接是按需向Druid池申请的。如果某个方法标记了DataSource(dm)但执行过程中抛了异常After清理了ThreadLocal但连接本身如果没有归还池子就会慢慢耗尽。正常情况下MyBatis的SqlSession会在finally块里把连接关掉归还但如果事务拦截器异常或者连接被借用后没正常返回就容易泄漏。解决思路DruidDataSource配置里设置max-active和min-idle同时开启testWhileIdle和time-between-eviction-runs-millis让空闲连接能被正常回收。关注After和AfterReturning/AfterThrowing的区别。如果数据源清理放在AfterReturning异常分支就不会执行清理导致数据源状态残留。建议用After保证清理必定执行。在代码里显式配置连接回收周期spring: datasource: druid: time-between-eviction-runs-millis: 60000 min-evictable-idle-time-millis: 300000 validation-query: SELECT 1 test-while-idle: true4.5 MySQL和达梦SQL方言差异速查表功能MySQL达梦兼容MySQL模式建议自增主键AUTO_INCREMENT序列SEQUENCE通过工具迁移时自动处理手工建表建序列分页LIMIT m, n兼容MySQL模式下可用LIMIT或用ROWNUM用PageHelper自动识别方言字符串拼接CONCAT() 函数兼容模式支持避免在复杂查询中混合拼接日期函数NOW(), DATE_FORMAT()NOW()可用DATE_FORMAT可能需调整尽量用标准函数布尔类型TINYINT(1)TINYINT兼容性较好全文索引原生支持第三方组件或全文索引能力不同评估业务依赖程度达梦有一个特点差不多所有信创项目里都会遇到虽然兼容模式帮你挡了一部分SQL差异但索引设计、存储过程编写、字段类型长度这些还是需要在达梦环境里亲自验证。尤其存储过程如果用了MySQL的DELIMITER自定义分隔符达梦里根本不认这套。4.6 配置项参考清单配置项推荐值说明initial-size5初始连接数max-active20最大活跃连接数min-idle5最小空闲连接数validation-querySELECT 1连接可用性检查test-while-idletrue空闲连接定期检查time-between-eviction-runs-millis60000驱逐线程运行间隔max-wait10000获取连接最大等待毫秒数这些值不是死的需要根据并发压力调优。核心思路是“探测要频繁等待要短空闲要及时回收”。5. 踩坑总结与扩展建议5.1 若依本身封装带来的“隐藏坑”若依微服务的DataSource注解其实在某些官方版本里是存在的但覆盖不完全。我们项目组最初直接用框架自带的注解发现部分场景无效。翻源码才发现若依自带的DataSourceAspect只做了方法级拦截类级注解没覆盖。因此如果你在类上标注了行为就变得不可预期。这种情况建议不用框架自带的切面直接引入自己写的这套能保证行为一致。还有一个点是若依的EnableAutoConfiguration配置比较多如果DataSourceConfig写的位置不当可能被其他自动配置覆盖。建议把DynamicDataSource的配置类放到模块的config包下并确保它能被组件扫描扫到。5.2 后续可以扩展的功能这套方案做好之后很多相关的增强能力都能自然扩展主从分离在路由Map里加一个slave数据源切面加一个“只读方法走从库”的规则不需要额外引入架构变化。多数据库支持路由Map里加更多Key比如oracle、postgresql每个数据源一个Key业务层按需选择。数据源健康检查定时任务里轮询每个数据源连接失败能告警。Druid自带的监控已经能提供大部分指标直接对接告警平台就行。灰度切换通过配置中心动态改targetDataSources的Map实现不停机切换数据库不过这个对代码结构要求高一些。5.3 最终一点关于配置管理的建议多数据源配置千万不要硬编码在本地application.yml里。如果用了若依Cloud配置统一放在Nacos的对应配置文件中管理并且注意区分环境dev、test、prod环境的数据源地址、账号密码都不一样建议单独建配置文件避免联调时误连生产库。我个人的习惯是数据源配置单独抽一个datasource.yml文件仅配置数据源相关的所有参数模块共享时引入即可。改数据库地址、切换账号密码完全不用碰到业务代码和主配置文件。这套做法在多个项目里用下来团队配合效率高很多上线时出问题的概率也小很多。回到最初的需求上很多人以为“多数据源就是配两个连接串”搞完才发现真正麻烦的是事务、异步、方言这些连带问题。希望这篇操作笔记能帮各位少走弯路。按这个思路配好之后代码层面完全无感知业务开发该怎么写就怎么写底层数据库的切换交给AOP去处理这本身就是最顺手的玩法。
在微服务改造和国产化适配这两股浪潮的交叉点上“若依微服务里配 MySQL DM 双数据源”是一个绕不开的经典需求。很多团队在信创环境下拿到一套若依Cloud第一步不是加业务代码而是琢磨怎么在不破坏原有权限体系的前提下让业务模块能同时读写关系型数据。先说清楚这套方案是干嘛的。它解决的问题非常具体默认的若依微服务框架只配置了一个数据源要么全库MySQL要么全库达梦。但实际交付中经常碰到两种情况——旧系统数据留在MySQL里新模块必须落到达梦上或者一套代码要交付给两个不同的最终用户一个要求MySQL另一个指定了达梦。如果直接在代码里硬写两套连接改起来痛苦维护成本更高。用抽象数据源加自定义注解的路子可以做到业务代码无感知请求到达Mapper时自动切换到底层数据库。适合正在做国产化迁移的团队、接手若依二开的开发者以及想搞明白多数据源路由原理的读者。这篇文章我会从整体设计思路开始拆解为什么选注解加AOP方案而不是简单配两个数据源然后给到核心的代码实现、配置项解析再附上我实际踩过的坑和排查思路。所有代码基于常见的若依Cloud版本理论上适配大多数分支。1. 整体设计与思路拆解1.1 为什么不能简单配两个数据源如果只是“能连上两种数据库”Spring Boot自带的配置确实够用——把两个DataSource定义出来注入到不同Mapper里各用各的。但放到若依微服务这种框架里这种思路有几个很现实的问题。首先是事务问题。若依很多Service是带Transactional的如果底层连着两个独立数据源一个业务方法里同时操作MySQL和达梦Spring默认的事务管理器只会管其中一个。数据不一致了排查起来极痛苦表面看是配置问题实际是事务边界失控。其次是代码侵入性。多数据源的硬编码意味着所有Mapper、Service都要指定“我连的是哪个库”一两个模块还好几十个模块就变成维护灾难。团队成员稍不留意新写的Mapper没有指定数据源默认走主库排查起来要命。还有一层是环境迁移成本。交付时如果用户要求换数据库硬编码的方案等于要把所有Mapper的注解全部改一遍。用路由方案的话只需要改配置文件和SQL方言代码层基本不用动。所以我更倾向于“路由式多数据源”——框架只注册一个主数据源入口通过AOP切面和自定义注解动态决定当前线程走哪个数据源。核心思想不复杂每个方法执行前根据注解里的DS(dm)这样的标记把一个数据源标识塞进ThreadLocal方法执行完再把这个标识清理掉。底层数据库连接池是多个但业务代码看到的永远是一个DataSource接口连接是在getConnection()时才被路由到真正的库里。这跟城市里设公交总站很类似线路很多但乘客在同一个站点上车闸机自动把人分流到对应线路。1.2 方案选型自定义注解 AOP 的优势市面上现成的动态数据源组件不少但放到若依里集成还是自己封装更可控。拿内部架构来看若依本身有很成熟的SpringUtils、SecurityUtils这些工具类包装一下不费劲。而且开源动态数据源组件功能很重像分库分表、读写分离这些在项目里根本用不上白白增加复杂度。自己实现也就是一个注解类、一个切面类、一个动态数据源类总共三个核心文件。选择自定义方案还有几层考量一是和若依框架的契合度。若依的Mapper层通常是单参数或实体参数自定义注解在方法级别拦截基本不会跟MyBatis的代理逻辑冲突。切面只需要拦截Service层的公开方法简单又干净。二是权限体系不会被破坏。若依的SysUser权限、Token校验都在网关和SecurityFilter里处理数据源切换只发生在Service层调用链中上层逻辑完全无感知。三是在排错上自己写的代码理得清调用关系。出了问题能直接定位是切面没触发、注解没生效还是数据库连接本身有问题。用开源组件万一兼容性翻车光看组件源码就够折腾半天。1.3 整体结构预览整套方案最终落地是这几个层次配置层application.yml里定义master和dm两个数据源连接信息。路由层DynamicDataSource继承AbstractRoutingDataSource重写determineCurrentLookupKey()方法从ThreadLocal拿数据源标识。切面层DataSourceAspect拦截带DataSource注解的方法执行前设置标识执行后清除。使用层业务代码在Service方法或类级别加上DataSource(dm)注解声明这个业务走达梦。这个结构和“配置中心 路由表 交通指挥员”的模型完全对应核心就是数据源标识的传递和动态解析。2. 核心细节解析与实操要点2.1 自定义注解的设计细节先看注解定义import java.lang.annotation.*; Target({ElementType.METHOD, ElementType.TYPE}) Retention(RetentionPolicy.RUNTIME) Documented public interface DataSource { String value() default master; }注解本身很简单但有两个细节容易出问题。第一是Target为什么要同时声明METHOD和TYPE。这涉及到Spring AOP的继承机制。如果某个Service接口没有注解但实现类上有Spring对实现类做代理时是能识别到的。反过来如果注解标在接口方法上部分代理模式会失效。为了系统严谨我建议用法上统一Service实现类上加注解并且容忍类级别注解的配置。TYPE的声明会让“切面直接检查类上注解”变为可能安全性更高。第二是value的默认值。设为master意味着“不注明就是主库”这很符合框架习惯——绝大多数查询走主库只有明确要求的模块才切到达梦。提示注解名用DataSource比较直观但注意别和某些组件自带的同名注解弄混。实际集成中如果项目里塞了多个动态数据源依赖可能会冲突。出问题时用全限定名导入就能区分。2.2 动态数据源路由核心动态数据源的核心类在Spring里已经现成了就是AbstractRoutingDataSource。看名字也知道这个类设计出来就是干这个事的。import org.springframework.jdbc.datasource.lookup.AbstractRoutingDataSource; public class DynamicDataSource extends AbstractRoutingDataSource { Override protected Object determineCurrentLookupKey() { return DataSourceContextHolder.getDataSource(); } }关键在于DataSourceContextHolder它的本质就是一个ThreadLocal包装public class DataSourceContextHolder { private static final ThreadLocalString CONTEXT_HOLDER new ThreadLocal(); public static void setDataSource(String dataSourceType) { CONTEXT_HOLDER.set(dataSourceType); } public static String getDataSource() { return CONTEXT_HOLDER.get(); } public static void clearDataSource() { CONTEXT_HOLDER.remove(); } }为什么用ThreadLocal因为数据源路由要保证“这个请求走到这个分支就一路用这个数据源”但不同请求之间绝对不能串。ThreadLocal天然把变量隔离在各自的线程里互相不干扰。实际配置DynamicDataSource时AbstractRoutingDataSource里有几个关键方法setDefaultTargetDataSource()默认数据源setTargetDataSources()所有可用数据源的Map映射afterPropertiesSet()初始化时把所有DataSource解析成连接在Configuration配置类里组装Configuration public class DataSourceConfig { Bean ConfigurationProperties(spring.datasource.druid.master) public DataSource masterDataSource() { return DruidDataSourceBuilder.create().build(); } Bean ConfigurationProperties(spring.datasource.druid.dm) public DataSource dmDataSource() { return DruidDataSourceBuilder.create().build(); } Bean Primary public DynamicDataSource dataSource() { DynamicDataSource dynamicDataSource new DynamicDataSource(); MapObject, Object targetDataSources new HashMap(); targetDataSources.put(master, masterDataSource()); targetDataSources.put(dm, dmDataSource()); dynamicDataSource.setTargetDataSources(targetDataSources); dynamicDataSource.setDefaultTargetDataSource(masterDataSource()); return dynamicDataSource; } }这里有个非常关键的细节多个DataSourceBean 存在时必须用Primary标注路由数据源。否则Spring注入时会发现有两个类型匹配的Bean直接报NoUniqueBeanDefinitionException。而且这个Primary加在路由数据源上之后所有依赖DataSource的地方包括事务管理器、MyBatis的SqlSessionFactory拿到的都是路由数据源后续才能实现真正的动态切换。2.3 AOP切面的执行时机与顺序切面类负责拦截注解标记的方法Aspect Component public class DataSourceAspect { Pointcut(annotation(com.example.annotation.DataSource) || within(com.example.annotation.DataSource)) public void dataSourcePointCut() {} Before(dataSourcePointCut()) public void before(JoinPoint point) { MethodSignature signature (MethodSignature) point.getSignature(); Method method signature.getMethod(); DataSource dataSource method.getAnnotation(DataSource.class); if (dataSource null) { Class? targetClass point.getTarget().getClass(); dataSource targetClass.getAnnotation(DataSource.class); } if (dataSource ! null) { DataSourceContextHolder.setDataSource(dataSource.value()); } } After(dataSourcePointCut()) public void after() { DataSourceContextHolder.clearDataSource(); } }切点表达式里我用了annotation和within两个条件这是为了让方法级和类级注解都能被拦截。如果只写annotation类头上的注解不会触发切面这是很多人在实际应用中遇到的坑。切面Before和After的时机也讲究。切面必须在Transactional事务管理器开始之前设置数据源标识否则事务管理器已经通过路由数据源拿到了连接再切换就晚了。好在Spring中Before的执行发生在事务通知之前前提是切面本身没有额外设置低优先级。如果业务里还挂了其他切面建议给DataSourceAspect设置Order(1)这类低数值高优先级。2.4 为什么不用MyBatis原生多数据库支持有些同学会问MyBatis不是本身支持多数据库ID吗直接配置databaseIdProvider不也能区分MySQL和达梦这个思路只解决“同一套Mapper针对不同数据库写不同SQL”的问题比如一个查询MySQL用LIMIT达梦用LIMIT或ROWNUM。但它解决不了“一个Service里两个不同业务模块连不同库”的问题。DatabaseId是在全局层面选SQL方言而数据源路由是在连接层面选数据库。两者解决的问题不同且可以并存——我做完数据源切换照样可以用databaseIdProvider区分方言。达梦有一个点要注意它高度兼容Oracle语法但跟MySQL的差异也不能忽视。自增主键的写法、分页语法、某些字符串函数都有差异。如果要做代码同时支持两种库建议在Mapper里针对不同databaseId写两套SQL或者把复杂的SQL抽出来做方言适配。这个后面实操部分会演示。3. 实操过程与核心环节实现3.1 修改 application.yml 配置实际项目中若依微服务的配置通常放在Nacos里统一管理。新建模块时把application-druid.yml这样的公共配置拉出来看按下面方式扩展数据源部分spring: datasource: druid: master: url: jdbc:mysql://localhost:3306/ry_cloud?useUnicodetruecharacterEncodingutf8serverTimezoneAsia/Shanghai username: root password: root123 driver-class-name: com.mysql.cj.jdbc.Driver dm: url: jdbc:dm://localhost:5236/DMSERVER?compatibleModemysql username: SYSDBA password: SYSDBA001 driver-class-name: dm.jdbc.driver.DmDriver initial-size: 5 min-idle: 5 max-active: 20配置里有几个细节值得展开。驱动类名必须确认。MySQL 8及以上用com.mysql.cj.jdbc.Driver5.x系列用com.mysql.jdbc.Driver。达梦8的驱动类是dm.jdbc.driver.DmDriver。如果写错启动时直接报ClassNotFoundException这个倒好排查一眼就能看出来。达梦的连接URL格式。默认端口是5236DMSERVER是默认服务名实际可能要按安装实例改。注意我写了?compatibleModemysql这是让达梦在语法兼容层面尽量往MySQL靠。达梦官方提供了多种兼容模式如果项目里大量用了MySQL特有的函数这个参数能省很多改SQL的功夫。但还是要提醒兼容模式不是万能的复杂的查询建议还是单独拿到达梦客户端上执行一遍验证。Druid监控配置。若依默认用Druid连接池多个数据源时Druid的监控统计也能配多个。比如spring: datasource: druid: filter: stat: enabled: true web-stat-filter: enabled: true如果生产环境要看每个数据源的活跃连接、慢查询数把多个数据源的DruidDataSource注册到Druid监控页时需要利用StatFilter和WallFilter手动注册。默认情况下监控页只会显示一个聚合值具体单独数据源的状态可以靠Druid提供的DataSourceStatManager查看。这里先不展开想深入的话直接看Druid官方文档关于多数据源监控的部分。3.2 创建达梦数据库表结构连接信息配好之后数据库侧的准备工作不能忽略。达梦一般有两种操作方式用达梦自带的“达梦管理工具”图形化操作或者用disql命令行执行脚本。实际项目里我见过太多人把精力全放在代码上结果库表都没准备好。讲个真实感受某次联调环境上开发说“连接没问题啊能ping通”结果一执行查询就报“表或视图不存在”。因为他在MySQL里建了表但达梦库里还是空的。所以建表脚本一定要提前在达梦控制台上执行一遍。达梦建表时兼容MySQL写法还是有一些细节要注意-- 如果原来MySQL表里有这种自增主键定义 -- 在达梦中需要换成使用序列 CREATE SEQUENCE seq_ry_user START WITH 1 INCREMENT BY 1; CREATE TABLE SYSDBA.RY_USER ( USER_ID INT NOT NULL, USER_NAME VARCHAR(50), STATUS CHAR(1) DEFAULT 0, PRIMARY KEY (USER_ID) ); INSERT INTO SYSDBA.RY_USER(USER_ID,USER_NAME) VALUES (seq_ry_user.NEXTVAL, 测试用户);AUTO_INCREMENT在达梦里可以被部分兼容但最稳定的做法还是显式创建序列。还有字段注释MySQL里是COMMENT 名称达梦里必须用COMMENT ON COLUMN SYSDBA.RY_USER.USER_NAME IS 用户名称;如果原来库很大建议直接用工具迁移而不是手动跑脚本。达梦自带迁移工具可以把MySQL的表结构和数据一键迁过来同时会把AUTO_INCREMENT和COMMENT做适配能省很多事。3.3 在Service层切换数据源配置和表都就绪后使用层就很简洁了。假设现在有个需求用户同步模块走达梦其余模块走MySQL。Service里这样写Service public class SysUserSyncServiceImpl implements SysUserSyncService { Resource private DmUserMapper dmUserMapper; Override DataSource(dm) public ListDmUser selectDmUserList(DmUser dmUser) { return dmUserMapper.selectDmUserList(dmUser); } }这个写法有两个细节要说清。一是DataSource标注在实现类方法上而不是接口方法上。我们切面切的是实现类标注在接口上在某些情况下会失效尤其当CGLIB代理时。统一注解写在实现类上能避免很多诡异行为。二是方法执行完后切面会清理ThreadLocal。如果不清理线程池里的线程复用后会把数据源标识带到下一个任务出现“A请求切到了达梦B请求也跟着去了达梦”的串数据现象。这个可以说是多数据源开发中最容易踩的坑之一。加了After清理之后每次请求都是干净状态。3.4 封装Dm的Mapper支持既然有了独立数据源Mapper自然也要能在这个数据源上工作。直接在若依的Mapper层写是可行的但要建独立的Mapper接口以及对应的XML文件。简单示例Mapper接口public interface DmUserMapper { ListDmUser selectDmUserList(DmUser dmUser); int insertDmUser(DmUser dmUser); }XML里是达梦对应的SQLselect idselectDmUserList parameterTypeDmUser resultTypeDmUser SELECT user_id, user_name, status FROM RY_USER where if testuserId ! null AND user_id #{userId} /if if testuserName ! null and userName ! AND user_name LIKE CONCAT(%, #{userName}, %) /if /where /select注意一个常见的分页问题。若依自带的分页插件是PageHelper它默认会按方言自动识别数据库。多数据源情况下PageHelper识别数据库类型是靠拿到的连接来判断的理论上能正常工作。但要注意PageHelper的dialect参数不要硬编码成mysql否则查达梦数据源时生成的分页SQL不兼容。让插件自动识别即可。至于DmUser实体类字段最好和达梦表保持严格一致。如果两个库都有同一个表可以共用一个实体类但别在实体里加奇怪的联合字段。多数据源场景下实体类越干净Mapper的匹配越省心。4. 常见问题与排查技巧实录4.1 Spring事务导致切换失效现象在Service方法上同时写Transactional和DataSource(dm)发现切面设置了数据源但查询报错“连接指向的还是主库”。原因Spring事务管理器在切面之前就已经获取了数据库连接。更准确地说Transactional的事务通知优先级默认高于切面它在进入业务方法之前就决定了连接归属。事务一旦开启连接上下文已经绑定到当前线程后面再怎么切都晚了。解决思路非事务类操作避免在标记了DataSource(dm)的方法上加重型事务注解。如果事务必须存在把数据源的初始化放在事务管理器创建连接之前比如在配置里就把事务管理器绑定到路由数据源上。另一种做法是在同一个事务内始终使用同一种数据源不要在一个标记了Transactional的大方法内部去切换多个数据源拆分成多个独立Service方法各自指定数据源。变通技巧如果确实要在一个完整事务里同时跨MySQL和达梦简单的Transactional已无法覆盖这是全局事务的问题。轻量级方案是用消息表加最终一致性代替强事务如果非要强一致需要引入分布式事务框架比如Seata但这属于另一个层面的话题至少在若依框架里不建议自己硬写。4.2 异步线程丢失数据源标识现象在Controller里调用了带Async的Service方法方法上标了DataSource(dm)结果异步执行时查了主库。原因Async会把任务提交到线程池执行新线程里没有原来那个ThreadLocal的数据。数据源标识只存在于提交任务的线程异步线程拿不到。解决思路尽量在异步方法内部再次标注DataSource(dm)让异步线程自己设置数据源。或者在异步抛出之前把数据源值作为参数传进去在异步方法内部手动设置。严格来说这不是框架的问题而是ThreadLocal的天然特性。理解这一点后排查起来就快了。4.3 切面拦截不到Service方法现象注解标了切面也定义了但DataSourceContextHolder里始终是空。排查思路先确认代理是否生效。Spring AOP默认用JDK动态代理若依的Service大多是接口加实现的结构如果注解标在实现类方法上理论上CGLIB或JDK代理都能拦截。但如果Service方法被final修饰CGLIB无法增强。另外检查切面类是否被Spring扫描到很多情况是Aspect注解忘了配Component导致切面根本没注册。再检查切点签名。annotation(com.example.annotation.DataSource)这种写法要求注解的Retention是RUNTIME否则运行时反射拿不到。这个坑虽然基础但确实有人踩。最后切面里做的方法判断。如果方法上有注解就直接用方法注解如果方法上没有再看类上是否有。顺序错了也可能拿到不同结果。4.4 达梦连接被Druid回收或连接泄漏现象长时间运行后偶尔报“无可用连接”或者连接池指标异常。原因数据源切换场景下连接是按需向Druid池申请的。如果某个方法标记了DataSource(dm)但执行过程中抛了异常After清理了ThreadLocal但连接本身如果没有归还池子就会慢慢耗尽。正常情况下MyBatis的SqlSession会在finally块里把连接关掉归还但如果事务拦截器异常或者连接被借用后没正常返回就容易泄漏。解决思路DruidDataSource配置里设置max-active和min-idle同时开启testWhileIdle和time-between-eviction-runs-millis让空闲连接能被正常回收。关注After和AfterReturning/AfterThrowing的区别。如果数据源清理放在AfterReturning异常分支就不会执行清理导致数据源状态残留。建议用After保证清理必定执行。在代码里显式配置连接回收周期spring: datasource: druid: time-between-eviction-runs-millis: 60000 min-evictable-idle-time-millis: 300000 validation-query: SELECT 1 test-while-idle: true4.5 MySQL和达梦SQL方言差异速查表功能MySQL达梦兼容MySQL模式建议自增主键AUTO_INCREMENT序列SEQUENCE通过工具迁移时自动处理手工建表建序列分页LIMIT m, n兼容MySQL模式下可用LIMIT或用ROWNUM用PageHelper自动识别方言字符串拼接CONCAT() 函数兼容模式支持避免在复杂查询中混合拼接日期函数NOW(), DATE_FORMAT()NOW()可用DATE_FORMAT可能需调整尽量用标准函数布尔类型TINYINT(1)TINYINT兼容性较好全文索引原生支持第三方组件或全文索引能力不同评估业务依赖程度达梦有一个特点差不多所有信创项目里都会遇到虽然兼容模式帮你挡了一部分SQL差异但索引设计、存储过程编写、字段类型长度这些还是需要在达梦环境里亲自验证。尤其存储过程如果用了MySQL的DELIMITER自定义分隔符达梦里根本不认这套。4.6 配置项参考清单配置项推荐值说明initial-size5初始连接数max-active20最大活跃连接数min-idle5最小空闲连接数validation-querySELECT 1连接可用性检查test-while-idletrue空闲连接定期检查time-between-eviction-runs-millis60000驱逐线程运行间隔max-wait10000获取连接最大等待毫秒数这些值不是死的需要根据并发压力调优。核心思路是“探测要频繁等待要短空闲要及时回收”。5. 踩坑总结与扩展建议5.1 若依本身封装带来的“隐藏坑”若依微服务的DataSource注解其实在某些官方版本里是存在的但覆盖不完全。我们项目组最初直接用框架自带的注解发现部分场景无效。翻源码才发现若依自带的DataSourceAspect只做了方法级拦截类级注解没覆盖。因此如果你在类上标注了行为就变得不可预期。这种情况建议不用框架自带的切面直接引入自己写的这套能保证行为一致。还有一个点是若依的EnableAutoConfiguration配置比较多如果DataSourceConfig写的位置不当可能被其他自动配置覆盖。建议把DynamicDataSource的配置类放到模块的config包下并确保它能被组件扫描扫到。5.2 后续可以扩展的功能这套方案做好之后很多相关的增强能力都能自然扩展主从分离在路由Map里加一个slave数据源切面加一个“只读方法走从库”的规则不需要额外引入架构变化。多数据库支持路由Map里加更多Key比如oracle、postgresql每个数据源一个Key业务层按需选择。数据源健康检查定时任务里轮询每个数据源连接失败能告警。Druid自带的监控已经能提供大部分指标直接对接告警平台就行。灰度切换通过配置中心动态改targetDataSources的Map实现不停机切换数据库不过这个对代码结构要求高一些。5.3 最终一点关于配置管理的建议多数据源配置千万不要硬编码在本地application.yml里。如果用了若依Cloud配置统一放在Nacos的对应配置文件中管理并且注意区分环境dev、test、prod环境的数据源地址、账号密码都不一样建议单独建配置文件避免联调时误连生产库。我个人的习惯是数据源配置单独抽一个datasource.yml文件仅配置数据源相关的所有参数模块共享时引入即可。改数据库地址、切换账号密码完全不用碰到业务代码和主配置文件。这套做法在多个项目里用下来团队配合效率高很多上线时出问题的概率也小很多。回到最初的需求上很多人以为“多数据源就是配两个连接串”搞完才发现真正麻烦的是事务、异步、方言这些连带问题。希望这篇操作笔记能帮各位少走弯路。按这个思路配好之后代码层面完全无感知业务开发该怎么写就怎么写底层数据库的切换交给AOP去处理这本身就是最顺手的玩法。
