【摸鱼项目】脚本执行管理工具编写探索

前言

看这里，为了解决重复度较高及量大的脚本管理执行问题，尝试做的一个脚本管理项目（单人摸鱼开发）。

 

场景

财务小姐姐：XX客户的XX单号维护错了，现在要改为XY客户，急着要开发票，帮忙把所有信息都改一下

我：.....

这里基本就是完成状态订单修改数据，涉及N张表，跨了多个数据库下的字段修改同步。

 

需求

• 需要可跨数据库
• 脚本的线上化保存（实际就是保存一个字符串）
• 多个脚本间的相互关联，脚本的执行流
  • 参数为XX客户，修改时先需要查询其内部编码，再作为修改脚本的入参
• 日志，修改的是生产数据，安全考虑，所有执行sql都需要持久化日志

 

最终效果

图一（总体展示）

图二（执行流展示）

图三（输入框展示 react-monaco-editor）

图四（执行效果展示）

 

系统

前端为：

• 框架：react + antd-pro 
• 输入框：codemirror + react-monaco-editor （两者效果差不多，用于进行输入及展示日志）
• 执行流：react-flow

 

后端为：

• 框架：spring-boot
• DAO：mybatis-plus（用于操作该项目的表），mybatis（由mp引入，用于解析脚本）
• 前后端交互：netty（用于websocket）
• 其他：mapstruct，fastjson, jsqlparser（用于校验解析出来的sql是否会引起异常，如删库）

 

流程：

• 通过数据源管理配置数据源
• 配置SQL模板
• 配置执行流
• 输入参数，点击执行
• 创建websocket与后端对接
• 后端接收到ws请求(string)，先解析为对象，判断请求类型，调用不同类型的解析器
• 解析器将对象中的data解析为执行树（难点1）
• 根据执行树，执行每个节点，并将节点的返回值流到下一个节点中（难点2）
• 无论成功还是失败，将执行结果记录下来
• 执行过程的每一个步骤，需要同步反馈给前端（所以使用ws）, 这样比较cool(

 

脚本节点的执行：

• 先使用mybatis解析模板，获取执行的sql
• 对sql进行粗校验，保证不会引起什么需要跑路的事。
• 根据执行模板，获取服务器信息，调用JdbcTemplate进行增删改查
• 将JdbcTemplate的返回值（List<Map>或者int）向下一个节点流转
• 这期间的关键步骤都需要返回给前端，而执行SQL及结果需要存入数据库

 

总结

在公司项目的空闲期间，断断续续摸鱼编写了一个多月，上线使用（本人用）几次后：

「 嗯嗯，不好用。」

问题点有很多，最大的问题还是在于一个多月后，基本就没有了需要执行的脚本（

为啥当初辣么多脚本改到吐，当我把这个东西写完后，连个需要测试的脚本都没了，摔

.......

总的来说，问题点还在在于脚本维护难度上

如图所示，要管理大量的脚本，使用Table来展示脚本信息，会导致没有关联，记录都混杂在了一起，感觉若能像window的文件夹一样，分组模板，应该会好很多，但是无奈于技术力不够。

另外一个点就是一个执行流维护起来还是很难，如例子中，需要查客户编码，查单号对应的系统单号，几个校验，多个表的单独更新脚本，虽然使用了react-flow来增加可视化，但是就像图二所示的，配置起来会有些恶心。

或许可以把校验部分默认下来，如果没查询到相关数据，就直接中断执行，这里还是考虑的太过通用。

由于上述两个问题，导致这个摸鱼做出来的东西，咱自己还是不大愿意用，而由于最大的问题，导致目前也没机会用了，世事无常 ━(￣ー￣*|||━━

 

其他

关于执行流的前端设计，其实是参考的postman新增的Flows功能，奈何技术力不够，做出来的没有它的那么好用。

没使用redux，也没使用antd-pro的model那套做执行流的状态管理，仅使用hooks导致使用react-flow时，难度倍增，还是吃了经验的亏。这次感觉将咱前端的底蕴都给压榨出来了。

另外虽然是摸鱼项目，但应该还算公司财产，就不帖代码了，才不是由于代码没法见人（