基于SPI机制修改ShardingJDBC底层，实现Nacos配置数据源

快乐早睡

已于 2024-04-10 19:11:27 修改

阅读量1.2k

点赞数 18

分类专栏：项目杂记文章标签： spring boot docker linux java

于 2024-04-10 19:09:00 首次发布

本文链接：https://blog.csdn.net/weixin_40909461/article/details/137606397

版权

本文讲述了如何在ShardingJdbc不直接支持Nacos配置的情况下，通过阅读源码并利用SPI机制，自定义扩展类实现Nacos动态配置功能的过程，包括依赖配置、SPI接口的使用以及具体代码实现。

摘要生成于 C知道，由 DeepSeek-R1 满血版支持，前往体验 >

目前最新版本的ShardingJdbc中，没有支持基于Nacos作为配置数据源的功能，经过阅读源码，发现ShardingJdbc底层是基于SPI机制来扫描的，所以决定对ShardingJdbc进行二次开发，使其可以支持Nacos的动态配置功能。

从shardingsphere-jdbc-core的 jar 包中可以发现，有些类似于SPI机制。于是开始推测，这个地方是不是可以做二次开发。

在这里插入图片描述

接着，根据这份SPI文件内部记录的类名，可以深入进行观察，发现它们都存在相同的接口。在接口中定义了accept和getContent函数，这两个函数从实现类的逻辑上看，感觉是在根据 url 的格式去判断用哪个 URLProvider 读取配置。

在这里插入图片描述
为了验证这个逻辑是否正确，在ClasspathDriverURLProvider的accept处加入断点进行观察。

这里会发现，在org.apache.shardingsphere.driver.jdbc.core.driver.ShardingSphereDriverURLManager中有一个do-while循环，它会将spi文件中的所有类都进行一次校验，如果accept返回成功，那么就会使用匹配的URLProvider对象去进行配置的进一步读取。代码如下图所示：
在这里插入图片描述
所以基本上，我们看到了这里，基本上可以想到设计思路了，自定义一个扩展类，也是采用SPI的思路去实现，在新定义的扩展类中实现对nacos的相关配置读取，然后在getContent函数中返回出去。接下来进行二次开发设计。

基于ShardingSphereDriverURLProvider接口实现SPI扩展类

这里需要用到关于shardingjdbc和nacos的依赖，相关依赖配置如下：

<dependency>
    <groupId>org.apache.shardingsphere</groupId>
    <artifactId>shardingsphere-jdbc-core</artifactId>
    <version>5.3.2</version>
</dependency>
<dependency>
    <groupId>com.alibaba.nacos</groupId>
    <artifactId>nacos-client</artifactId>
</dependency>

在golive-framework-datasource-starter模块中，编写一个基于Nacos配置的类，代码内容如下：

package org.golive.framework.datasource.starter.config;
import com.alibaba.nacos.api.NacosFactory;
import com.alibaba.nacos.api.PropertyKeyConst;
import com.alibaba.nacos.api.config.ConfigService;
import com.alibaba.nacos.api.exception.NacosException;
import