服务设计-低码化设计sql转Http

一、背景

        想象一个场景，客户或者部分用户想要系统支持一些业务查询，每次提需求过来后，自己需要开放接口或者界面，然后后端开发sql实现，经过研发自测、测试、发布，然后周期少则十天半个月，多则一个月起步，中大型公司流程带来的额简单的需求仍有较差的客户体验。就在上述流程中仍有比较多的问题，比如客户发现需求传递有出入或者实现的有bug，又是一轮的调整和迭代。

         聪明的同学可能考虑到可以开放sql功能给客户自行实现，有这个想法的同学可能业务系统不够重要或者业务量太小，此种方式风险极大。数据库的数据属于系统核心数据，通常不允许随意查看，此外不合理的使用sql可能会导致数据库不稳定或者资源占用，需要控制。

        是否有一个低码化的设计，通过系统服务支持人员配置sql的方式开发Http接口，然后用户通过Http接口的方式访问系统数据库资源呢？无疑是可以的，这个过程中由专业人员审核sql保证sql被允许，此外可以在服务中再做一些防护即可。

二、Sql转Http

2.1 数据服务设计方案

2.2 服务分层说明

2.2.1、上层为web服务层，主要呈现对外提供能力

包含：

1）数据源管理：提供数据源的配置创建、修改、删除、连通性校验等内容，为sql查询提供连接信息；

2）服务开发：配置sql，url，入参，可选插件（数据转换/脱敏/缓存等），返回值配置等；

3）服务测试：通过http请求，配置入参等，测试sql转api的接口是否满足要求；

4）服务运维：

服务权限（token，白名单，黑名单，有效时长等）；

导入导出服务；

服务统计（访问量、访问平均耗时等）；

服务监控告警（调用记录；服务不可用；服务调用失败，服务调用超时等）

2.2.2、核心层，数据数据服务后端

2.2.3、底层为配置库

可选客户mysql/oracle等，也可以使用内嵌sqlLite/ignite等;

数据源配置信息，用户信息，服务配置信息；统计告警信息，系统配置信息等内容存放到配置库；