本人想做一个cms查询框架,用于解决实际的业务问题,顺便锻炼下能力 #1 背景介绍
在一个配置管理系统即cms系统中,有很多的实体,实体间有很多的关联关系,这些实体就是构建成了一张网。如下图所示:
目前面临的问题是,如何轻松应对其他用户对实体的各种各样的查询需求?
#2 需求整理
站在用户的角度来分析需求
##2.1 用户的输入
###2.1.1 用户要查询的数据
- 可能只需要获取某些想要的字段
- 可能想获取每个实体的所有字段
###2.1.2 查询条件
-
各种各样的查询条件,如
如 =、 !=、>、<、like、in、exists 等查询条件,时间段查询等
-
查询条件间的and or 关系,以及多层条件嵌套
如 a>2 and (b>3 or c<4)
##2.2 查询输出
###2.2.1 字段对应的值的格式化
如某个表的type字段的值为0或1,需要将这些0或1转化成有意义的值,如 0表示online 1表示offline
###2.2.2 返回的数据形式的格式化
sql查询的结果是平铺的形式,然而返回给用户的希望是一个格式良好的形式,所以要求必须具备格式化的功能。
目前可能的格式化形式如下所示:
-
形式1 a下的所有的b(外层主体内容是a,然后包含一个b的集合)
{ "aName":"name1", "bs":[ { "bName":"name2" }, { "bName":"name3" } ] }
-
形式2 b的信息(外层主体是b,然后包含一个a的信息)
{ "bName":"name2", "a":{ "aName":"name1" } }
-
形式3 a下所有的b、c(外层主体是a,然后包含一个b的集合,也包含一个c的集合)
{ "aName":"name1", "bs":[ { "bName":"name2" }, { "bName":"name3" } ], "cs":[ { "cName":"name4" }, { "cName":"name5" } ] }
#3 大概的设计
-
1 用户查询封装成QueryBody
-
2 对QueryBody进行解析,解析成sql
-
3 根据sql查询出对应的结果
-
4 对sql查询的结果进行值的格式化和形式的格式化,返回满意的结果
##3.1 用户查询封装成QueryBody
QueryBody就是配置用户需求的地方。它的来源有两种方式,分别如下:
-
方式1 用户配置QueryBody的一些参数直接进行http请求
这种方式的情况下,用户需要了解QueryBody的配置意义,同时用户可以自行进行各种各样的查询
-
方式2 根据用户的查询需求,在后台配置QueryBody的参数,并映射对应的key,然后让用户拿着key来进行查询,如下
{ "key1":{QueryBody1的配置}, "key2":{QueryBody2的配置} }
用户拿着key1来查询,即我们使用key1对应的QueryBody配置来进行查询。这种方式,用户不需要关心QueryBody的配置,但只能按照我们后台所配置的参数进行查询了。方式1就不需要维护信息,方式2就需要维护key对应的QueryBody的配置信息
以上的这两种方式都可能会出现,所以都要支持。
##3.2 对QueryBody进行解析,解析成sql
这一部分其实就是一个sql生成器。这里需要说明的是,我们并不是去设计一个复杂的sql生成器,而是针对cms系统常见的查询操作能够生成sql就行了。所以不要指望这个查询框架能自动帮你生成复杂的sql。 但是有很多地方要注意:
###3.2.1 对解析要进行缓存
方便下一次相同的请求直接跳过解析过程,加快搜索。然而一旦服务器关闭,缓存就消失,所以是否要考虑将解析缓存持久化起来,在服务器启动的时候,就去先加载解析缓存。
同时允许清空缓存等操作
###3.2.2 普通查询sql的几个要素
普通sql如下所示:
select 表1.column_a,表1.column_b,表2.column_c,表3.column_d
from 表1 表2 表3
where 表1.column_e>4 and 表2.column_f='test'
主要分成三大部分:
-
第一部分 要查询的column
这一部分,可以让用户自己输入,还要进行下配置映射,避免对外暴漏数据库中的表和字段名
上述方式一般很少,所以大部分的时候还是,查询表1 表2 表3 的全部有用字段的信息,所以需要在后台配置哪些表的哪些字段需要对外暴漏。
上面的两种方式也都是要支持的
-
第二部分 表之间的连接关系
一种方式就是,直接配置表与表之间的连接关系(简单粗暴,但是会有很多的重复配置信息)
另一种方式就是,只配置两两表之间的连接关系,通过一个针对图的算法模块来找到表之间的连接关系。如博客开头的图片中,算法模块能够自动计算出entity1和entity4之间的连接关系是 entity1->entity2->entity3->entity4。这种方式大大减少了配置的冗余度。
虽然算法这一块是美好的,仍然会存在很多的问题。算法要找出最短路径,但是最短路径的连接关系不一定是用户想要的,所以有时候又不能来依靠算法,还需要人为的干预配置。如上图中的entity1到entity7有2条途径,算法只能给我们推荐一个最短的路径,但这并不一定是用户想要的,所以在这个时候,我们是需要配置使用哪条路径的
-
第三部分 查询参数部分
用户的查询条件就是一个json对象,我们要把这个json对象转化成sql中的where部分
用户的查询条件是各种各样的,同时查询条件是可以嵌套的,如下两种查询条件
{ "a.name":"lg", "b.age@>":24 }
这里就表示查询 where a.name='lg' and b.age>24
{ "a.name":"lg", "$or":{ "b.age@>":24, "c.id@in":[1,2,3] } }
这里就表示查询 where a.name='lg' and (b.age>24 or c.id in (1,2,3) )
所以希望能够做到上述的查询效果,这就需要设计一系列内置的查询参数解析器,同时方便用户自定义扩展查询参数解析器,来支持更加复杂的查询
##3.3 根据sql查询出对应的结果
这一块就需要借助于如Spring的JdbcTemplate来执行相应的sql,或者借助于其他,这就需要思考如何更加方便的接入呢?
##3.4 对sql查询的结果进行值的格式化和形式的格式化,返回满意的结果
sql的查询结果是平铺的,这时候就需要进行聚合操作,聚合操作就需要依据外层实体的主键作为聚合的重要依据了。
对数据进行格式化处理,就需要遍历查询结果,一一进行处理。然后返回给用户,如果用户还要进行相应的处理操作,又要遍历一次,造成浪费,所以该框架还要支持用户配置一些处理操作。
#4 还涉及的问题
##4.1 日志
-
该框架应该不能定死所使用的日志系统,所以需要采用slf4j这个统一的日志接口
-
对于程序中哪部分的日志采用debug级别,哪部分的日志采用info级别需要仔细考量。简单来说就是,程序的主要执行过程采用info级别,使得我们能够迅速定位错误原因就可以了,而一些详细的解析过程采用debug级别就够了。
##4.2 配置文件的监控模块
为了不用重启服务器,就能方便的发布新的API、或者改动老的API,就需要对这些配置文件进行监控。
因为这些各种各样的配置文件会很多,所以就需要把监控单独写成一个模块,方便外界随意的添加监控项。
同时还需要监控的总开关和每个监控项的子开关,来随时关闭或者打开某个监控项。
##4.3 上下文环境Context
在解析的过程中,用户的查询QueryBody,会在很多地方都要用到,如果都是作为方法的参数传递来传递去,将非常难看和难以维护,很明显这里就需要用到ThreadLocal形式了,将类似QueryBody和一些对应的缓存存储到绑定的对应的线程中,通过ThreadLocal对象来随时随地获取这些数据。最好是弄一个上下文环境来封装数据。
##4.4 异常处理
配置文件加载、解析产生的异常要进行规范的自定义处理
##4.5 集成与配置
如何更加方便的使用与配置这个cms查询框架
#5 最终达成的效果
还是如文章最上面的图
1 用户输入如下:
{
"entites":["entity1","entity2s@listentity2","entity3s@listentity3"],
"params":{
这里放置查询参数
}
}
则代表查询的是所有的entity1,以及它所包含的entity2和entity3,返回的数据格式是如下形式的:
{
"entity1Name":"aaa",
"entity2s":[
{"entity2Name":"xxx"},
{"entity2Name":"xxx"}
],
"entity3s":[
{"entity3Name":"xxx"}
]
}
2 如果用户输入如下:
{
"entites":["entity2","entity1@mapentity1"],
"params":{
这里放置查询参数
}
}
则表示用户想查询entity2的信息,并且想知道每个entity2所属的entity1信息,是如下格式的:
{
"entity2Name":"aaa",
"entity1":{
"entity1Name":"xxx"
}
}