CN112199426A - 微服务架构下的接口调用管理方法、装置、服务器及介质 - Google Patents

Abstract

本发明实施例公开了一种微服务架构下的接口调用管理方法、装置、服务器及介质。该方法包括：获取服务缓存表中的服务消费者与服务生产者之间的接口调用关系，其中，服务消费者用于表示接口调用的调用发起方，服务生产者用于表示接口调用的被调用方；匹配接口调用关系与数据库中在先存储的接口调用关系；当匹配失败时，确定接口调用关系是新增接口调用关系，在数据库中存储新增接口调用关系。本发明实施例通过获取服务缓存表中的接口调用关系，将所获取的接口调用关系中的新增接口调用关系存储入数据库，实现数据库存储全量接口调用关系，解决了现有技术中无法获知组件中各个服务的被调用情况的问题，实现全局管理各个组件发布的服务接口调用关系。

Description

微服务架构下的接口调用管理方法、装置、服务器及介质

技术领域

本发明实施例涉及计算机技术，尤其涉及微服务架构下的接口调用管理方法、装置、服务器及介质。

背景技术

随着微服务和敏捷研发模式的盛行，各个互联网公司、商业银行等头部IT企业基本都转向了多项目组协同开发的分布式、频繁迭代的研发模式。这种研发模式有很多优点，比如可以更快速灵活的响应外部市场环境的变化，更早的交付用户价值，微服务松耦合的开发部署方式使得每一个组件可以由不同的团队、不同的编程语言独立进行开发和部署、降低了单个组件的复杂度等等。

然而，古语云“有一利必有一弊”，这种研发模式也给传统的研发和质量管理工作带来了很多新问题和挑战，主要是快速频繁的迭代版本意味着频率更快数量更多的变更，而每一次变更都有可能给系统带来不确定的风险，引起系统产生非预期的行为。

当系统中某个链路上的节点发生变更时，链路跟踪技术能够快速定位该节点所在链路。现有的链路跟踪技术，最早由谷歌Google在2010年提出的，当时Google发布了一篇名为“Dapper,a Large-Scale Distributed Systems Tracing Infrastructure”的论文，介绍了自研的分布式链路追踪的实现原理，还介绍了他们是怎么低成本实现对应用透明的。除了Google的Dapper，还有一些其他比较有名的链路追踪产品，比如阿里的鹰眼、大众点评的中央应用程序监控(Central Application Tracking,CAT)、推特Twitter的Zipkin以及国产开源的Skywalking等。

然而，链路跟踪技术只能定位组件中的每个服务调用了哪些外部服务，在分布式架构的开发模式下，每个项目组负责一个组件的若干服务的开发，用户视角下一个完整的业务功能和流程，会调用由很多团队开发的不同服务，每个服务又会调用由其它团队开发的服务，每个团队都只知道自己的组件调用了哪些外部服务，但是现有的链路跟踪技术无法从全局视角分析单个服务的变更影响，任何一个微小的变更往往会给整体的系统的行为带来不可控的巨大风险。因此，如何管理各个组件发布的服务接口调用关系成为亟待解决的问题。

发明内容

本发明实施例提供一种微服务架构下的接口调用管理方法、装置、服务器及介质，可以实现全局管理各个组件发布的服务接口调用关系。

第一方面，本发明实施例提供了一种微服务架构下的接口调用管理方法，包括：

获取服务缓存表中的服务消费者与服务生产者之间的接口调用关系，其中，所述服务消费者用于表示接口调用的调用发起方，所述服务生产者用于表示接口调用的被调用方；

匹配所述接口调用关系与数据库中在先存储的接口调用关系；

当匹配失败时，确定所述接口调用关系是新增接口调用关系，在所述数据库中存储所述新增接口调用关系。

第二方面，本发明实施例还提供了一种微服务架构下的接口调用管理装置，包括：

关系获取模块，用于获取服务缓存表中的服务消费者与服务生产者之间的接口调用关系，其中，所述服务消费者用于表示接口调用的调用发起方，所述服务生产者用于表示接口调用的被调用方；

关系匹配模块，用于匹配所述接口调用关系与数据库中在先存储的接口调用关系；

关系确定模块，用于当匹配失败时，确定所述接口调用关系是新增接口调用关系，在所述数据库中存储所述新增接口调用关系。

第三方面，本发明实施例还提供了一种服务器，所述服务器包括：

一个或多个处理器；

存储装置，用于存储一个或多个程序，

当所述一个或多个程序被所述一个或多个处理器执行，使得所述一个或多个处理器实现如本发明任意实施例提供的微服务架构下的接口调用管理方法。

第四方面，本发明实施例还提供了一种包含计算机可执行指令的存储介质，所述计算机可执行指令在由计算机处理器执行时用于执行如本发明任意实施例提供的微服务架构下的接口调用管理方法。

本发明实施例通过获取服务缓存表中的服务消费者与服务生产者之间的接口调用关系，并将该接口调用关系与数据库中在先存储的接口调用关系进行匹配，若匹配失败，则确定该接口调用关系是新增接口调用关系，并在数据库中进行存储，实现数据库存储全量接口调用关系，解决了现有技术中无法全面地获知组件中各个服务的被调用情况的问题，实现全局管理各个组件发布的服务接口调用关系。

附图说明

图1是本发明实施例一提供的一种微服务架构下的接口调用管理方法的流程图；

图2是本发明实施例二提供的另一种微服务架构下的接口调用管理方法的流程图；

图3是本发明实施例三提供的又一种微服务架构下的接口调用管理方法的流程图；

图4是本发明实施例四提供的又一种微服务架构下的接口调用管理方法的流程图；

图5是本发明实施例五提供的一种微服务架构下的接口调用管理装置的结构示意图；

图6为本发明实施例六提供的一种服务器的结构示意图。

具体实施方式

下面结合附图和实施例对本发明作进一步的详细说明。可以理解的是，此处所描述的具体实施例仅仅用于解释本发明，而非对本发明的限定。另外还需要说明的是，为了便于描述，附图中仅示出了与本发明相关的部分而非全部结构。

实施例一

图1是本发明实施例一提供的一种微服务架构下的接口调用管理方法的流程图，本实施例可适用于面向服务的架构模式的情况，该方法可以由微服务架构下的接口调用管理装置来执行，该装置可以采用软件和/或硬件的方式实现。该装置可配置于服务器中。如图1所示，该方法包括：

步骤S101、获取服务缓存表中的服务消费者与服务生产者之间的接口调用关系。

在微服务和敏捷研发模式下，每个组件可以由不同团队、不同的编程语言独立进行开发和部署。微服务最早由Martin Fowler与James Lewis于2014年共同提出，微服务架构风格是一种使用一套小服务来开发单个应用的方式途径，每个服务运行在自己的进程中，并使用轻量级机制通信，通常是超文本传送协定应用程序编程接口(HyperTextTransfer Protocol Application Programming Interface,HTTP API)，这些服务基于业务能力构建，并能够通过自动化部署机制来独立部署，这些服务使用不同的编程语言实现，以及使用不同数据存储技术，并保持最低限度的集中式管理。敏捷开发(Agile)是一种以人为核心、迭代、循序渐进的开发方法。在敏捷开发中，软件项目的构建被切分成多个子项目，各个子项目的成果都经过测试，具备集成和可运行的特征，敏捷研发力求在很短的周期内开发出产品的核心功能，尽早发布出可用的版本。然后在后续的生产周期内，按照新需求不断迭代升级，完善产品。

组件是对数据和方法的封装，例如业务组件是对相关数据和方法的封装，可以提供多个业务功能。服务是组件暴露在外部的接口，用于和其他组件相互调用。一个组件可以有0个、1个或多个服务，不同的组件之间可以通过服务进行相互调用。

面向服务的架构(Service-Oriented Architecture,SOA)中的服务注册中心(Enterprise Service Bus,ESB)或微服务架构的服务网关可以用于服务注册和发布，各个组件的服务统一注册到ESB或服务网关，各个组件的服务在调用外部服务时，都需要先访问ESB或服务网关，查询外部服务的真实物理地址，再访问外部服务的真实物理地址。本发明实施例的服务器可以是SOA中的ESB、微服务架构的服务网关或其他具有服务注册和发布功能的服务器，本发明对此不作具体限定。

服务缓存表可以内置于服务器中，用于存储每次接口调用的服务消费者和服务生产者，例如，服务缓存表可以是关系型数据表。其中，服务消费者用于表示接口调用的调用发起方，服务生产者用于表示接口调用的被调用方。例如，服务A和服务B是不同组件的对外接口。当服务A调用服务B时，服务A是接口调用的调用发起方，即服务A是服务消费者，服务B是接口调用的被调用方，即服务B是服务生产者。

具体地，服务器获取服务缓存表中所有的服务消费者与服务生产者之间的接口调用关系。例如，缓存表中记录了服务A调用服务B，服务器获取服务A和服务B的物理地址以及服务A和服务B之间的接口调用关系。

步骤S102、匹配接口调用关系与数据库中在先存储的接口调用关系。

具体地，服务器将服务缓存表中的服务消费者与服务生产者之间的接口调用关系与数据库中在先存储的接口调用关系进行匹配，并判断是否匹配成功。其中，数据库通过接口与服务器连接，用于存储服务消费者的物理地址、服务生产者的物理地址以及服务消费者与服务生产者之间的调用关系，可以是关系型数据库，例如，Oracle、DB2、MySQL、Microsoft SQL Server、Microsoft Access等。

示例性地，从ESB或服务网关获取服务缓存表中的服务消费者A和服务生产者B之间的调用关系为服务A调用服务B，在数据库中查询服务A调用服务B是否与数据库中存储的接口调用关系重复，若重复，则判断匹配成功，若不重复，则判断匹配失败。

步骤S103、判断匹配是否成功，若是，执行步骤S105，否则执行步骤S104。

步骤S104、确定接口调用关系是新增接口调用关系，在数据库中存储新增接口调用关系。

具体地，当匹配失败时，服务器确定服务缓存表中该匹配失败的接口调用关系是新增接口调用关系，将该新增接口调用关系存储入数据库中。

示例性地，如果查询到服务A调用服务B在数据库中没有重复记录，服务器确定服务A调用服务B是新增接口调用关系，将该新增接口调用关系插入到数据库中并进行存储。

数据库中存储全量的服务消费者与服务生产者之间的接口调用关系，用户可以在数据库中查看全量的接口调用关系，解决了现有技术中每个团队用户仅能查看自己的组件调用了哪些外部服务，无法查看自己的组件被哪些外部服务调用的技术问题，通过将一个业务功能的完整调用链路存储入数据库，每个团队用户均能够查看自己的组件被哪些外部服务调用，也能够查看全量的接口调用关系。当某个服务发生变更时，通过数据库中存储的接口调用关系，能够快速定位与该服务具有接口调用关系的其他服务，有效地避免了因服务变更而导致整体系统行为发生不可控的巨大风险。

步骤S105、确定接口调用关系非新增。

具体地，当匹配成功时，确定接口调用关系在数据库中已存在，进一步确定该接口调用关系非新增。

本发明实施例通过获取服务缓存表中的服务消费者与服务生产者之间的接口调用关系，并将该接口调用关系与数据库中在先存储的接口调用关系进行匹配，若匹配失败，则确定该接口调用关系是新增接口调用关系，并在数据库中进行存储，实现数据库存储全量接口调用关系，解决了现有技术中无法全面地获知组件中各个服务的被调用情况的问题，实现全局管理各个组件发布的服务接口调用关系。

实施例二

图2是本发明实施例二提供的另一种微服务架构下的接口调用管理方法的流程图，本实施例在上述实施例的基础上进行优化，如图2所示，该方法包括：

步骤S201、当检测到接口调用事件时，在服务缓存表中记录与接口调用事件相关的服务消费者与服务生产者之间的接口调用关系。

其中，接口调用事件是各个组件的服务在调用外部服务时触发的事件。例如，检测到各个组件的服务在调用外部服务时，访问服务器，查询外部服务的物理地址等信息，触发的接口调用事件。

具体地，当检测到组件的服务访问服务器以调用外部服务时，服务器在服务缓存表中记录与此次接口调用事件相关的服务消费者与服务生产者之间的接口调用关系。例如，当检测到服务A访问服务器以调用服务B时，服务器在服务缓存表中记录服务A调用服务B。通过服务缓存表记录接口调用关系，减少了冗余的数据传输。

步骤S202、获取服务缓存表中的服务消费者与服务生产者之间的接口调用关系。

其中，服务消费者用于表示接口调用的调用发起方，服务生产者用于表示接口调用的被调用方。

可选地，周期性地获取服务缓存表中所有的服务消费者与服务生产者之间的接口调用关系。

具体地，服务器以预设周期获取服务缓存表中所有的服务消费者与服务生产者之间的接口调用关系。其中，预设周期可以是一天、一周、一个月或其他时间。

示例性地，在每一天的凌晨、每周的周末或每个月的月末获取服务缓存表中所有的服务消费者与服务生产者之前的接口调用关系，并将获取到的接口调用关系与数据库中在先存储的接口调用关系进行匹配，若确定为新增接口调用关系，则在数据库中存储新增接口调用关系。按照预设周期获取服务缓存表中的接口调用关系，能够实现周期性地更新数据库中的接口调用关系。

可选地，获取服务缓存表中重点的服务消费者与重点的服务生产者之间的接口调用关系。

其中，重点的服务消费者用于表示由用户预设的在接口调用中起关键性作用的调用发起方，重点的服务生产者用于表示由用户预设的在接口调用中起关键性作用的被调用方。起关键性作用的服务可以是用户重点关注的服务，也可以是高危的服务，具体可以由用户根据实际需求进行预设。

具体地，用户在服务器中将在接口调用中起关键性作用的调用发起方设置为重点的服务消费者，将在接口调用中起关键性作用的被调用方设置为重点的服务生产者，服务器在获取服务缓存表中的接口调用关系时，仅获取重点的服务消费者与重点的服务生产者之间的接口调用关系。由于在用户视角下进行一个完整的业务功能和流程时，服务消费者会调用很多服务生产者，进而会涉及大量的服务消费者与服务生产者，通过仅获取服务缓存表中重点的服务消费者与重点的服务生产者之间的接口调用关系，无需获取服务缓存表中非重点的接口调用关系，能够减小运行数据量，提高运行速度，且对接口调用管理更加具有针对性。

示例性地，服务器获取服务缓存表中易发生调用错误的服务消费者与服务生产者之间的接口调用关系。通过缩减接口调用管理的接口调用关系，仅关注易发生错误的服务消费者与服务生产者之间的接口调用关系，能够实现当发生变更时对易发生错误的服务进行针对性地管理。

步骤S203、匹配接口调用关系与数据库中在先存储的接口调用关系。

步骤S204、判断匹配是否成功，若是，执行步骤S206，否则执行步骤S205。

步骤S205、确定接口调用关系是新增接口调用关系，在数据库中存储新增接口调用关系，然后执行步骤S207。

步骤S206、确定该接口调用关系非新增，然后执行步骤S207。

步骤S207、当检测到目标服务生产者的被调用关系查询指令时，查找数据库中与目标服务生产者对应的所有的服务消费者。

其中，目标服务生产者的被调用关系查询指令用于指示服务器查询调用目标服务生产者的服务消费者。目标服务生产者可以由用户指定，也可以根据微服务架构中服务的变更自动确定发生变更的服务为目标服务生产者。

具体地，当检测到目标服务生产者的被调用关系查询指令时，服务器在数据库中查找与该目标服务生产者对应的所有的服务消费者，这些服务消费者均在微服务架构下调用该目标服务生产者。

示例性地，当检测到目标服务生产者B的被调用关系查询指令时，查找数据库得到调用B的所有服务消费者A1、A2和A3。其中，A1调用B，A2调用B，A2调用B。

步骤S208、生成目标服务生产者对应的服务消费者列表。

其中，服务消费者列表用于反映目标服务生产者的被调用情况，可以通过数据表的形式存储与目标服务生产者对应的所有服务消费者。

具体地，服务器根据数据库中查找到的与目标服务生产者对应的所有服务消费者，生成目标服务生产者对应的服务消费者列表。该服务消费者列表中包括与目标服务生产者对应的所有服务消费者，可以反映该目标服务生产者的被调用情况。

示例性地，在数据库中查找到调用服务生产者B的所有服务消费者有A1、A2和A3，服务器生成B对应的服务消费者列表，该服务消费者列表中包括A1、A2和A3。

需要注意的是，步骤S201至步骤S205和步骤S206至步骤S207可以分别单独执行，也可以结合执行。步骤S201至步骤S207的顺序并不限于本实施例列举的顺序，这些步骤还可以以其他的顺序执行，例如，先执行步骤S206至步骤S207，再执行步骤S201至步骤S205。或者其他可以执行的顺序，本发明对此不作具体限定，对本领域技术人员来说能够进行各种明显的变化、重新调整和替代而不会脱离本发明的保护范围。

本发明实施例通过当检测到接口调用事件时，在服务缓存表中记录与接口调用事件相关的服务消费者与服务生产者之间的接口调用关系，将所获取的接口调用关系中的新增接口调用关系存储入数据库，当检测到目标服务生产者的被调用关系查询指令时，查找数据库中与目标服务生产者对应的所有的服务消费者，生成目标服务生产者对应的服务消费者列表。本发明实施例通过将所有接口调用关系存入数据库，实现数据库存储全量接口调用关系，通过分析接口之间的调用关系，能够分析出每个服务会被哪些服务调用，在获取各个组件发布的服务接口调用关系前提下进行服务的变更影响分析，能够减小变更给系统的性能带来的影响。并且生成服务消费者列表能够更加直观地展示调用目标服务生产者的所有服务消费者。

实施例三

图3是本发明实施例三提供的又一种微服务架构下的接口调用管理方法的流程图，本实施例在上述实施例的基础上进行优化，如图3所示，该方法包括：

步骤S301、获取服务缓存表中服务消费者的第一消费地址以及与服务消费者具有接口调用关系的服务生产者的第一生产地址，将第一消费地址与第一生产地址之间的地址访问关系作为服务消费者与服务生产者之间的接口调用关系。

其中，第一消费地址用于确定服务消费者的真实物理地址，第一生产地址用于确定服务生产者的真实物理地址。真实物理地址是固化在服务中的真实地址，用于唯一标识服务。服务消费者在调用服务生产者时，需要先访问服务器，在服务器中查询服务生产者的真实物理地址，服务消费者根据查询到的真实物理地址对服务生产者的真实物理地址进行访问，以达到接口调用的目的。

具体地，服务器获取服务缓存表中的服务消费者与服务生产者之间的接口调用关系，该接口调用关系包括服务消费者的第一消费地址、服务生产者的第一生产地址和第一消费地址与第一生产地址之间的地址访问关系。

示例性地，服务消费者A的第一消费地址为aa，服务生产者B的第一生产地址为bb，服务消费者A调用服务生产者B，即第一消费地址aa访问第一生产地址bb。服务器将第一消费地址aa与第一生产地址bb之间的地址访问关系作为服务消费者与服务生产者之间的接口调用关系。

步骤S302、匹配第一消费地址和数据库中在先存储的服务消费者的第二消费地址，匹配第一生产地址和数据库中在先存储的与第二消费地址对应的服务生产者的第二生产地址。

其中，述第二消费地址用于确定数据库中在先存储的服务消费者的真实物理地址，第二生产地址用于确定数据库中在先存储的服务生产者的真实物理地址。

具体地，服务器将服务缓存表中服务消费者的第一消费地址与数据库中在线存储的服务消费者的第二消费地址进行匹配，将服务缓存表中服务生产者的第一生产地址与数据库中在线存储的与第二消费地址对应的服务生产者的第二生产地址进行匹配。

步骤S303、判断第一消费地址与第二消费地址，或第一生产地址与第二生产地址是否匹配失败，若是，执行步骤S304，否则执行步骤S305。

步骤S304、确定第一消费地址与第一生产地址之间的地址访问关系是新增地址访问关系，在数据库中存储新增地址访问关系。

具体地，当第一消费地址与第二消费地址匹配失败，或第一生产地址与第二生产地址匹配失败时，服务器确定第一消费地址与第一生产地址之间的地址访问关系是新增地址访问关系，在数据库中存储该新增地址访问关系。

示例性地，服务器获取服务缓存表中服务消费者A的第一消费地址为aa，服务生产者B的第一生产地址为bb，第一消费地址aa访问第一生产地址bb。若在数据库中没有匹配到第一消费地址aa访问第一生产地址bb，则匹配失败，确定第一消费地址aa访问第一生产地址bb是新增地址访问关系，在数据库中存储该新增地址访问关系。

步骤S305、确定第一消费地址与第一生产地址之间的地址访问关系非新增。

具体地，当第一消费地址与第二消费地址匹配成功，且第一生产地址与第二生产地址匹配成功时，确定第一消费地址与第一生产地址之前的地址访问关系在数据库中已经存在，确定第一消费地址与第一生产地址之间的地址访问关系非新增。

示例性地，服务器获取服务缓存表中服务消费者A的第一消费地址为aa，服务生产者B的第一生产地址为bb，第一消费地址aa访问第一生产地址bb。若数据库中存在该地址访问关系，则确定第一消费地址与第一生产地址之间的地址访问关系非新增。

本发明实施例通过将服务消费者的第一消费地址与服务生产者的第一生产地址之间的地址访问关系作为服务消费者与服务生产者之间的接口调用关系，并分别与数据库中在先存储的服务消费者的第二消费地址和与第二消费地址对应的服务生产者的第二生产地址进行匹配，将新增地址访问关系存储入数据库中。本发明实施例利用真实物理地址的唯一性，实现数据库精准存储服务全量的地址访问关系，实现全局管理各个组件发布的服务的地址访问关系。

实施例四

图4是本发明实施例四提供的又一种微服务架构下的接口调用管理方法的流程图，本实施例在上述实施例的基础上进行优化，如图4所示，该方法包括：

步骤S401、获取服务缓存表中的服务消费者与服务生产者之间的接口调用关系。

其中，服务消费者用于表示接口调用的调用发起方，服务生产者用于表示接口调用的被调用方。

步骤S402、匹配接口调用关系与数据库中在先存储的接口调用关系。

步骤S403、判断接口调用关系匹配是否成功，若是，执行步骤S405，否则执行步骤S404。

步骤S404、确定接口调用关系是新增接口调用关系，在数据库中存储新增接口调用关系，然后执行步骤S406。

步骤S405、确定接口调用关系非新增。

步骤S406、根据数据库中存储的所有接口调用关系，确定每个接口所属组件的参考组件调用关系。

具体地，基于服务消费者和服务生产者分别与组件的对应关系，确定与服务消费者对应的组件消费者，以及与服务生产者对应的组件生产者，其中，组件消费者用于表示组件调用的调用发起方，组件生产者用于表示组件调用的被调用方。基于数据库中存储的服务消费者与服务生产者之间的接口调用关系、服务消费者与组件消费者的对应关系以及服务生产者与组件生产者的对应关系，确定所有组件消费者与组件生产者之间的组件调用关系。

示例性地，服务消费者A所属的组件是组件消费者AA，服务生产者B所属的组件是组件生产者BB。基于数据库中存储的服务消费者A调用服务生产者B，服务消费A者与组件消费者AA的对应关系以及服务生产者B与组件生产者BB的对应关系，确定组件AA调用组件BB。

步骤S407、过滤重复的参考组件调用关系，得到所有组件的组件调用关系。

具体地，基于步骤S406确定的参考组件调用关系中存在重复的参考组件调用关系，将重复的参考组件调用关系进行过滤，得到所有组件的组件调用关系。

示例性地，服务消费者A1所属的组件是组件消费者AA，服务生产者B1所属的组件是组件生产者BB，服务消费者A1调用服务生产者B1。服务消费者A2所属的组件是组件消费者AA，服务生产者B2所属的组件是组件生产者BB，服务消费者A2调用服务生产者B2。基于步骤S406的方法确定参考组件调用关系中包括两个组件消费者AA调用组件生产者BB，即存在重复的参考组件调用关系，过滤重复的参考组件调用关系，仅保留一个组件消费者AA调用组件生产者BB。

步骤S408、匹配组件调用关系与数据库中在先存储的组件调用关系。

具体地，将基于步骤S407得到的组件调用关系与数据库中在先存储的组件调用关系进行匹配。

步骤S409、判断组件调用关系是否匹配成功，若是，执行步骤S411，否则执行步骤S410。

步骤S410、确定组件调用关系是新增组件调用关系，在数据库中存储新增组件调用关系，然后执行步骤S412。

示例性地，若组件消费者AA调用组件生产者BB在数据库中不存在相同的匹配，则确定该组件调用关系是新增组件调用关系，在数据库中存储组件消费者AA调用组件生产者BB。

步骤S411、确定组件调用关系非新增。

步骤S412、当检测到目标组件生产者的被调用关系查询指令时，查找数据库中与目标组件生产者对应的所有的组件消费者。

其中，目标组件生产者的被调用关系查询指令用于指示服务器查询调用目标组件生产者的组件消费者。目标组件生产者可以由用户指定，也可以根据微服务架构中组件的变更自动确定发生变更的组件为目标组件生产者。

具体地，当检测到目标组件生产者的被调用关系查询指令时，服务器在数据库中查找与该目标组件生产者对应的所有的组件消费者，这些组件消费者均在组件架构下调用该目标组件生产者。

示例性地，当检测到目标组件生产者BB的被调用关系查询指令时，查找数据库中调用BB的所有组件消费者AA1、AA2和AA3。其中，AA1调用B，AA2调用B，AA2调用B。

步骤S413、生成目标组件生产者对应的组件消费者列表。

其中，组件消费者列表用于反映目标组件生产者的被调用情况，可以通过数据表的形式存储与目标组件生产者对应的所有组件消费者。

具体地，服务器根据数据库中查找到的与目标组件生产者对应的所有组件消费者，生成目标组件生产者对应的组件消费者列表。该组件消费者列表中包括与目标组件生产者对应的所有组件消费者，可以反映该目标组件生产者的被调用情况。

示例性地，在数据库中查找到调用组件生产者BB的所有组件消费者有AA1、AA2和AA3，服务器生成BB对应的组件消费者列表，该组件消费者列表中包括AA1、AA2和AA3。

需要注意的是，步骤S408至步骤S411和步骤S412至步骤S413可以分别单独执行，也可以结合执行。步骤S408至步骤S413的并不限于本实施例列举的顺序，这些步骤还可以以其他的顺序执行，例如，先执行步骤S412至步骤S413，再执行步骤S408至步骤S411。或者其他可以执行的顺序，本发明对此不作具体限定，对本领域技术人员来说能够进行各种明显的变化、重新调整和替代而不会脱离本发明的保护范围。

本发明实施例通过服务消费者与服务生产者之间的接口调用关系确定所属的组件消费者与组件生产者之间的参考组件调用关系，过滤重复的参考组件调用关系，在数据库中查找是否存在相同的组件调用关系，若不存在，将新增组件调用关系存储入数据库中，能够实现数据库存储全量组件调用关系，解决了现有技术中无法获知组件的被调用情况的问题，实现全局管理各个组件的组件调用关系。当检测到目标组件生产者的被调用关系查询指令时，将数据库中与目标组件生产者对应的所有的组件消费者以组件消费者列表的方式输出，通过分析组件之间的调用关系，能够分析出每个组件会被哪些组件调用，并且生成组件消费者列表能够更加直观地展示调用目标组件生产者的所有组件消费者。

实施例五

图5是本发明实施例五提供的一种微服务架构下的接口调用管理装置的结构示意图。该装置可由软件和/或硬件实现，一般可集成在服务器中，可以通过执行微服务架构下的接口调用管理方法实现全局管理各个组件发布的服务接口调用关系。如图5所示，该装置包括：

关系获取模块510，用于获取服务缓存表中的服务消费者与服务生产者之间的接口调用关系，其中，所述服务消费者用于表示接口调用的调用发起方，所述服务生产者用于表示接口调用的被调用方；

关系匹配模块520，用于匹配所述接口调用关系与数据库中在先存储的接口调用关系；

关系确定模块530，用于当匹配失败时，确定所述接口调用关系是新增接口调用关系，在所述数据库中存储所述新增接口调用关系。

可选地，该装置还包括：

关系记录模块，用于在获取服务缓存表中的服务消费者与服务生产者之间的接口调用关系之前，当检测到接口调用事件时，在服务缓存表中记录与所述接口调用事件相关的服务消费者与服务生产者之间的接口调用关系。

可选地，所述关系获取模块510具体用于：

周期性地获取服务缓存表中所有的服务消费者与服务生产者之间的接口调用关系。

可选地，所述关系获取模块510具体用于：

获取服务缓存表中重点的服务消费者与重点的服务生产者之间的接口调用关系，其中，所述重点的服务消费者用于表示由用户预设的在接口调用中起关键性作用的调用发起方，所述重点的服务生产者用于表示由用户预设的在接口调用中起关键性作用的被调用方。

可选地，所述关系获取模块510具体用于：

获取服务缓存表中服务消费者的第一消费地址以及与所述服务消费者具有接口调用关系的服务生产者的第一生产地址，将所述第一消费地址与第一生产地址之间的地址访问关系作为所述服务消费者与服务生产者之间的接口调用关系，其中，所述第一消费地址用于确定所述服务消费者的真实物理地址，所述第一生产地址用于确定所述服务生产者的真实物理地址。

可选地，所述关系匹配模块520具体用于：

匹配所述第一消费地址和数据库中在先存储的服务消费者的第二消费地址，匹配所述第一生产地址和所述数据库中在先存储的与所述第二消费地址对应的服务生产者的第二生产地址，其中，述第二消费地址用于确定所述数据库中在先存储的服务消费者的真实物理地址，所述第二生产地址用于确定所述数据库中在先存储的服务生产者的真实物理地址。

可选地，所述关系确定模块530具体用于：

当所述第一消费地址与第二消费地址匹配失败，或所述第一生产地址与第二生产地址匹配失败时，确定所述第一消费地址与第一生产地址之间的地址访问关系是新增地址访问关系，在所述数据库中存储所述新增地址访问关系。

可选地，所述装置还包括：

消费者查找模块，用于当检测到目标服务生产者的被调用关系查询指令时，查找数据库中与所述目标服务生产者对应的所有的服务消费者；

服务列表生成模块，用于生成所述目标服务生产者对应的服务消费者列表，其中，所述服务消费者列表用于反映所述目标服务生产者的被调用情况。

可选地，所述装置还包括：

组件确定模块，用于在在所述数据库中存储所述新增接口调用关系之后，根据所述数据库中存储的所有接口调用关系，确定每个接口所属组件的参考组件调用关系；

组件过滤模块，用于过滤重复的参考组件调用关系，得到所有组件的组件调用关系。

可选地，所述组件确定模块具体用于：

基于所述服务消费者和服务生产者分别与组件的对应关系，确定与所述服务消费者对应的组件消费者，以及与所述服务生产者对应的组件生产者，其中，所述组件消费者用于表示组件调用的调用发起方，所述组件生产者用于表示组件调用的被调用方；

基于数据库中存储的所述服务消费者与服务生产者之间的接口调用关系、所述服务消费者与组件消费者的对应关系以及所述服务生产者与组件生产者的对应关系，确定所有组件消费者与组件生产者之间的组件调用关系。

可选地，所述装置还包括：

组件存储模块，用于在得到所有组件的组件调用关系之后，匹配所述组件调用关系与数据库中在先存储的组件调用关系；

当匹配失败时，确定所述组件调用关系是新增组件调用关系，在所述数据库中存储所述新增组件调用关系。

可选地，所述装置还包括：

组件查找模块，用于在在所述数据库中存储所述新增组件调用关系之后，当检测到目标组件生产者的被调用关系查询指令时，查找所述数据库中与所述目标组件生产者对应的所有的组件消费者；

组件列表生成模块，用于生成所述目标组件生产者对应的组件消费者列表，其中，所述组件消费者列表用于反映所述目标组件生产者的被调用情况。

本发明实施例所提供的微服务架构下的接口调用管理装置可执行本发明任意实施例所提供的微服务架构下的接口调用管理方法，具备执行方法相应的功能模块和有益效果。

实施例六

图6为本发明实施例六提供的一种服务器的结构示意图，如图6所示，该服务器包括处理器600、存储器610、输入装置620和输出装置630；服务器中处理器600的数量可以是一个或多个，图6中以一个处理器600为例；服务器中的处理器600、存储器610、输入装置620和输出装置630可以通过总线或其他方式连接，图6中以通过总线连接为例。

存储器610作为一种计算机可读存储介质，可用于存储软件程序、计算机可执行程序以及模块，如本发明实施例中的微服务架构下的接口调用管理方法对应的程序指令和/或模块(例如，微服务架构下的接口调用管理装置中的关系获取模块510、关系匹配模块520和关系确定模块530)。处理器600通过运行存储在存储器610中的软件程序、指令以及模块，从而执行服务器的各种功能应用以及数据处理，即实现上述的微服务架构下的接口调用管理方法。

存储器610可主要包括存储程序区和存储数据区，其中，存储程序区可存储操作系统、至少一个功能所需的应用程序；存储数据区可存储根据终端的使用所创建的数据等。此外，存储器610可以包括高速随机存取存储器，还可以包括非易失性存储器，例如至少一个磁盘存储器件、闪存器件、或其他非易失性固态存储器件。在一些实例中，存储器610可进一步包括相对于处理器600远程设置的存储器，这些远程存储器可以通过网络连接至服务器。上述网络的实例包括但不限于互联网、企业内部网、局域网、移动通信网及其组合。

输入装置620可用于接收输入的数字或字符信息，以及产生与服务器的用户设置以及功能控制有关的键信号输入。输出装置630可包括显示屏等显示设备。

实施例七

本发明实施例七还提供一种包含计算机可执行指令的存储介质，所述计算机可执行指令在由计算机处理器执行时用于执行一种微服务架构下的接口调用管理方法，该方法包括：

获取服务缓存表中的服务消费者与服务生产者之间的接口调用关系，其中，所述服务消费者用于表示接口调用的调用发起方，所述服务生产者用于表示接口调用的被调用方；

匹配所述接口调用关系与数据库中在先存储的接口调用关系；

当匹配失败时，确定所述接口调用关系是新增接口调用关系，在所述数据库中存储所述新增接口调用关系。

当然，本发明实施例所提供的一种包含计算机可执行指令的存储介质，其计算机可执行指令不限于如上所述的方法操作，还可以执行本发明任意实施例所提供的微服务架构下的接口调用管理方法中的相关操作。

通过以上关于实施方式的描述，所属领域的技术人员可以清楚地了解到，本发明可借助软件及必需的通用硬件来实现，当然也可以通过硬件实现，但很多情况下前者是更佳的实施方式。基于这样的理解，本发明的技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来，该计算机软件产品可以存储在计算机可读存储介质中，如计算机的软盘、只读存储器(Read-Only Memory,ROM)、随机存取存储器(RandomAccess Memory,RAM)、闪存(FLASH)、硬盘或光盘等，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)执行本发明各个实施例所述的方法。

值得注意的是，上述微服务架构下的接口调用管理装置的实施例中，所包括的各个单元和模块只是按照功能逻辑进行划分的，但并不局限于上述的划分，只要能够实现相应的功能即可；另外，各功能单元的具体名称也只是为了便于相互区分，并不用于限制本发明的保护范围。

注意，上述仅为本发明的较佳实施例及所运用技术原理。本领域技术人员会理解，本发明不限于这里所述的特定实施例，对本领域技术人员来说能够进行各种明显的变化、重新调整和替代而不会脱离本发明的保护范围。因此，虽然通过以上实施例对本发明进行了较为详细的说明，但是本发明不仅仅限于以上实施例，在不脱离本发明构思的情况下，还可以包括更多其他等效实施例，而本发明的范围由所附的权利要求范围决定。

Claims (15)

1.一种微服务架构下的接口调用管理方法，其特征在于，包括：

获取服务缓存表中的服务消费者与服务生产者之间的接口调用关系，其中，所述服务消费者用于表示接口调用的调用发起方，所述服务生产者用于表示接口调用的被调用方；

匹配所述接口调用关系与数据库中在先存储的接口调用关系；

当匹配失败时，确定所述接口调用关系是新增接口调用关系，在所述数据库中存储所述新增接口调用关系。

2.根据权利要求1所述的方法，其特征在于，在获取服务缓存表中的服务消费者与服务生产者之间的接口调用关系之前，还包括：

当检测到接口调用事件时，在服务缓存表中记录与所述接口调用事件相关的服务消费者与服务生产者之间的接口调用关系。

3.根据权利要求1所述的方法，其特征在于，所述获取服务缓存表中的服务消费者与服务生产者之间的接口调用关系，包括：

周期性地获取服务缓存表中所有的服务消费者与服务生产者之间的接口调用关系。

4.根据权利要求1所述的方法，其特征在于，所述获取服务缓存表中的服务消费者与服务生产者之间的接口调用关系，包括：

获取服务缓存表中重点的服务消费者与重点的服务生产者之间的接口调用关系，其中，所述重点的服务消费者用于表示由用户预设的在接口调用中起关键性作用的调用发起方，所述重点的服务生产者用于表示由用户预设的在接口调用中起关键性作用的被调用方。

5.根据权利要求1所述的方法，其特征在于，所述获取服务缓存表中的服务消费者与服务生产者之间的接口调用关系，包括：

获取服务缓存表中服务消费者的第一消费地址以及与所述服务消费者具有接口调用关系的服务生产者的第一生产地址，将所述第一消费地址与第一生产地址之间的地址访问关系作为所述服务消费者与服务生产者之间的接口调用关系，其中，所述第一消费地址用于确定所述服务消费者的真实物理地址，所述第一生产地址用于确定所述服务生产者的真实物理地址。

6.根据权利要求5所述的方法，其特征在于，所述匹配所述接口调用关系与数据库中在先存储的接口调用关系，包括：

匹配所述第一消费地址和数据库中在先存储的服务消费者的第二消费地址，匹配所述第一生产地址和所述数据库中在先存储的与所述第二消费地址对应的服务生产者的第二生产地址，其中，述第二消费地址用于确定所述数据库中在先存储的服务消费者的真实物理地址，所述第二生产地址用于确定所述数据库中在先存储的服务生产者的真实物理地址。

7.根据权利要求6所述的方法，其特征在于，所述当匹配失败时，确定所述接口调用关系是新增接口调用关系，在所述数据库中存储所述新增接口调用关系，包括：

当所述第一消费地址与第二消费地址匹配失败，或所述第一生产地址与第二生产地址匹配失败时，确定所述第一消费地址与第一生产地址之间的地址访问关系是新增地址访问关系，在所述数据库中存储所述新增地址访问关系。

8.根据权利要求1所述的方法，其特征在于，还包括：

当检测到目标服务生产者的被调用关系查询指令时，查找数据库中与所述目标服务生产者对应的所有的服务消费者；

生成所述目标服务生产者对应的服务消费者列表，其中，所述服务消费者列表用于反映所述目标服务生产者的被调用情况。

9.根据权利要求1所述的方法，其特征在于，在在所述数据库中存储所述新增接口调用关系之后，还包括：

根据所述数据库中存储的所有接口调用关系，确定每个接口所属组件的参考组件调用关系；

过滤重复的参考组件调用关系，得到所有组件的组件调用关系。

10.根据权利要求9所述的方法，其特征在于，所述根据所述数据库中存储的所有接口调用关系，确定每个接口所在组件的调用关系，包括：

基于所述服务消费者和服务生产者分别与组件的对应关系，确定与所述服务消费者对应的组件消费者，以及与所述服务生产者对应的组件生产者，其中，所述组件消费者用于表示组件调用的调用发起方，所述组件生产者用于表示组件调用的被调用方；

基于数据库中存储的所述服务消费者与服务生产者之间的接口调用关系、所述服务消费者与组件消费者的对应关系以及所述服务生产者与组件生产者的对应关系，确定所有组件消费者与组件生产者之间的组件调用关系。

11.根据权利要求10所述的方法，其特征在于，在得到所有组件的组件调用关系之后，还包括：

匹配所述组件调用关系与数据库中在先存储的组件调用关系；

当匹配失败时，确定所述组件调用关系是新增组件调用关系，在所述数据库中存储所述新增组件调用关系。

12.根据权利要求11所述的方法，其特征在于，在在所述数据库中存储所述新增组件调用关系之后，还包括：

当检测到目标组件生产者的被调用关系查询指令时，查找所述数据库中与所述目标组件生产者对应的所有的组件消费者；

生成所述目标组件生产者对应的组件消费者列表，其中，所述组件消费者列表用于反映所述目标组件生产者的被调用情况。

13.一种微服务架构下的接口调用管理装置，其特征在于，包括：

关系获取模块，用于获取服务缓存表中的服务消费者与服务生产者之间的接口调用关系，其中，所述服务消费者用于表示接口调用的调用发起方，所述服务生产者用于表示接口调用的被调用方；

关系匹配模块，用于匹配所述接口调用关系与数据库中在先存储的接口调用关系；

关系确定模块，用于当匹配失败时，确定所述接口调用关系是新增接口调用关系，在所述数据库中存储所述新增接口调用关系。

14.一种服务器，其特征在于，所述服务器包括：

一个或多个处理器；

存储器，用于存储一个或多个程序，

当所述一个或多个程序被所述一个或多个处理器执行，使得所述一个或多个处理器实现如权利要求1-12中任一所述的微服务架构下的接口调用管理方法。

15.一种包含计算机可执行指令的存储介质，其特征在于，所述计算机可执行指令在由计算机处理器执行时用于执行如权利要求1-12中任一所述的微服务架构下的接口调用管理方法。

Images