自定义查询系统架构设计分析

自定义查询系统架构设计分析

背景

最近参与某新自定义查询系统开发，系统是锋哥设计的，核心代码也是锋哥写的。做为一个搬砖者自下而上的分析学习一下大神的系统设计。文中的谈到架构设计内容是根据对代码理解从新整理出来的，不表明系统的实际架构和实现。同时因为业务和技术的复杂性及其余缘由，不对实现细节做说明。

设计场景

在该系统以前已经有两个自定义查询系统，一个为竞争对手的CS系统，一个为我司开发的BS系统。两个系统均用了MS SQLSERVER为数据存储和查询引擎，实现的业务功能不少，同时也有比较严重的性能问题。新系统的主要使命是用新技术提升自定义查询性能，改善可用性，同时对飙竞争对手的系统。所以也有不少设计上不合理但必须的功能。

必备知识

系统中用到了一些新技术，这些新技术或者非主流的技术是该系统实现的基石，这里作一个简单介绍。

• Elasticsearch全文搜索引擎。须要对ES的DSL查询语言和数据模型有深刻的理解。
• FreeMarker 模板引擎。前端界面及大量的模型类和数据转换类使用该技术自动生成。
• layui 前端UI组件。采用先后端分离设计，界面及一些重要的组件用此技术实现，并作了一些改造。
• RocketMQ 消息队列，在该系统中作数据同步使用。

逻辑架构

系统的主要目的是将若干业务系统的数据信息，清洗转换汇聚到ES中，利用ES在查询方面的性能优点，来实现自定义查询。系统逻辑上大概能够分为如下几个模块：

数据模型

• 什么是数据模型？
  数据模型出现的本质缘由是RDBMS与ES的数据建模方式不一样，须要一套对应规则将各业务系统的数据库表及数据对应到ES中。本系统中数据模型是什么呢？不是代码，是四张核心的excel。这四张excel是本系统的灵魂和精华所在，10万行代码本质上就是围绕这四张excel编写的，同时excel中的数据固化到元数据库中。

• 数据模型解决了什么问题？

  • 数据从哪里来的问题
    定义了从哪些子系统中获取什么数据及数据的关联方式
  • 数据到哪里去的问题
    定义了在ES中数据存储到哪几个索引、类型和数据文档嵌套方式
  • 查什么数据的问题
    定义了系统中能够查询哪些字段和展现哪些数据字段
  • 怎么查数据的问题
    定义了数据字段在ES中的路径和不一样字段类型在ES中使用的查询方式及结果集处理方式

数据同步

经过如下几个主要的步骤实现数据从业务库到ES中的同步：

• 业务系统中埋点或者数据库触发器将要同步的元信息推送到MQ
• 消费端（新自定义查询）将要同步的数据以任务的形式落库
• 新自定义查询系统定时的根据任务从其余系统拉取数据
• 将拉取的数据作清洗转换导入到ES集群

数据清洗

系统经过如下几个步骤实现数据的装载和转换：

• 根据同步任务，各批量装载器实现业务数据的加载
• 将数据转换的中间结果落盘
• 从磁盘中读出中间数据，各转换器转换后，导入到ES。

查询引擎

• 什么是查询引擎？
  查询引擎主要将前台页面选择的条件和展现字段、排序方式、分页方式、数据合并方式等在后台转换成ES的DSL查询语言并查询出结果。是系统最重要的模块，同时也是代码逻辑最复杂的模块。

• 查询条件的组合方式
  从组合方式上来讲，查询条件有与、或、非、异或、全或几种组合，分别对应着DSL的 must、should、must_not 和其组合。

• 值的比较方式
  从值的比较方式上来讲，主要有精确匹配、范围匹配、前缀匹配、模糊匹配等，分别对应着DSL的term、terms、range、prefix、wildcard等

• ES的数据建模方式
  从ES的数据建模方式来看，查询主要能够分为嵌套查询、父子查询、子父查询、父子+嵌套查询等

系统主要以流水线得思想将一个复杂的查询拼装，分配给各组件完成，并统一组装，主要有嵌套查询流水线、父子查询流水线、子父查询流水线等

模板引擎

模板引擎主要将大量重复劳动或者须要灵活变更或者特殊对应关系的代码用模板生成，主要生成前端Html、pojo类，mapper映射和其余元数据磁盘缓存等。

对外服务

• 对外服务主要提供了将ES中的数据以某种方式输出，提供给外部系统。

系统总结

首先，优势:

• 实现了系统的使命，查询性能有很大提升，且因为ES的横向可扩展性，数据量增大也能保证基本查询性能。
• 引入了新技术新模式，为解决相似问题提供了另一条思路。且对ES的深刻使用，应该是走到了研发中心各团队的前面。
• 其设计思想和部分代码能够复用借鉴到其余项目。

其次，缺点：

• 不只要有新技术新模式，更要引入新思想新用法。还按照传统的方法去使用ES，引入了几个疑难问题，好比复杂排序问题和深分页问题(解决方法参见本人博客)。
• 设计思想的执行和代码质量由于交付压力大打折扣，代码上有很强的业务耦合，比较难作到直接复用。
• 数据同步设计有待商榷，好比数据同步的及时性和稳定性及对其余系统的压力。
• 查询引擎代码有很多重复且后续逻辑有点混乱，耦合度高。
• 对ES等新技术的特性研究还不够，掉入了一些坑里。