CN115630105A - 一种基于知识图谱的微服务架构治理方法及系统 - Google Patents

Abstract

本发明公开了一种基于知识图谱的微服务架构治理方法及系统，包括获取业务系统中微服务的结构化数据和非结构化数据；基于结构化数据和非结构化数据，构建知识图谱的微服务架构模型；基于知识图谱的微服务架构模型对业务系统进行治理；本发明利用微服务架构为拓扑结构特征，将其构建成知识图谱，通过该知识图谱能清晰的看到一个微服务的所有信息，解决了公司在微服务治理中遇到的跨部门沟通困难、微服务之间关系复杂、故障影响范围难以定位、功能涉及团队人员多，不易找到对应责任人等各种头疼的问题。

Description

一种基于知识图谱的微服务架构治理方法及系统

技术领域

本发明涉及通信技术领域，尤其涉及一种基于知识图谱的微服务架构治理方法及系统。

背景技术

随着互联网的不断发展、业务需求的日渐复杂以及产品迭代节奏的不断加快，微服务(MicroServices)架构技术在各大企业不断生根发芽。而对于一个大型企业来说，公司内部也会存在众多业务系统，每一个业务系统也可能是微服务架构组成，不同业务系统之间也会存在跨系统跨服务的调用链路追踪的问题。在微服务在研发的过程中，涉及到很多相关联的知识点和功能点设计的开发知识库，不同的微服务涉及不同的团队成员，同一团队也可能负责好几个微服务。一个微服务的模块会依赖其它众多微服务等。

随着微服务和业务系统不断的庞大和复杂，在众多的业务系统中，微服务之间的调用关系也会变得复杂和难以维护，尤其是在跨部门跨业务的情况下，我们往往所依赖的服务出现问题后不知道排查的方向，不知道所涉及的团队。在公司人员不断流动的情况下，难以找到对应的功能开发人员和相关资料知识库。随着微服务系统越来越庞大在大多数的场景下，随着公司业务变更，人员变动等，很多的数据可能并没有留存，微服务的治理也开始变得更加困难。

目前市面上对于微服务治理方案讨论较多的是基于传统的微服务的注册与发现、流量治理规则等方面的切入，其中常见方案如配置中心，注册中心，服务监控，服务熔断限流等。主要是针对服务模块进行，通过编码或是组件集成的方式对服务进行治理，但却无法描述服务之间的关系，不能够解决如上所提出的问题。

发明内容

针对上述问题中存在的不足之处，本发明提供一种基于知识图谱的微服务架构治理方法及系统。

为实现上述目的，本发明提供一种基于知识图谱的微服务架构治理方法，包括：

获取业务系统中微服务的结构化数据和非结构化数据；

基于所述结构化数据和非结构化数据，构建知识图谱的微服务架构模型；

基于所述知识图谱的微服务架构模型对所述业务系统进行治理。

优选的是，获取所述结构化数据为利用关系型数据库和知识图谱进行关系映射，将所述关系型数据库中的表与所述知识图谱的节点进行映射；

其中，所述表的外键与所述知识图谱的关系进行映射，所述表的属性与所述知识图谱的节点属性进行映射。

优选的是，所述非结构化数据包括通过接口采集文本数据、通过对工程文件进行解析和转译采集微服务之间关系以及微服务与依赖库之间的依赖关系以及API采集调用关系。

优选的是，基于所述结构化数据和非结构化数据，构建知识图谱的微服务架构模型包括：

对所述非结构数据进行抽取处理，获得实体数据、实体关系数据和实体属性；

通过Neo4j ETL工具将所述结构化数据和所述非结构数据抽取获得的数据录入图数据库；

基于所述图数据库，建立所述知识图谱的微服务架构模型。

本发明还包括一种基于知识图谱的微服务架构治理系统，包括：

采集模块，用于获取业务系统中微服务的结构化数据和非结构化数据；

构建模块，用于基于所述结构化数据和非结构化数据，构建知识图谱的微服务架构模型；

其中，基于所述知识图谱的微服务架构模型对所述业务系统进行治理。

优选的是，获取所述结构化数据为利用关系型数据库和知识图谱进行关系映射，将所述关系型数据库中的表与所述知识图谱的节点进行映射；

其中，所述表的外键与所述知识图谱的关系进行映射，所述表的属性与所述知识图谱的节点属性进行映射。

优选的是，所述非结构化数据包括通过接口采集文本数据、通过对工程文件进行解析和转译采集微服务之间关系以及微服务与依赖库之间的依赖关系以及API采集调用关系。

优选的是，基于所述结构化数据和非结构化数据，构建知识图谱的微服务架构模型包括：

对所述非结构数据进行抽取处理，获得实体数据、实体关系数据和实体属性；

通过Neo4j ETL工具将所述结构化数据和所述非结构数据抽取获得的数据录入图数据库；

基于所述图数据库，建立所述知识图谱的微服务架构模型。

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

本发明利用微服务架构为拓扑结构特征，将其构建成知识图谱，通过该知识图谱能清晰的看到一个微服务的所有信息，解决了公司在微服务治理中遇到的跨部门沟通困难、微服务之间的沟通关系复杂、故障影响范围难以定位、功能涉及团队人员多，不易找到对应责任人等各种头疼的问题。

附图说明

图1是本发明基于知识图谱的微服务架构治理方法流程图；

图2是本发明基于知识图谱的微服务架构治理方法结构图；

图3是基于知识图谱的微服务与微服务以及其他属性特性的关联关系网。

具体实施方式

为使本发明实施例的目的、技术方案和优点更加清楚，下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例是本发明的一部分实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有做出创造性劳动的前提下所获得的所有其他实施例，都属于本发明保护的范围。

本发明提供一种基于知识图谱的微服务架构治理方法，包括：

获取业务系统中微服务的结构化数据和非结构化数据；

具体地，获取结构化数据为利用关系型数据库和知识图谱进行关系映射，将关系型数据库中的表与知识图谱的节点进行映射；

其中，表的外键与知识图谱的关系进行映射，表的属性与知识图谱的节点属性进行映射。

进一步地，在表设计时要遵循以下设计规则：带有外键的表被视为连接并作为具有关系的节点导入；具有2个外键的表被视为连接表并作为关系导入；外键>2的表被视为n个中间节点，并作为具有多个关系的节点导入。在系统中，标签、标签分类、系统应用，微前端、微服务、维护团队、等数据可以作为结构化数据进行映射。

非结构数据还包括半结构化数据，非结构化数据包括通过接口采集文本数据、通过对工程文件进行解析和转译采集微服务之间关系以及微服务与依赖库之间的依赖关系以及API采集调用关系。

具体地，文本数据采集的形式比较灵活,用途上也更为广泛，像是一些接口在调用时产生的数据节点和关系使用这种方式就会比较方便和灵活，我们定义标准的文本数据采集器和采集组件，在业务系统代码中利用Agent技术把所要收集的元数据以规定的格式，产生日志文件的形式进行收集，把收集的日志文本然后按照预先定义好的语义转换规则，关系解析引擎等进行语义转换提取实体、关系和属性。例如：在业务中添加一条数据微服务，且他存在标签，并属于某个系统。那在添加的接口中可以以日志记录的形式记录:ms.log：

Data_collection_log:(MS:{“id”:123,”name”:”xxx”})-[B]->(SYS:{“id”:xxx})

Data_collection_log:(MS:{“id”:123,”name”:”xxx”})-[C]->(TAG:{“id”:xxx})

按照关系解析引擎和语义转换引擎对ms.log文件进行解析得到微服务和系统，微服务和标签的关系；

通过对工程文件的POM进行解析和转译，解析出来的依赖树本身也是一个知识图谱的数据结构，按照依赖树进行解析，把微服务与微服务之间的关系，微服务与依赖库之间的依赖关系进行采集和提取；

对于微服务之间的API调用关系的数据采集，我们可以根据组件提供的API进行上报采集。

基于结构化数据和非结构化数据，构建知识图谱的微服务架构模型；

具体地，按照上述规则通过元数据采集的方式，把系统信息、微服务信息、微服务功能信息、应用信息、团队信息，标签信息、API信息、知识库信息、微服务配置信息等元数据和他们之前相应的关系都存储在图数据库中，并建立基于知识图谱的微服务架构模型。

基于知识图谱的微服务架构模型对业务系统进行治理。

在本实施例，将系统的数据按照标准化结构数据进行建模采集，把数据库表和节点进行对齐，把数据库属性和节点属性对齐，把外键和关系对齐，可以得到节点(系统SYS)、(微服务MS)、关系：(SYS)-[C]->(MS),(MS)-[B]->(SYS)。把功能和对应的API按照业务数据，可以是接口采集的方式也可以是文本采集的方式进行采集，把API的调用关系通过接口上报的方式进行采集，通过转换后可以得到数据节点(API)、(功能FUN)；关系：(MS)-[C]->(FUN)-[C]->(API),

(MS)-[C]->(FUN)-[C]->(API)-[CALL]->(API)-[B]->(FUN)。

构建图谱：按照上述所示数据进行采集，最终构建如图2所示图谱。

应用1：分析某一个微服务的功能点的API改动后的影响范围，结合图2进行分析，

根据图数据库标准查询公式：MATCH(n:FUN)-[:C]->(:API{API.id＝xxx})RETURNn根据此公示可以查询出直接受到影响的包含此修改API的所有功能点(如在示例图中：假设API-2发生变更，则包含此API-2的微服务2的功能1会受到直接影响)。

据标准公式：MATCH(m:FUN)-[:C]->(:API)-[:Call]->(:API{API.id＝xxx})RETURN m则可以查询API修改后，直接调用此API所影响的功能范围。(在图2中，假设当微服务2的API-2发生变更，微服务1的API1调用此API-2，因为API1属于微服务1的功能1和功能2，所以当API-2发生变更微服务1的功能1和功能2也会受到影响)。

根据标准公式：

MATCH(m:FUN)-[:C]->(:API)-[:Call]->(:API)-[:Call]->(:API{API.id＝xxx})RETURN m。则可以查询出间接调用此API有可能的影响范围。(如图中API-2发生变更，API1调用API-2，而API则调用API1，从而会间接影响到微服务3中API所对应的功能)。

在上述示例中，检索分析出与此节点有关联的或者间接关联的任何节点。参考类似的检索方案，可以通过在智能分析系统中查出任一节点以及节点关系的指向的所有链路上的节点内容，可以方便的找到任一节点修改或是变更的影响范围。在基于知识图谱的微服务治理架构系统中，应用的场景还包括分析一个微服务、功能、系统维护人、日志、知识库资料，在日常生活开发中，我们可以迅速的查阅到相关资料信息，找到相关服务治理人员等。解决大多数公司在微服务治理中遇到的跨部门沟通困难、微服务之间的沟通关系复杂、故障影响范围难以定位、功能涉及团队人员多，不易找到对应责任人等一系列问题。

本发明还包括一种基于知识图谱的微服务架构治理系统，包括：

采集模块，用于获取业务系统中微服务的结构化数据和非结构化数据；

具体地，获取结构化数据为利用关系型数据库和知识图谱进行关系映射，将关系型数据库中的表与知识图谱的节点进行映射；

其中，表的外键与知识图谱的关系进行映射，表的属性与知识图谱的节点属性进行映射。

进一步地，在表设计时要遵循以下设计规则：带有外键的表被视为连接并作为具有关系的节点导入；具有2个外键的表被视为连接表并作为关系导入；外键>2的表被视为n个中间节点，并作为具有多个关系的节点导入。在系统中，标签、标签分类、系统应用，微前端、微服务、维护团队、等数据可以作为结构化数据进行映射。

非结构数据还包括半结构化数据，非结构化数据包括通过接口采集文本数据、通过对工程文件进行解析和转译采集微服务之间关系以及微服务与依赖库之间的依赖关系以及API采集调用关系。

具体地，文本数据采集的形式比较灵活,用途上也更为广泛，像是一些接口在调用时产生的数据节点和关系使用这种方式就会比较方便和灵活，我们定义标准的文本数据采集器和采集组件，在业务系统代码中利用Agent技术把所要收集的元数据以规定的格式，产生日志文件的形式进行收集，把收集的日志文本然后按照预先定义好的语义转换规则，关系解析引擎等进行语义转换提取实体、关系和属性。例如：在业务中添加一条数据微服务，且他存在标签，并属于某个系统。那在添加的接口中可以以日志记录的形式记录:ms.log：

Data_collection_log:(MS:{“id”:123,”name”:”xxx”})-[B]->(SYS:{“id”:xxx})

Data_collection_log:(MS:{“id”:123,”name”:”xxx”})-[C]->(TAG:{“id”:xxx})

按照关系解析引擎和语义转换引擎对ms.log文件进行解析得到微服务和系统，微服务和标签的关系；

通过对工程文件的POM进行解析和转译，解析出来的依赖树本身也是一个知识图谱的数据结构，按照依赖树进行解析，把微服务与微服务之间的关系，微服务与依赖库之间的依赖关系进行采集和提取；

对于微服务之间的API调用关系的数据采集，我们可以根据组件提供的API进行上报采集。

构建模块，用于基于结构化数据和非结构化数据，构建知识图谱的微服务架构模型；

具体地，按照上述规则通过元数据采集的方式，把系统信息、微服务信息、微服务功能信息、应用信息、团队信息，标签信息、API信息、知识库信息、微服务配置信息等元数据和他们之前相应的关系都存储在图数据库中，并建立基于知识图谱的微服务架构模型。

其中，基于知识图谱的微服务架构模型对业务系统进行治理。

本发明的核心就是自动化采集微服务在各环节的元数据，利用微服务天然的网状拓扑结构建立基于知识图谱的微服务治理架构模型。在本发明中需要理解如下术语‘节点’和‘关系’(这里的节点和关系均是指在图数据库中所维护的节点和关系)。

其中发明中基于知识图谱的微服务建构方案建模所使用的元数据规范如下：

节点：在图数据库中，节点用()表示。

(系统SYS)、(微服务MS)、(标签Tag)、(标签分类CTag)、(团队T)、(人员P)、(API)、(日志LOG)、(知识库K)、(配置节点Conf)、(功能FUN)。

关系：在图数据库中，关系用-[]->表示，其中>是关系的方向。

-[属于B]->、-[包含C]->、-[负责人D]->、-[依赖R]->、-[调用Call]->、

-[对应关系OTO]->。

在本实施例中，知识图谱的微服务架构模型包括应用系统管理模块、微服务管理模块、团队管理模块、标签管理模块、通用管理模块等；

应用系统管理模块在知识图谱元数据中对应建立一个节点(系统SYS)来存储应用系统的相关系统基础信息。此节点(系统SYS)基本信息包括应用系统的功能点、描述信息、应用系统的版本、应用系统的负责团队等。此模块中元数据维护的节点关系应包含如下：应用系统所包含的微服务(SYS系统节点)-[包含C]->(微服务节点MS)，此关系可以把一个系统下的微服务进行聚合，根据系统可以查询到此系统下的微服务以及所包含的微服务信息；系统的负责团队(系统SYS)-[责任人D]->(负责团队T/责任人P)，此关系用于查询系统的负责人信息；

微服务管理模块主要通过微服务和与微服务相关的节点、关联关系进行维护。具体详细的：此模块提供存储的元数据节点为(微服务节点MS)，具体的此节点包含微服务基本详情信息、微服务版本等。此模块中以微服务节点为中心所维护的关系为：微服务所包含的功能和API关系(微服务MS)-[包含C]->(功能FUN)-[包含C]->(API)、微服务所依赖的服务(微服务MS)-[依赖R]->(微服务MS)、微服务所调用的其他服务的API(微服务)-[Call]->(API)，微服务对应的日志(微服务MS)-[对应OTO]->(日志LOG)、微服务所包含的标签与所属分类(微服务MS)-[包含C]->(标签Tag)-[属于B]->(标签分类CTag)、微服务所属的知识库(微服务MS)-[对应OTO]->(知识库K)、微服务所指向的配置(微服务)-[对应OTO]->(配置)；

团队管理模块对一些人员信息进行聚合，在实际公司项目中，每个人可能同时负责不同的项目组，不行的项目组属于不同团队，也存在一些系统所建立的虚拟团队，此模块是为了能够把人员与项目建立更好对应关系。创建的知识图谱元数据节点为：(团队T)虚拟团队，指共同负责的某一个项目或是某个系统的人员的集合；(人员P)指某个具体的独立的用户个体。此模块所包含的关系为：团队所包含的团队人员关系(团队T)-[包含C]->(人员P)，团队中对应的负责人关系指向(团队T)-[责任人D]->(人员P)；

标签管理模块为了更好的对不同类型的节点进行聚合和分类，也为了更好的检索。此模块提供标签节点元数据：(标签节点Tag)、(标签分类CTag)。所创建的关系为(标签Tag)-[属于B]-(标签分类CTag)；

通用管理模块包含一些常规通用的节点，主要包含微服务主节点的一些扩展关联节点。其中具体的包含：接口管理节点(API节点)、知识库管理(知识库节点K)、配置管理：(配置管理节点)，日志管理(日志节点)。此模块所包含的关系为：(配置Conf)-[属于B]->(微服务MS)、API-[属于]->(微服务)、(知识库)-[属于]->(服务)。

按照上述发明内容中对元数据进行采集后，按照各模块所述的节点和关系进行知识图谱构建，整体上可以得到如图3示的基于知识图谱的微服务与微服务以及其他属性特性的关联关系网。此模型与微服务本身的关系有着相同的结构特性，是一张天然的网格数据模型。

以上仅为本发明的优选实施例而已，并不用于限制本发明，对于本领域的技术人员来说，本发明可以有各种更改和变化。凡在本发明的精神和原则之内，所作的任何修改、等同替换、改进等，均应包含在本发明的保护范围之内。

Claims (8)

1.一种基于知识图谱的微服务架构治理方法，其特征在于，包括：

获取业务系统中微服务的结构化数据和非结构化数据；

基于所述结构化数据和非结构化数据，构建知识图谱的微服务架构模型；

基于所述知识图谱的微服务架构模型对所述业务系统进行治理。

2.根据权利要求1所述的基于知识图谱的微服务架构治理方法，其特征在于，获取所述结构化数据为利用关系型数据库和知识图谱进行关系映射，将所述关系型数据库中的表与所述知识图谱的节点进行映射；

其中，所述表的外键与所述知识图谱的关系进行映射，所述表的属性与所述知识图谱的节点属性进行映射。

3.根据权利要求2所述的基于知识图谱的微服务架构治理方法，其特征在于，所述非结构化数据包括通过接口采集文本数据、通过对工程文件进行解析和转译采集微服务之间关系以及微服务与依赖库之间的依赖关系以及API采集调用关系。

4.根据权利要求3所述的基于知识图谱的微服务架构治理方法，其特征在于，基于所述结构化数据和非结构化数据，构建知识图谱的微服务架构模型包括：

对所述非结构数据进行抽取处理，获得实体数据、实体关系数据和实体属性；

通过Neo4j ETL工具将所述结构化数据和所述非结构数据抽取获得的数据录入图数据库；

基于所述图数据库，建立所述知识图谱的微服务架构模型。

5.一种基于知识图谱的微服务架构治理系统，其特征在于，包括：

采集模块，用于获取业务系统中微服务的结构化数据和非结构化数据；

构建模块，用于基于所述结构化数据和非结构化数据，构建知识图谱的微服务架构模型；

其中，基于所述知识图谱的微服务架构模型对所述业务系统进行治理。

6.根据权利要求5所述的基于知识图谱的微服务架构治理系统，其特征在于，获取所述结构化数据为利用关系型数据库和知识图谱进行关系映射，将所述关系型数据库中的表与所述知识图谱的节点进行映射；

其中，所述表的外键与所述知识图谱的关系进行映射，所述表的属性与所述知识图谱的节点属性进行映射。

7.根据权利要求6所述的基于知识图谱的微服务架构治理系统，其特征在于，所述非结构化数据包括通过接口采集文本数据、通过对工程文件进行解析和转译采集微服务之间关系以及微服务与依赖库之间的依赖关系以及API采集调用关系。

8.根据权利要求7所述的基于知识图谱的微服务架构治理系统，其特征在于，基于所述结构化数据和非结构化数据，构建知识图谱的微服务架构模型包括：

对所述非结构数据进行抽取处理，获得实体数据、实体关系数据和实体属性；

通过Neo4j ETL工具将所述结构化数据和所述非结构数据抽取获得的数据录入图数据库；

基于所述图数据库，建立所述知识图谱的微服务架构模型。

Images