CN116781661A - 一种接口管理方法、装置、设备及存储介质 - Google Patents

Abstract

本申请公开了一种接口管理方法、装置、设备及存储介质，该方法包括：将服务端信息、接口信息分存入CMDB服务端模型和接口模型；基于客户端发送的接口调用请求，从模型中确定出目标接口信息和目标服务端信息；基于目标接口、目标服务端信息，生成URL地址，并将其发送给客户端，使得客户端基于URL地址对目标服务端接口进行调用。如此，利用CMDB对服务端接口相关的服务端信息和接口信息进行纳管，可以便于开发者对服务端信息以及接口信息的管理；且将服务端信息和接口信息进行纳管后，可以直接生成URL地址，为客户端提供便捷的服务端接口访问方式。

Description

一种接口管理方法、装置、设备及存储介质

技术领域

本发明涉及微服务领域，尤其涉及一种接口管理方法、装置、设备及存储介质。

背景技术

微服务架构是一种云原生架构，它将一个复杂的应用拆分成多个独立自治的服务组件，组件与组件之间松散耦合，并可独立部署。与传统的一体化架构(MonolithicArchitecure)相比，微服务架构具备灵活部署、技术异构、可扩展等特点。

每个微服务都是一个独立的实体，他们之间的交互通常以表征状态转移(Representational State Transfer，RESTful)接口的形式进行。相比传统架构，微服务开发者不仅需要维护服务端的接口信息，还需要考虑接口服务端故障、限流等各种异常情况，因此还需要对与接口相关的服务端信息进行管理。然而传统的接口管理***功能有限，仅限于对接口信息的管理，无法从根本上减少微服务开发人员的工作量。

发明内容

为解决上述技术问题，本申请实施例期望提供一种接口管理方法、装置、设备及存储介质。

本申请的技术方案是这样实现的：

第一方面，提供了一种接口管理方法，所述方法包括：

获取至少一个服务端的服务端信息，以及每个服务端绑定的至少一个服务端接口的接口信息；

将所述服务端信息存入CMDB服务端模型，将所述接口信息存入CMDB接口模型；

接收客户端发送的接口调用请求；其中，所述接口调用请求包括：目标服务端接口的标识信息；

基于所述目标服务端接口的标识信息，从所述CMDB接口模型中确定出所述目标服务端接口的目标接口信息，从所述CMDB服务端模型中确定出所述目标服务端接口所绑定目标服务端的目标服务端信息；

基于所述目标接口信息和所述目标服务端信息，生成URL地址；

将所述URL地址发送给所述客户端，以使得所述客户端基于所述URL地址对所述目标服务端接口进行调用。

第二方面，提供了一种接口管理装置，所述装置包括：

获取模块，用于获取至少一个服务端的服务端信息，以及每个服务端绑定的至少一个服务端接口的接口信息；

处理模块，用于将所述服务端信息存入CMDB服务端模型，将所述接口信息存入CMDB接口模型；

接收模块，用于接收客户端发送的接口调用请求；其中，所述接口调用请求包括：目标服务端接口的标识信息；

所述处理模块，还用于基于所述目标服务端接口的标识信息，从所述CMDB接口模型中确定出所述目标服务端接口的目标接口信息，从所述CMDB服务端模型中确定出所述目标服务端接口所绑定目标服务端的目标服务端信息；基于所述目标接口信息和所述目标服务端信息，生成URL地址；

发送模块，用于将所述URL地址发送给所述客户端，以使得所述客户端基于所述URL地址对所述目标服务端接口进行调用。

第三方面，提供了一种电子设备，所述电子设备包括：处理器和配置为存储能够在处理器上运行的计算机程序的存储器，其中，所述处理器配置为运行所述计算机程序时，执行前述方法的步骤。

第四方面，提供了一种计算机存储介质，其上存储有计算机程序，其中，该计算机程序被处理器执行时实现前述方法的步骤。

本申请公开一种接口管理的方法、装置、设备及存储介质，通过利用CMDB对服务端接口相关的服务端信息和接口信息进行纳管，可以便于开发者对服务端信息以及接口信息的管理；且将服务端信息和接口信息进行纳管后，可以直接生成客户端所需的URL地址，为客户端提供便捷的服务端接口访问方式。。

附图说明

图1为本申请实施例中接口管理方法的第一流程示意图；

图2为本申请实施例中接口调用在Open Feign中的请求流程图；

图3为本申请实施例中接口管理方法的第二流程示意图；

图4为本申请实施例中接口管理***的结构示意图；

图5为本申请实施例中接口管理装置的组成结构示意图；

图6为本申请实施例中电子设备的组成结构示意图。

具体实施方式

为了能够更加详尽地了解本申请实施例的特点与技术内容，下面结合附图对本申请实施例的实现进行详细阐述，所附附图仅供参考说明之用，并非用来限定本申请实施例。

本申请实施例提出一种接口管理方法。图1为本申请实施例中接口管理方法的第一流程示意图，如图1所示，该接口管理方法具体可以包括：

步骤101：获取至少一个服务端的服务端信息，以及每个服务端绑定的至少一个服务端接口的接口信息；

这里，服务端信息为与服务端接口相关的服务端信息。示例性的，服务端信息包括：服务ID、服务名称、传输协议(http/https)、服务域名、ip地址、服务端口、服务标签、服务描述等配置项信息，如下表1所示。其中，服务ID用于唯一标识接口服务端信息，同时与不同的接口信息绑定；服务名称用来对接口服务命名；传输协议用于制定接口的请求协议，如常用的http/https协议；服务域名用于映射接口服务的网络地址；ip地址标识服务所在服务器的ip地址；服务端口用于指定服务对应的服务器访问端口；服务标签可以用于对服务器进行分组管理；服务描述记录了服务的详细信息。

表1服务端信息

这里，接口信息为服务端接口的相关信息。示例性的，接口信息包括：接口ID、接口名称、请求方式、请求路径、请求头、请求参数、请求体等配置项信息。其中，接口ID用于唯一标识一个接口(相当于接口的标识信息)，接口ID与服务端信息的服务ID存在绑定关系，需要说明的是，该绑定关系也存在于接口信息中，即接口信息中包括：接口信息与服务端信息的绑定关系；接口名称用于对某个接口命名；请求方式即包括GET、POST、HEAD、PUT、DELETE、PATCH等在内的请求方法；请求路径即接口的统一资源标识路径，当存在路径参数时，可使用“{路径参数名}”的方式存储；请求头、请求参数和请求体用于存放接口需要提供的入参，它们在数据库中都通过json的方式存储，便于参数的解析。

示例性的，在实际应用中，获取至少一个服务端的服务端信息，以及每个服务端绑定的至少一个服务端接口的接口信息，可以是通过用户界面接收获取接口管理输入的服务端信息及接口信息。

步骤102：将所述服务端信息存入CMDB服务端模型，将所述接口信息存入CMDB接口模型；

这里，配置管理数据库CMDB(Configuration Management Database)本质是一个存储配置数据的逻辑数据库，该数据库主要用来存储配置项全生命周期的基本信息以及配置项之间的逻辑关系。

示例性的，在一些实施例中，所述方法还包括：接收服务端信息管理指令和/或接口信息管理指令；基于所述服务端信息管理指令对所述CMDB服务端模型中的服务端信息进行管理；基于所述接口信息管理指令对所述CMDB接口模型中的接口信息进行管理。

示例性的，在一些实施例中，所述方法还包括：根据服务器元数据信息构建所述CMDB服务端模型。

本申请充分利用CMDB的优势，为服务端接口相关的服务端信息和接口信息提供了存储、维护等功能，使得接口管理***的管理员可以通过WEB前端页面来查看不同接口的服务端信息，并对服务端信息进行创建、更新和删除等操作，以实现对服务端信息及接口信息的配置和管理。且由于接口信息中存储了接口信息与服务端信息的绑定关系，管理员还可以通过管理接口信息绑定的服务端信息，实现接口的调用和返回。

步骤103：接收客户端发送的接口调用请求；其中，所述接口调用请求包括：目标服务端接口的标识信息；

示例性的，目标服务端接口的标识信息可以为目标服务端接口的接口ID。

步骤104：基于所述目标服务端接口的标识信息，从所述CMDB接口模型中确定出所述目标服务端接口的目标接口信息，从所述CMDB服务端模型中确定出所述目标服务端接口所绑定目标服务端的目标服务端信息；

这里，需要说明的是，接口信息中包括服务端与接口的绑定关系，即CMDB接口模型中，相对应的接口信息与服务端信息存在绑定关系，客户端通过借助服务调用框架openfeign，便可实现对服务端接口的调用。通常，一个服务端可与多个接口绑定，一个接口也可通过多个服务端进行访问，服务端与接口可以是多对多的关系。默认在接口信息录入到CMDB之前，***管理员需要提供上级服务端信息的绑定，若不提供服务端信息，接口调用时就会默认返回接口对应的mock数据。

步骤105：基于所述目标接口信息和所述目标服务端信息，生成URL地址；

步骤106：将所述URL地址发送给所述客户端，以使得所述客户端基于所述URL地址对所述目标服务端接口进行访问、调用。

这里，统一资源***(Uniform Resource Locator,URL)地址是WWW的统一资源定位标志，就是指网络地址。客户端可直接通过该地址实现对目标服务端接口的访问、调用。

示例性的，在一些实施例中，所述方法还包括：获取所述服务端与所述客户端之间的交互信息；将所述交互信息作为***日志进行保存。

通过记录获取服务端与客户端之间的交互信息，可以实现接口调用的监控工作，使得管理员可以随时了解接口的使用情况，以完成接口的自动化运维工作。

这里，步骤101至步骤106的执行主体可以为实现本申请实施例接口管理方法的电子设备的处理器。

本申请实施例的技术方案，利用CMDB服务端模型和接口模型对服务端接口相关的服务端信息和接口信息进行存储之后，CMDB中所有的配置项信息(相当于服务端信息和接口信息)便交由CMDB统一纳管，可以由***管理员完成录入、编辑等功能，便于开发者对服务端信息以及接口信息的管理；将服务端信息和接口信息进行纳管后，可以直接生成客户端所需的URL地址，为客户端提供便捷的服务端接口访问方式。

示例性的，本申请在CMDB纳管服务端信息和接口信息的基础上，可通过CMDB纳管接口规则映射，达到规范化接口的目的，降低使用者的接口开发成本。

示例性的，下表为本申请实施中包含接口映射规则的接口信息。

表2接口信息

下面对接口映射规则的机制进行进一步举例说明。

示例性的，在一些实施例中，接口信息包括：入参映射规则，所述入参映射规则包括：通用接口的请求方式与服务端接口的请求方式之间的映射关系。

示例性的，所述接口信息包括入参映射规则时，所述方法还包括：通过所述通用接口接收客户端发送的第一请求体；基于所述第一请求体和所述目标接口信息对应的入参映射规则，解析出所述第一请求体对应的第二请求体；将所述第二请求体通过所述目标服务端接口发送给目标服务端。

这里，本申请在CMDB纳管服务端信息和接口信息的基础上，整合所有服务端信息和接口信息，对外仅暴露一个通用接口完成不同服务端下不同接口的调用和返回。不同服务端接口的入参，包括请求头、请求参数和请求体都使用通用接口的请求体来传入。这里，第一请求体为从客户端发送的请求信息中解析出来的请求体。

示例性的，该通用接口的具体设计如下：通用接口默认使用POST请求方式，***管理员也可借助CMDB自定义通用接口的请求方式以及通用接口的请求路径；通用接口包含serviceId和apiId两个请求参数，其中serviceId为可选参数，用于传入服务端信息配置模块的服务ID，当不提供服务ID时，则通过默认的服务接口进行调用，否则使用提供的服务进行调用，***管理员可以使用该参数配置蓝绿或灰度；而apiId为必选参数，用于传入接口信息配置模块的接口ID。不同接口的入参，包括请求头、请求参数和请求体都使用通用接口的请求体来传入。示例性的，这里提供通用接口的请求体模板如下：

其中，header用于传入接口ID对应接口的请求体信息，param用于传入接口ID对应接口的请求参数信息，body用于传入接口ID对应接口的请求体信息。

为了增强通用接口返回体构成的灵活性和可定制能力，在一些实施例中，CMDB接口模型的接口信息中还增加了出参映射规则的配置项信息，提供了一种可配置化返回体模式的功能，便于***管理员自定义统一的返回体模式或所需要的返回字段数据。

示例性的，在一些实施例中，接口信息还包括：出参映射规则，所述出参映射规则用于将返回至客户端的返回体统一成预设的返回体模式。

示例性的，所述接口信息包括出参映射规则时，所述方法还包括：通过服务端接口接收服务端发送的第一返回体；基于所述第一返回体和所述出参映射规则，解析出所述第一返回体对应的第二返回体；将所述第二返回体通过所述通用接口发送给所述客户端。

示例性的，目前适用于出参映射规则的示例如下：

示例一：

原始出参为：

400

映射规则为：

原始出参为：

示例二：

原始出参为：

映射规则为：

实际出参为：

示例三：

原始出参为：

映射规则为：

实际出参为：

下面对上述三个示例进行说明，具体的：映射规则中的key用来表示实际返回的key，当value为非字符串类型时默认赋值到对应的key。而当value为字符串时，本申请提供规则解析器对value值进行解析，解析器主要包含四个关键字符，分别为：“[]”、“{}”、“：”、“”、“.”。其中，空字符串“”表示对应key传入返回体本身；“：”作为前缀使用，表示对应key传入“：”后的字符串作为默认值；“[]”作为前缀使用，表示返回体或当前值为数组类型；“{}”作为前缀使用，表示返回体或当前值为对象类型；“.”用于获取数组或对象的子元素，当value为数组时通过索引获取元素，要求为数值字符串，当value为对象时通过key获取元素。

示例一的默认返回体为数值类型，映射规则直接将返回体作为模板对象code键的值，并设置message键的值为“error”，data键的值为null；

示例二的默认返回体为对象类型，映射规则将对象类的元素分别映射到模板对象的对应的key中，仅返回用户所需要的对象值；

示例三默认返回数组类型，通过映射规则，规则处理器将数组的各个元素映射到模板对象中，构建与示例一、二中一致的返回模式。

通过上述规则的制定，***管理员可以将各种风格迥异的接口，规范化为唯一的POST请求方式的通用接口，且该接口的返回也可定制成统一的返回体结构。

通过上述入参、出参映射规则的制定，可以将各种风格迥异的服务端接口，规范化为唯一的POST请求方式(或其他自定义的请求方式)的通用接口，且通用接口的返回也可定制成统一的返回体结构，提供了接口返回体的可配置化方案，实现了接口的统一调用方式，继而减少了开发者适配不同接口的工作量，同时极大地提高微服务之间接口联调和对接的工作效率。

示例性的，本申请在CMDB纳管服务端信息和接口信息的基础上，可利用CMDB纳管***、熔断器等常用组件的配置参数，实现接口的功能增强，来应对接口服务端出现的各种异常情况。

示例性的，在一些实施例中，所述接口信息包括：功能组件的配置参数；所述方法还包括：基于所述功能组件的配置参数，对服务端接口的调用过程进行控制。

示例性的，在一些实施例中，所述功能组件包括以下至少之一：熔断器组件、重试器组件、限流器组件、限流器组件、缓存器组件、签名插件。

OpenFeign为Spring Cloud技术栈中专注于服务调用的技术框架，它提供了声明式的注解方式来实现对某个服务的接口调用，简化了Web服务客户端的开发。OpenFeign足够轻量且功能丰富，集成了编码器Encoder、解码器Decoder、熔断器Circuit Breaker、重试器Retryer、***Request Interceptor、日志工具Logger等常用组件。示例性的，图2为本申请实施例中接口调用在Open Feign中的请求流程图如图2所示，OpenFeign足够轻量且功能丰富，集成了编码器Encoder、解码器Decoder、熔断器Circuit Breaker、重试器Retryer、***Request Interceptor、日志工具Logger等常用组件，在客户端调用服务端接口时，这些功能组件可以用来应对接口服务端出现的各种异常情况，FeignClient可以实现远程调用接口，方便做统一处理。

具体的，熔断器组件，用于在服务端无法访问时，调用接口返回自定义的默认值。***管理员可以通过在WEB页面上为每个接口填写默认的返回值，示例如下：

除此之外，熔断器配置参数还可以包括一些基本参数，包括触发熔断器时接口调用失败的次数、熔断器生效的持续时间等。

重试器组件，用于提供简单的接口失败重复调用功能。示例性的，可以默认重试次数为3次。还可以通过管理CMDB接口模型中重试器组件的配置参数，如管理最大重试次数、固定重试间隔等配置参数来制定重试规则。

超时控制器组件，用于限定接口访问的超时时间。可以通过超时控制器完成对方法调用的超时控制，超时控制器的配置参数包括连接超时时间、读取超时时间等。

限流器组件，提供控制接口调用频次的功能，限制服务的调用频率。***管理员可以通过限流器限制周期内接口到达服务端的并发请求数，达到降低接口的实时流量的目的，避免服务端过载崩溃。限流器配置参数包括接口调用权限的刷新时间以及一个周期可调用接口的权限数等。

缓存器功能，提供缓存接口调用返回结果的功能。***管理员可以设置调用接口使用缓存的触发条件，比如返回结果中某个参数值非空时触发缓存；除此之外，***管理员还可以配置调用接口返回结果的缓存时间。

签名插件功能，用于提供签名算法插件，如RSA、DSA等，方便需要签名认证的接口调用等。***管理员可以管理加密规则，比如加密参数、参数拼接方式、是否排序、签名请求方式、返回体是否需要解密等。

本申请实施例的技术方案，通过将上述功能组件的配置参数维护在CMDB接口信息中，为***管理员提供了更细粒度的接口调用控制方式，可以确保接口正常调用并返回客户端所需要的信息。

图3为本申请实施例中接口管理方法的第二流程示意图，如图3所示，该接口管理方法具体可以包括：

步骤301：获取至少一个服务端的服务端信息，以及每个服务端绑定的至少一个服务端接口的接口信息；

这里，所述接口信息包括：入参映射规则、出参映射规则、功能组件的配置参数；

步骤302：将所述服务端信息存入CMDB服务端模型，将所述接口信息存入CMDB接口模型；

步骤303：接收服务端信息管理指令和/或接口信息管理指令；

其中，所述接口信息管理指令包括以下至少之一：入参映射规则管理指令、出参映射规则管理指令、功能组件的配置参数管理指令、绑定关系管理指令；

其中，绑定关系管理指令用于管理对接口信息绑定的服务端信息。

步骤304：基于所述服务端信息管理指令对所述CMDB服务端模型中的服务端信息进行管理；

步骤305：基于所述接口信息管理指令对所述CMDB接口模型中的接口信息进行管理。

本申请实施例的技术方案，利用CMDB服务端模型和接口模型对服务端接口相关的服务端信息和接口信息进行存储之后，CMDB中所有的配置项信息(相当于服务端信息和接口信息)便交由CMDB统一纳管，可以由***管理员完成录入、编辑等功能，便于开发者对服务端信息以及接口信息的管理；利用CMDB纳管入参、出参映射规则，可以提供接口返回体的可配置化方案，实现了接口的统一调用方式，继而减少了开发者适配不同接口的工作量，同时极大地提高微服务之间接口联调和对接的工作效率；利用CMDB纳管功能组件的配置参数，为***管理员提供了更细粒度的接口调用控制方式，可以确保接口正常调用并返回客户端所需要的信息。

为了能更加体现本申请的目的，在本申请上实施例的基础上，进行进一步的举例说明。图4为本申请实施例中接口管理***的结构示意图。如图4所示，该接口管理***包括：用户界面401(User Interface)、服务视图402(Service View)、业务逻辑模块403(Business Logic)、资源访问模块404(Resource Access)和数据库405(Data base)。

其中，用户界面401用于与管理员进行人机交互，接收管理员输入的管理指令或显示管理员所需的服务端信息、接口信息、***日志等。如图4所示，用户界面401包括：模型创建/更新/删除/展示界面、配置录入/编辑/删除/展示界面、接口控制界面。

具体的，***管理员可通过模型创建/更新/删除/展示界面，对CMDB模型进行管理；可通过配置录入/编辑/删除/展示界面，对CMDB模型中的配置项信息(如服务端信息、接口信息等)进行管理；可通过接口控制界面，进行接口添加、接口删除等控制操作。

其中，服务视图402包括：模型拓扑视图、配置项拓扑视图。其中，模型拓扑视图用于展示并维护CMDB接口模型和CMBD服务端模型；配置项拓扑视图用于展示并维护CMDB模型中的配置项信息。

其中，业务逻辑模块403，用于存储并维护业务逻辑，包括：模型(接口、服务端)管理、配置(接口、服务端)管理、接口规则映射、通用接口访问、日志记录、功能组件拓展。

其中，资源访问模块404，可以包括：DB Adapter、ORM、Data Relation、Data Type等。数据库405(Data base)可以包括：Neo4j、Mysql、Redis等。

本申请实施例的技术方案，在CMDB中维护服务端配置信息的同时，存储接口的基本信息(包括：请求方式、路径、请求头、请求参数、请求体等)，将服务端和接口的配置信息纳管后，为使用者提供便捷地服务端接口访问方式，甚至可以为相同接口关联不同的服务器地址；为了适配不同风格的接口模式，本发明为使用者提供了统一的接口调用方式，通过配置映射规则，达到规范化接口的目的，降低使用者的接口开发成本；本发明还在CMDB的接口模型中增加了接口访问相关的性能参数配置(包括：访问超时、重试次数、限流、熔断等配置)，来应对接口服务端出现的各种异常情况；鉴于部分接口在调用时需要进行复杂的数字签名认证等流程，本发明提供了几种通用的数字签名算法插件，只需要提供签名相关的密钥即可完成接口的安全调用。除此之外，使用CMDB管理接口信息不仅可以让接口管理***具备安全、高效、易扩展、易维护等特性，还可以轻松的集成与接口相关的性能数据的统计和监控等功能，以完成接口的自动化运维工作。

图5为本申请实施例中接口管理装置的组成结构示意图，展示了一种接口管理方法的实现装置，该接口管理装置50具体包括：

获取模块501，用于获取至少一个服务端的服务端信息，以及每个服务端绑定的至少一个服务端接口的接口信息；

处理模块502，用于将所述服务端信息存入CMDB服务端模型，将所述接口信息存入CMDB接口模型；

接收模块503，用于接收客户端发送的接口调用请求；其中，所述接口调用请求包括：目标服务端接口的标识信息；

所述处理模块502，还用于基于所述目标服务端接口的标识信息，从所述CMDB接口模型中确定出所述目标服务端接口的目标接口信息，从所述CMDB服务端模型中确定出所述目标服务端接口所绑定目标服务端的目标服务端信息；基于所述目标接口信息和所述目标服务端信息，生成URL地址；

发送模块504，用于将所述URL地址发送给所述客户端，以使得所述客户端基于所述URL地址对所述目标服务端接口进行调用。

在一些实施例中，所述接口信息包括：入参映射规则，所述入参映射规则包括：通用接口的请求方式与服务端接口的请求方式之间的映射关系；所述接收模块503，还用于通过所述通用接口接收客户端发送的第一请求体；所述处理模块502，还用于基于所述第一请求体和所述目标接口信息对应的入参映射规则，解析出所述第一请求体对应的第二请求体；所述发送模块504，还用于将所述第二请求体通过所述目标服务端接口发送给目标服务端。

在一些实施例中，所述接口信息还包括：出参映射规则，所述出参映射规则用于将返回至客户端的返回体统一成预设的返回体模式；所述接收模块503，还用于通过服务端接口接收服务端发送的第一返回体；所述处理模块502，还用于基于所述第一返回体和所述出参映射规则，解析出所述第一返回体对应的第二返回体；所述发送模块504，还用于将所述第二返回体通过所述通用接口发送给所述客户端。

在一些实施例中，所述接口信息包括：功能组件的配置参数；所述处理模块503，还用于基于所述功能组件的配置参数，对服务端接口的调用过程进行控制。

在一些实施例中，所述功能组件包括以下至少之一：熔断器组件、重试器组件、限流器组件、限流器组件、缓存器组件、签名插件。

在一些实施例中，所述接收模块503，还用于接收服务端信息管理指令和/或接口信息管理指令；所述处理模块502，还用于基于所述服务端信息管理指令对所述CMDB服务端模型中的服务端信息进行管理；基于所述接口信息管理指令对所述CMDB接口模型中的接口信息进行管理。

在一些实施例中，所述获取模块501，还用于获取所述服务端与所述客户端之间的交互信息；所述处理模块502，还用于将所述交互信息作为***日志进行保存。

基于上述接口管理装置中各单元的硬件实现，本申请实施例还提供了一种电子设备。图6为本申请实施例中电子设备的组成结构示意图。如图6所示，该设备60包括：处理器601和配置为存储能够在处理器上运行的计算机程序的存储器602；

其中，处理器601配置为运行计算机程序时，执行前述实施例中的方法的步骤。

当然，实际应用时，如图6所示，该电子设备中的各个组件通过总线***603耦合在一起。可理解，总线***603用于实现这些组件之间的连接通信。总线***603除包括数据总线之外，还包括电源总线、控制总线和状态信号总线。但是为了清楚说明起见，在图6中将各种总线都标为总线***603。

在实际应用中，上述处理器可以为特定用途集成电路(ASIC，ApplicationSpecific Integrated Circuit)、数字信号处理装置(DSPD，Digital Signal ProcessingDevice)、可编程逻辑装置(PLD，Programmable Logic Device)、现场可编程门阵列(Field－Programmable Gate Array，FPGA)、控制器、微控制器、微处理器中的至少一种。可以理解地，对于不同的设备，用于实现上述处理器功能的电子器件还可以为其它，本申请实施例不作具体限定。

上述存储器可以是易失性存储器(volatile memory)，例如随机存取存储器(RAM，Random-Access Memory)；或者非易失性存储器(non-volatile memory)，例如只读存储器(ROM，Read-Only Memory)，快闪存储器(flash memory)，硬盘(HDD，Hard Disk Drive)或固态硬盘(SSD，Solid-State Drive)；或者上述种类的存储器的组合，并向处理器提供指令和数据。

在示例性实施例中，本申请实施例还提供了一种计算机可读存储介质，例如包括计算机程序的存储器，计算机程序可由电子设备的处理器执行，以完成前述方法的步骤。

应当理解，在本申请使用的术语是仅仅出于描述特定实施例的目的，而非旨在限制本申请。在本申请和所附权利要求书中所使用的单数形式的“一种”、“所述”和“该”也旨在包括多数形式，除非上下文清楚地表示其他含义。还应当理解，本文中使用的术语“和/或”是指并包含一个或多个相关联的列出项目的任何或所有可能组合。本申请中表述“具有”、“可以具有”、“包括”和“包含”、或者“可以包括”和“可以包含”在本文中可以用于指示存在对应的特征(例如，诸如数值、功能、操作或组件等元素)，但不排除附加特征的存在。

应当理解，尽管在本申请可能采用术语第一、第二、第三等来描述各种信息，但这些信息不应限于这些术语。这些术语仅用来将同一类型的信息彼此区分开，不必用于描述特定的顺序或先后次序。例如，在不脱离本发明范围的情况下，第一信息也可以被称为第二信息，类似地，第二信息也可以被称为第一信息。本申请实施例所记载的技术方案之间，在不冲突的情况下，可以任意组合。在本申请所提供的几个实施例中，应该理解到，所揭露的方法、装置和设备，可以通过其它的方式实现。以上所描述的实施例仅仅是示意性的，例如，单元的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，如：多个单元或组件可以结合，或可以集成到另一个***，或一些特征可以忽略，或不执行。另外，所显示或讨论的各组成部分相互之间的耦合、或直接耦合、或通信连接可以是通过一些接口，设备或单元的间接耦合或通信连接，可以是电性的、机械的或其它形式的。

上述作为分离部件说明的单元可以是、或也可以不是物理上分开的，作为单元显示的部件可以是、或也可以不是物理单元，即可以位于一个地方，也可以分布到多个网络单元上；可以根据实际的需要选择其中的部分或全部单元来实现本实施例方案的目的。

另外，在本申请各实施例中的各功能单元可以全部集成在一个处理单元中，也可以是各单元分别单独作为一个单元，也可以两个或两个以上单元集成在一个单元中；上述集成的单元既可以采用硬件的形式实现，也可以采用硬件加软件功能单元的形式实现。

以上所述，仅为本申请的具体实施方式，但本申请的保护范围并不局限于此，任何熟悉本技术领域的技术人员在本申请揭露的技术范围内，可轻易想到变化或替换，都应涵盖在本申请的保护范围之内。

Claims (10)

1.一种接口管理方法，其特征在于，所述方法包括：

获取至少一个服务端的服务端信息，以及每个服务端绑定的至少一个服务端接口的接口信息；

将所述服务端信息存入CMDB服务端模型，将所述接口信息存入CMDB接口模型；

接收客户端发送的接口调用请求；其中，所述接口调用请求包括：目标服务端接口的标识信息；

基于所述目标服务端接口的标识信息，从所述CMDB接口模型中确定出所述目标服务端接口的目标接口信息，从所述CMDB服务端模型中确定出所述目标服务端接口所绑定目标服务端的目标服务端信息；

基于所述目标接口信息和所述目标服务端信息，生成URL地址；

将所述URL地址发送给所述客户端，以使得所述客户端基于所述URL地址对所述目标服务端接口进行调用。

2.根据权利要求1所述的方法，其特征在于，所述接口信息包括：入参映射规则，所述入参映射规则包括：通用接口的请求方式与服务端接口的请求方式之间的映射关系；所述方法还包括：

通过所述通用接口接收客户端发送的第一请求体；

基于所述第一请求体和所述目标接口信息对应的入参映射规则，解析出所述第一请求体对应的第二请求体；

将所述第二请求体通过所述目标服务端接口发送给目标服务端。

3.根据权利要求2所述的方法，其特征在于，所述接口信息还包括：出参映射规则，所述出参映射规则用于将返回至客户端的返回体统一成预设的返回体模式；所述方法还包括：

通过服务端接口接收服务端发送的第一返回体；

基于所述第一返回体和所述出参映射规则，解析出所述第一返回体对应的第二返回体；

将所述第二返回体通过所述通用接口发送给所述客户端。

4.根据权利要求1所述的方法，其特征在于，所述接口信息包括：功能组件的配置参数；所述方法还包括：

基于所述功能组件的配置参数，对服务端接口的调用过程进行控制。

5.根据权利要求4所述的方法，其特征在于，所述功能组件包括以下至少之一：熔断器组件、重试器组件、限流器组件、限流器组件、缓存器组件、签名插件。

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

接收服务端信息管理指令和/或接口信息管理指令；

基于所述服务端信息管理指令对所述CMDB服务端模型中的服务端信息进行管理；

基于所述接口信息管理指令对所述CMDB接口模型中的接口信息进行管理。

7.根据权利要求1-6任一项所述的方法，其特征在于，所述方法还包括：

获取服务端与客户端之间的交互信息；

将所述交互信息作为***日志进行保存。

8.一种接口管理装置，其特征在于，所述装置包括：

获取模块，用于获取至少一个服务端的服务端信息，以及每个服务端绑定的至少一个服务端接口的接口信息；

处理模块，用于将所述服务端信息存入CMDB服务端模型，将所述接口信息存入CMDB接口模型；

接收模块，用于接收客户端发送的接口调用请求；其中，所述接口调用请求包括：目标服务端接口的标识信息；

所述处理模块，还用于基于所述目标服务端接口的标识信息，从所述CMDB接口模型中确定出所述目标服务端接口的目标接口信息，从所述CMDB服务端模型中确定出所述目标服务端接口所绑定目标服务端的目标服务端信息；基于所述目标接口信息和所述目标服务端信息，生成URL地址；

发送模块，用于将所述URL地址发送给所述客户端，以使得所述客户端基于所述URL地址对所述目标服务端接口进行调用。

9.一种电子设备，其特征在于，所述电子设备包括：处理器和配置为存储能够在处理器上运行的计算机程序的存储器，

其中，所述处理器配置为运行所述计算机程序时，执行权利要求1至7任一项所述方法的步骤。

10.一种计算机可读存储介质，其上存储有计算机程序，其特征在于，该计算机程序被处理器执行时实现权利要求1至7任一项所述的方法的步骤。