[发明专利]一种微服务架构下数据通用查询方法及查询系统

说明书

本申请公开了一种微服务架构下数据通用查询方法及查询系统，所述查询方法包括：S2：从第一数据库中拉取对应的第一数据；S4：同步接收所述数据同步服务单元的所述第一数据；S6：建立数据存储模型，并建立数据模型视图；S8：管理所述元数据；S10：通过元数据模型与所述第一数据提供查询服务，根据所述元数据模型的描述，形成对应的数据模型查询语句，调用所述统一数据仓库单元的接口进行查询。与现有技术相比，本申请所提供的微服务架构下数据通用查询方法及查询系统为解决查询次数频繁，高并发，数据实时性要求相对不高的数据查询场景，不保障写入数据的立即生效。但通过数据库定时及数据库监听的方式，保障数据的准实时性。

技术领域

一种数据查询方法及查询系统，特别涉及一种微服务架构下数据通用查询方法及查询系统。

背景技术

在互联网应用场景下，一个复杂的业务系统，通常由多个微服务组成，每个微服务一般会使用独立的数据库进行数据存储和查询。

在单一的服务下，数据的存储和查询一般都是通过数据库进行。但在复杂的业务系统中，一个业务单据使用的数据是来源于其他多个微服务来进行提供。

例如，一个报销业务单据，上面可能会引用多个其他业务对象：费用类型、承担部门、收款人银行账户等。这些都是由独立的微服务提供。而在开发或实施过程中，单据还可能会不断补充其他属性，例如工程项目报销会携带对应的工程项目，差旅类保险会增加相关的交通方式和地点说明。

基于以上情况，在报销单据的对象上会引用以上多个对象的主键，作为当前单据的属性。但在界面展现或特定业务计算时，会根据主键查询相关的数据。

请参照图1，对于数据提供方业务系统来说，一般会根据业务系统的需求，提供相关的api接口对外提供服务。这类api接口一般是为了实现某一类业务带有特定业务逻辑的专项接口。上面业务单据需要的简单的数据查询接口也可通过类似api提供。

在业务单据使用时，对于一条数据的处理过程，例如界面显示，需要根据界面显示的属性，依次调用相关服务的查询接口，业务系统需要记录所有相关的微服务提供的接口。同时，在扩展业务单据需要新的服务时，需要改写原有的代码来调用相关新的微服务提供的接口进行查询。因此改方案不利于业务系统的实现和扩展。

其次，在业务实现时，经常会出现关联多个服务查询的场景，例如在报销单审批时，查询报销单的费用承担部门的上级部门负责人对应的用户进行审批。需要传统多个对象进行查询(请参照图2)。

按服务接口提供则需要在部门上提供上级和负责人的查询接口，在员工上提供用户查询的接口

报销单调用时，需要分三次调用不同接口。需要了解部门接口的格式分别调用。或者由部门服务提供上级部门负责人对应用户的接口。这样会导致部门服务的接口根据业务场景频繁增加。

在通过api接口进行查询方案中，存在如下问题：

1、会导致实现的复杂多过高，每个查询根据业务不同要开发独立服务接口。

2、多个服务的级联调用会导致请求的时间变长，大量时间消耗在请求过程上。

3、调用链路复杂的情况下，任一服务的问题或访问链路的问题都会导致服务不可使用，导致服务的可靠性下降。

综上所述，需要提供一种通用的简单查询的服务，解决多个微服务之间，无复杂业务的简单查询的能力。

发明内容

本申请的目的在于克服上述问题或者至少部分地解决或缓解上述问题。