一种基于酒行业的跨微服务、跨库的联合查询方法

摘要

本发明涉及软件技术领域，具体为一种基于酒行业的跨微服务、跨库的联合查询方法，包括以下步骤：工作流数据与业务数据通过字段进行关联；将关联的数据额外存储在文档型数据库中；基于数据库日志实现的Canal、Flink CDC工具进行数据同步；获取相关表的字段信息，构建成数据库查询语句，进行条件查询；有益效果为：本发明提出的基于酒行业的跨微服务、跨库的联合查询方法，使用非关系型数据库存储宽表数据，并使用数据同步工具对数据进行同步；为软件开发中常见的跨服务联合查询问题提供一种解决思路。

说明书

技术领域

本发明涉及软件技术领域，具体为一种基于酒行业的跨微服务、跨库的联合查询方法。

背景技术

现代软件功能越来越复杂，软件背后的实现也越来越困难。传统的软件架构难以满足如今软件开发的需要，无论是开发还是维护，都将遇到瓶颈，软件架构升级已经迫在眉睫。

现有技术中，大多数的应用是从简单到复杂一点一点积累的，到了一定的程度应用就会变得越来越庞大，也越来越难以维护，除了应用本身，应用使用到的中间件(比如数据库、缓存等)也可能会有性能瓶颈，将单个服务拆分成多个微服务是大势所趋。同样，一些中间件也需要随着服务进行拆分。微服务化能解决单体应用庞大臃肿、维护困难、结构复杂、运维困难等问题，但是也会引入其他的一些问题。

发明内容

本发明的目的在于提供一种基于酒行业的跨微服务、跨库的联合查询方法，以解决上述背景技术中提出的问题。

为实现上述目的，本发明提供如下技术方案：一种基于酒行业的跨微服务、跨库的联合查询方法，所述联合查询方法包括以下步骤：

工作流数据与业务数据通过字段进行关联；

将关联的数据额外存储在文档型数据库中；

基于数据库日志实现的Canal、Flink CDC工具进行数据同步；

获取相关表的字段信息，构建成数据库查询语句，进行条件查询。

优选的，工作流数据与业务数据通过字段进行关联时，工作流数据与业务数据在同一个数据库时，查询时进行关联查询；将服务拆分成工作流服务和业务服务后，数据库相应的也拆分成了工作流库和业务库，每个服务只访问相应的数据库，查询时无法再进行关联查询，通过服务之间调用进行数据关联。

优选的，将关联的数据额外存储在文档型数据库时，数据格式由原先扁平的行数据转变成了立体的对象文档，对象嵌套表示数据之间的关联关系。

优选的，基于数据库日志实现的Canal、Flink CDC工具进行数据同步时，数据同步工具在监听到数据变化后进行数据补全，并将补全的数据保存到文档数据库中。

优选的，获取相关表的字段信息时，从数据库schema中获取字段、字段对应的名称、字段的类型和字段的长度。

与现有技术相比，本发明的有益效果是：

本发明提出的基于酒行业的跨微服务、跨库的联合查询方法，使用非关系型数据库存储宽表数据，并使用数据同步工具对数据进行同步；为软件开发中常见的跨服务联合查询问题提供一种解决思路。

附图说明

图1为本发明方法流程图；

图2为本发明数据查询流程图；

图3为本发明对象嵌套表示数据关联关系示意图。

具体实施方式

为了使本发明的目的、技术方案进行清楚、完整地描述，及优点更加清楚明白，以下结合附图对本发明实施例进行进一步详细说明。应当理解，此处所描述的具体实施例是本发明一部分实施例，而不是全部的实施例，仅仅用以解释本发明实施例，并不用于限定本发明实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本发明保护的范围。

实施例一

请参阅图1至图2，本发明提供一种技术方案：一种基于酒行业的跨微服务、跨库的联合查询方法，所述联合查询方法包括以下步骤：

工作流数据与业务数据通过字段进行关联；

将关联的数据额外存储在文档型数据库中；

基于数据库日志实现的Canal、Flink CDC工具进行数据同步；

获取相关表的字段信息，构建成数据库查询语句，进行条件查询。

实施例二

在实施例一的基础上，具体实现方式为：

一个流程系统至少包含两部分数据，一部分是工作流相关数据，如表1所示，计作表workflow_def，一部分是与流程相关的业务数据，如表2所示，计作表business。

表1工作流部分字段

表2业务部分字段

工作流数据与业务数据通过一个或多个字段进行关联。当工作流数据与业务数据在同一个数据库时，查询时可以进行关联查询。将服务拆分成工作流服务和业务服务后，数据库相应的也拆分成了工作流库和业务库，每个服务只访问相应的数据库，查询时无法再进行关联查询，只能通过服务之间调用进行数据关联。以上面两张表为例，按照创建时间排序查询流程拥有者为“张三”的10条流程，工作流服务查询到数据后取出所有的流程定义id，然后以这些id为参数调用业务服务，业务服务查询指定流程定义id的数据并返回，流程如图1所示，

如果现在两个库都有查询条件，这种方式就无法实现了，工作流服务查询到的数据与业务服务查询到的数据的流程定义id不一定匹配，如图2。

对于这个问题，本专利提供的方案是将关联的数据额外存储在文档型数据库中，比如Elasticsearch、MongoDB。数据格式由原先扁平的行数据转变成了立体的对象文档，对象嵌套表示数据之间的关联关系，如图3所示：

引入了额外的数据库之后，还需要解决关系型数据库与文档数据库之间的数据同步问题。可以使用基于数据库日志实现的Canal、Flink CDC等工具进行数据同步，数据同步工具在监听到数据变化后进行数据补全，并将补全的数据保存到文档数据库中。

增删改查是数据天生的行为，大多数的数据都会被修改、被查询。对于多数的业务系统，查询数据是频繁的操作。大多数的查询又是指定字段的查询，比如要在工作流表workflow_def中查找流程定义名称为xx的数据，

SELECT*FROM workflow_def WHERE name＝‘xx’

如果有多个条件，就需要拼接多个条件，如果条件变动频繁，那么就需要经常改动程序，普通的查询也难以实现用户自定义查询条件。

要实现通用查询，首先需要获取相关表的字段信息，至少需要获取字段、字段对应的名称、字段的类型和字段的长度等，这些可以从数据库schema中获取，但是直接从schema中获取不一定满足需求：使用备注作为字段名称，备注中可能包含一些给开发人员使用、却不适合展示给用户的内容；并不是所有的字段都会提供给用户，有些字段没有必要提供给用户，比如id等；原始的表字段可能需要进行处理才能返回给用户。鉴于以上原因，本专利提供的方案是使用浪潮云数据湖产品或者其他相关工具，通过工具抽取数据库表字段，并提供维护这些字段的能力，通过标签指定可使用的字段，或者抽取字段时只抽取可使用的字段。通过字典维护一些字段的值对象，code表示存储在数据库中的值，label表示值对象展示的名称，比如数据库中表示性别的gender字段，配置字典为[{code:‘0’,label:‘男’},{code:‘1’,label:‘女’}]，gender值为1时表示性别女。

不同的字段类型展示的搜索框不同，数字类型的字段可以展示有范围的数字输入框，日期类型的字段可以展示有范围的日期时间输入框，其余的一般字段可以展示文本输入框。用户端在展示搜索框时需要对字段的类型进行判断，进行搜索时将用户输入内容和字段信息传输到后端，后端构建查询条件。后端在构建查询条件时需要再次判断字段的类型，这其实是没有必要的，因为用户端已经判断过一次了。用户端与后端可以约定常用的查询条件，比如日期、数字类型用BETWEEN，数据匹配用EQUAL，模糊匹配用LIKE，其他可能用到的IN、NOT_IN等，这样后端只需根据字段、条件、搜索值即可构建查询。以Java为例，后端定义查询条件枚举，

QueryCondition用来接收用户端传输的查询条件，

查询条件需要构建成数据库查询语句才能进行查询，每个查询条件根据查询的类型进行构建，EQUAL转换为field_a＝‘xx’，LIKE转换为field_b LIKE‘yy’，IN转换为field_c IN(‘oo’,‘pp’)等。在MongoDB中，查询条件可以构建为Criteria对象，转化过程在每个查询条件中，

MongoDB使用$match聚合进行条件查询，由于查询条件有多个，而且条件之间是“且”的关系，需要将条件置于$and子聚合中，

尽管已经示出和描述了本发明的实施例，对于本领域的普通技术人员而言，可以理解在不脱离本发明的原理和精神的情况下可以对这些实施例进行多种变化、修改、替换和变型，本发明的范围由所附权利要求及其等同物限定。