一种基于微服务的多数据库SQL验证方法

背景

为了增强业务产品竞争力，同一个业务功能需要开发各种数据库版本，所面临的问题是需要部署各种数据库版本的应用以支持同一个功能的多次测试，需要投入人力资源、时间资源、服务器资源。为了验证异构SQL正确性带来的这种资源浪费是可观的。为了避免这种行为，我司开发了本方案中的agent套件。

现有技术方案及缺陷

1、部署多套环境，对同一业务功能多次测试。

2、通过拦截机制获取SQL，线下使用数据库SQL转换工具处理。

1、需要投入硬件资源、人力资源、时间资源重复处理，资源消耗过多且存在人工出错可能。

2、依赖第三方工具，处理不及时、通知不及时，且存在参数对象复杂而无法处理的情况。

整体流程

实现步骤

一种微服务架构下异构SQL执行验证的方法，包括下列步骤：

S1.通过定制脚本启动包括主应用在内的其他异构配置 ，通过spring.config.location指定不同的目录来启动不同的应用实例，通过修改数据库配置来保证每个从应用实例拥有不同的数据库环境

S2 同时启动主、从应用的SpringApplication，主从应用都切入了java agent,从应用的server.port端口必须不同，且不能注册到服务注册中心，以保证从应用不接收web请求，只接收SQL请求。除此之外，当spring Application加载完成后，将记录spring上下文对象到agent相关引用中，并启动netty服务，netty服务端口号为30000+server.port。

S3 拦截主mybatis的org.apache.ibatis.executor.BaseExecutor接口中的query、update方法等发送SQL请求对象到内存有界队列，SQL请求对象包括如下部分：

其中paramObject为SQL参数对象，一般为实体；ds为当前数据源，适配mybatis plus的多数据源机制；

sql为当前主应用版本的数据库SQL，statementId为mybatis查询ID，如：

offset和limit用于分页。

S4 主应用线程把队列中的SQL请求对象，通过netty方式发往其他从节点，这些从节点的信息记录在启动脚本中，并通过agent机制传入。netty网络编解码协议间接使用了java序列化机制，以保证参数的无损传入，否则将可能失真。

S5 从应用接收到SQL请求对象，并传入S2中提及的spring上下文对象后，执行SQL，有如下几个要点：

1. 设置从执行标志，以配合S3拦截时的主从判断，以保证从SQL不被循环执行；

2. 设置com.baomidou.dynamic.datasource.toolkit.DynamicDataSourceContextHolder中的数据源为参数ds;以保证后续取的sessionFactory和数据源是正确的；

3. 通过通过sessionFactory -》Configuration -》Environment -》TransactionFactory ->Transaction获取事务，通过sessionFactory -》Configuration -》Environment -》Executor获取执行对象，即可。执行完成后清除1、2步设置的参数；

4. 在执行过程中若出错，则以生成新的文本文件，记录本次错误的上下文信息，包括原SQL、本次从应用数据库SQL、参数以及异常。便于日后下载查阅；日志文件名为时间错，如下图:

S6 若发现有新的文件生产，则发送企业微信群组或邮箱，内容包括服务器IP、错误文件路径；

S7 主机监控服务作为一个可选的服务，使用httpserver_notice.sh执行后，只要产生新的错误文件，则将以企业微信或邮箱的方式通知相关人员，告知错误文件所在服务器IP以及文件路径；

S8 主机httpserver服务作为一个可选的服务，使用httpserver_notice.sh执行后，可在Ip:10000端口打开浏览器查看或下载错误文件。