CN112612508A - Api网关中的api版本控制方法、装置及存储介质 - Google Patents

Abstract

本公开提供了一种API网关中的API版本控制方法、装置及存储介质，用于API版本控制中业务侵入、代码冗余的技术问题。本公开在API网关的组件架构基础上，通过新增版本控制组件，实现API版本与服务下的上游服务组件的绑定，能够根据客户端请中所携带的API版本参数将请求转发给指定API版本的上游服务组件进行处理，在服务端实现了不同版本的服务与对应的API版本的绑定，服务端不需要将不同版本的API混合在一个服务当中提供服务，从而减少业务的侵入、代码的冗余，实现了API版本的统一管理和控制。

Description

API网关中的API版本控制方法、装置及存储介质

技术领域

本公开涉及互联网技术领域，尤其涉及一种API网关中的API版本控制方法、装置及存储介质。

背景技术

应用程序编程接口API是API提供者与API使用者之间建立的纽带。正常情况下，API版本不会轻易变动，一旦API提供者将API对外公开发布，就必须保持它是可用的并且不会影响到已有的使用者。如果是遇到多个项目，则需要对API进行版本控制，以防止影响到现有的API使用者。

API的版本控制策略一般有以下3种模式：

(1)The Knot无版本模式，即API永远只有一个版本，所有的API使用者都必须使用最新的API，任何API的修改都会影响到API的已有使用者。

(2)Point-to-Point点对点模式，即API自带版本号，API使用者根据自己的需求选择使用相应API版本。

(3)Compatible Versioning兼容版本控制模式，和The Knot一样，API只有一个版本，但最新版本需要兼容以前的所有API版本。

RESTful是一种网络应用程序的设计风格和开发方式，基于HTTP，可以使用XML格式定义或JSON格式定义。在RESTful API领域，版本管理目前有以下3中比较流行的方式：

(1)URI方式，即直接在统一资源标识符(uniform resource identifier，URI)中标记使用的哪个版本，无版本号默认使用最新版本。例如：http://h3c-cloud/api/v1.0/users/1234

(2)Request Parameter请求参数方式，即在每一个请求后添加一个version参数，表示请求的是哪个版本。例如：

http://h3c-cloud/api/clusters/1234？version＝3

(3)Header方式，即在HTTP请求的header中使用Media Type或者自定义字段标记该请求想获取的资源，同样可以不设置或设置通用的Media Type表示最新的API版本。

例如：version:v1.0或Accept:application/vnd.h3c.customer-v2+json

以上的3种实现方式一般都是需要API提供者自己开发和维护，在同一个API里面可能需要维护多个版本的代码，且一般为全量代码，这样做会导致代码的冗余，项目的臃肿。

上述API版本控制方式存在以下几方面的技术问题：

业务侵入性强，API提供者在开发新的业务需求时，还需要考虑对旧版本API的兼容问题，当业务逻辑复杂，版本过多时，会给API提供者带来很多的额外工作量。

造成代码冗余，为了避免多个版本的API之间互相影响的情况，不同版本的API即使逻辑大部分都一样，但还是得给每个版本的API提供单独的代码，导致了代码冗余，随着版本的增多，项目会变的越来越臃肿。

管理繁重，在微服务的体系下，不同的模块的业务往往会被分为不同的微服务来实现，由不同团队的人员来维护，不同团队之间可能会有各自的API版本的标准，当一个微服务体系比较庞大时，维护不同微服务的API版本会变得十分困难。

发明内容

有鉴于此，本公开提供一种基于API网关的API版本控制方法、装置及存储介质，用于API版本控制中业务侵入、代码冗余的技术问题。

图1为本公开一实施提供的一种API网关中的API版本控制方法的步骤图，该方法适用于采用RESTful开发方式的API版本的管理和控制，该方法包括：

步骤101.指定服务的路由组件Route接收到客户端请求后，基于预设的匹配规则将请求转发给相应的服务组件Service：

步骤102.服务组件Service接收到请求后，将请求转发给版本控制组件；

服务组件是上层服务的抽象，路由组件Route和版本控制组件都创建于服务之下，例如服务svc1的路由组件接收到请求后，根据自身预设的匹配规则进行匹配，匹配成功后将请求转发给该服务对应的服务组件Service，服务组件Service可对请求做某些处理(例如修改路径等)后，将请求转发给所述指定服务下的版本控制组件。

步骤103.版本控制组件接收到请求后，从请求中提取API版本参数，根据预配置的API版本与上游服务组件Upstream的对应关系表，将请求转发给与请求中API版本参数对应的上游服务组件Upstream；

在本公开一实施例中，客户端发送的请求中，通过添加API版本参数来指示版本控制组件该请求所适配的API版本，例如在所述请求的HTTP请求头Header中携带用于指定API版本的API版本参数，版本控制组件通过请求头中携带的API版本参数将请求转发给与API版本参数相对应的上游服务组件Upstream。

在本公开一实施例中，当请求中未携带用于指定API版本的API版本参数时，版本控制组件根据服务组件Service中预设的默认上游服务组件Upstream值，将请求转发给默认上游服务组件Upstream。

步骤104.上游服务组件Upstream接收到请求后，根据负载均衡策略，将请求转发给下挂于该上游服务组件的某个目标组件Target。

在本公开一实施例中，当请求中包括自定义参数时，版本控制组件根据预配置的上游服务组件Upstream与自定义规则列表的对应关系，进行请求中的自定义参数与所述自定规则列表中的匹配条件的匹配，将请求转发给与所述自定义规则列表相匹配的上游服务组件Upstream。

图2为本公开一实施例提供的一种API网关中的API版本控制装置结构示意图，该装置中的各功能模块可以采用软件模块形式实现，也可以采用硬件单元方式实现。该装置的各模块的功能与本公开实施提供的方法中的各步骤具有对应关系。该装置中的各模块可以在一个硬件设备上执行，也可以由不同的硬件设备分别实施。该装置200包括：

路由组件201，用于根据预设的匹配规则对请求进行匹配，将匹配的请求转发给相应的服务组件202；

服务组件202，用于提供服务入口，在接收到请求后，将请求转发给版本控制组件203；

版本控制组件203，用于实现指定服务下API版本与上游服务组件的绑定，在接收到请求后，从请求中提取API版本参数，根据预配置的API版本与上游服务组件204的对应关系表，将请求转发给与请求中API版本参数对应的上游服务组件；

上游服务组件204，用于对客户端请求进行负载平衡，在接收到请求后，根据负载均衡策略将请求转发给下挂的目标组件205；

目标组件205，用于标识后端服务实例，将请求转发给后端服务实例进行处理。

进一步地，当请求中未携带用于指定API版本的API版本参数时，版本控制组件203根据服务组件202中预设的默认上游服务组件，将请求转发给默认上游服务组件204。

进一步，在所述请求的HTTP请求头Header中携带用于指定API版本的API版本参数，版本控制组件203根据请求头中携带的API版本参数将请求转发给与API版本参数对应的上游服务组件204。

进一步地，当请求中包括自定义参数时，版本控制组件203根据预配置的上游服务组件204与自定义规则列表的对应关系，进行请求中的自定义参数与所述自定规则列表中的匹配条件的匹配，将请求转发给与所述自定义规则列表相匹配的上游服务组件204。

图3为本公开一实施例提供的一种电子设备结构示意图，该设备300包括：诸如中央处理单元(CPU)的处理器310、内部总线320、网络接口340以及计算机可读存储介质330。其中，处理器310与计算机可读存储介质330可以通过内部总线320相互通信。计算机可读存储介质330内可存储本公开提供的用于实施上述方法的计算机程序，当计算机程序被处理器310执行时即可实现本公开提供的方法的各步骤功能。

机器可读存储介质可以包括随机存取存储器(Random Access Memory，RAM)，也可以包括非易失性存储器(Non-Volatile Memory，NVM)，例如至少一个磁盘存储器。另外，机器可读存储介质1202还可以是至少一个位于远离前述处理器的存储装置。处理器可以是通用处理器，包括中央处理器(Central Processing Unit，CPU)、网络处理器(NetworkProcessor，NP)等；还可以是数字信号处理器(Digital Signal Processing，DSP)、专用集成电路(Application Specific Integrated Circuit，ASIC)、现场可编程门阵列(Field-Programmable Gate Array，FPGA)或其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件。

本公开在API网关的组件架构基础上，通过新增版本控制组件，实现API版本与服务下的上游服务组件Upstream的绑定，能够根据客户端请中所携带的API版本参数将请求转发给指定API版本的Upstream进行处理，在服务端实现了不同版本的服务与对应的API版本的绑定，服务端不需要将不同版本的API混合在一个服务当中提供服务，从而减少业务的侵入、代码的冗余，实现了API版本的统一管理和控制。

附图说明

为了更加清楚地说明本公开实施例或者现有技术中的技术方案，下面将对本公开实施例或者现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本公开中记载的一些实施例，对于本领域普通技术人员来讲，还可以根据本公开实施例的这些附图获得其他的附图。

图1为本公开一实施提供的一种API网关中的API版本控制方法的步骤图；

图2为本公开一实施例提供的一种API网关中的API版本控制装置结构示意图；

图3为本公开一实施例提供的一种电子设备结构示意图；

图4为本公开一实施例提供的Kong API网关的架构结构示意图。

具体实施方式

在本公开实施例使用的术语仅仅是出于描述特定实施例的目的，而非限制本公开实施例。本公开实施例中所使用的单数形式的“一种”、“所述”和“该”也旨在包括多数形式，除非上下文清楚地表示其它含义。本公开中使用的术语“和/或”是指包含一个或多个相关联的列出项目的任何或所有可能组合。

应当理解，尽管在本公开实施例可能采用术语第一、第二、第三等来描述各种信息，但这些信息不应限于这些术语。这些术语仅用来将同一类型的信息彼此区分开。例如，在不脱离本公开实施例范围的情况下，第一信息也可以被称为第二信息，类似地，第二信息也可以被称为第一信息。取决于语境，此外，所使用的词语“如果”可以被解释成为“在……时”或“当……时”或“响应于确定”。

API网关即API Gateway是整个业务应用系统的唯一入口。API网关封装了业务应用系统的内部架构，为每个客户端提供定制的API。

Kong是一款基于OpenResty(Nginx+Lua模块)编写的高可用、易扩展的，开源的API网关项目。Kong能提供易于使用的RESTful API来操作和配置API管理系统，可通过水平扩展多个Kong服务器，实现大批量网络请求的负载分担。Kong采用插件机制进行功能定制，插件集在API请求响应循环的生命周期中被执行。几个基础功能包括：HTTP基本认证、密钥认证、CORS(Cross-Origin Resource Sharing，跨域资源共享)、TCP、UDP、文件日志、API请求限流、请求转发以及Nginx监控等。

为了更清楚地说明本公开提供的技术方案，以下以Kong API网关为例结合附图进行说明。图4为本公开一实施例提供的Kong API网关的组件架构结构示意图。该Kong API网关包括以下几个基础组件：

Route路由组件：用于定义匹配规则以匹配客户端的请求，将请求导向到客户端所请求的服务组件。

Service服务组件：用于为客户端提供服务入口，该组件是对上游服务的抽象，一个服务组件对应一类业务服务。

版本控制组件：用于实现指定服务下API版本与上游服务组件的绑定，基于客户端请求中标识的API版本将请求转发给对应版本的Upstream上游服务组件，该模块主要用来实现不同API版本之间的路由跳转。该组件为本公开新增的组件。

Upstream上游服务组件：用于对客户端请求进行负载平衡，将请求均衡分配给多个Target目标组件。在本公开中，该组件的作用被扩展，不仅具有负载均衡的功能，还具有区分API版本的功能。

Target目标组件：用于标识后端服务实例，该组件配置有后端服务实例对应的端口的ip地址或主机名，Target组件接收到请求后根据自身配置将请求转发给后端服务实例进行处理。

在Kong网关进行客户端请求的处理之前，首先需要通过Kong网关的管理接口来创建上述Route路由组件、Service服务组件、版本控制组件、Upstream上游服务组件、Target目标组件，在创建组件的同时需要根据业务服务环境对组件进行配置。当这些组件创建完毕并运行相应的组件实例后，即可对客户端的请求进行相应处理。

参考图4，假定Kong网关的组件相关的配置如下：

Kong网关的代理访问地址为：http://10.125.50.10:48000；

需要被代理的API有两个版本，分别为版本v1和版本v2；

上游服务组件Upstream1对应版本v1，上游服务组件Upstream2对应版本v2；

被代理的后端服务实例有6个，分别是Target1～Target6，其中Target1～Target3提供API版本v1的服务，Target4～Target6提供API版本v2的服务。Target1～Target3由Upstream1实现负载均衡，Target4～Target6由Upstream2实现负载均衡。

假设Target1～Target6的地址分别为：127.0.0.1～127.0.0.6，则Target1被代理的API的请求可示例如下：

GET http://127.0.0.1:8080/path

以下给出创建各组件的示例：

创建两个Upstream组件，upstream1对应API版本v1，upstream2对应API版本v2，Upstream组件主要负责其下挂的Target组件的负载均衡处理：

在Upstream1和Upstream2下分别创建3个Target组件：

在服务svc1下，创建版本控制组件，需要配置的参数有：版本控制组件的名称(name)、组件配置项(config，配置项详细说明见表1)，其中，在版本控制组件中的组件配置项配置了API版本与Upstream之间的对应关系，API版本与Upstream之间的对应关系可通过所配置的API版本匹配条件来确定，例如api_version用来指定API版本，upstream参数用来指定对应的Upstream组件。根据如下版本控制组件的配置，当客户端发送的请求中携带api-version版本参数键值对且api-version指定为v1时，API版本v1的请求会被转发给Upstream1来处理，针对API版本v2的请求由Upstream2来处理。

创建Service组件，Service组件需要配置的参数有：被代理的API的名称即服务名(name)、端口(port)，访问路径(path)等。Service组件可将请求直接导向后端服务实例(例如在host属性中直接指定Target的IP地址)，也可通过指定Upstream来做流量的负载均衡。为了提高灵活性，Service组价还可通过指定path属性来对请求进行路径修改等操作。在本公开中，Service组件中host属性还可用于指定请求默认的API版本，当客户端发送的请求中未携带用于指示API版本的参数或携带错误的API版本参数时，则版本控制组件会默认提取Service组件中host属性设定的Uptream，并将请求转发给对应的Upstream组件进行处理。

在服务svc1下创建Route组件，Route组件需要配置的参数有：名称(name)、代理访问路径(paths)等。

当Kong网关接收到一个来自客户端的请求Request时，其请求的处理流程如下：

步骤501.Route组件route1接收到请求后，基于预设的匹配规则进行匹配，将符合匹配规则的请求转发给对应的Service组件；

例如在该实施例中，客户端发送的请求可通过“-H关键字：值”参数来显性地指定客户端所请求的API版本，示例如下：

GET-H api-version:v2 http://10.125.50.10:48000/proxy/path

该请求中，-H表示在客户端发送的HTTP请求的请求头header中加入该参数指定的键值对即“api-version:v2”，该键值对用于指示版本控制组件该请求对应的API版本为v2。

当路由组件Route通过path属性设置匹配路径为“/proxy/path”，当路由组件接收到请求后基于path属性进行匹配，匹配成功后将请求转发给对应的Service组件。

步骤502.Service组件svc1接收到请求后，将请求转发给对应的版本控制组件；

Service组件为服务的入口，在Service组件中可设置默认的Upstream组件，也可通过设置port、path等属性来修改请求中的端口和路径等。

例如，客户端发送的请求中也可不包括-H参数，这种情况下，可通过Service组件中的Host属性来指定该请求默认的API版本，假设当host属性设置为upstream1时，则默认请求的API版本为upstream1对应的API版本即v1版本。

步骤503.版本控制组件接收到Service转发的请求后，从请求中提取API版本参数，根据预配置的API版本与Upstream组件的对应关系，将请求转发给API版本参数指定的API版本对应的Upstream组件；

例如，当版本控制组件获取客户端发送的请求中的请求头Header里的api-version的值为v2时，根据自身的属性配置项，匹配到API版本v2对应的Upstream组件为upstream2，则将请求转发给upstream2。

如果请求中没有携带API版本参数，则版本控制组件根据Service组件中host属性设置的默认Upstream组件，将请求发送给默认的Upstream组件。

步骤504.Upstream组件接收到请求后，根据负载均衡策略，将请求转发给在该Upstream组件下挂的某个Target组件；

例如当Upstream组件upstream2接收到请求后，根据其配置的负载均衡策略，将请求转给其下Target4～Target6中的一个。

在Upstream组件中会进行请求中代理地址的替换，例如将请求中的http://10.125.50.10:48000/path替换为http://127.0.0.6:8080/path，然后将请求转发给Target6进行处理。

在本公开另一实施例中，还支持在请求中携带自定义的参数来告知版本控制组件根据自定义参数的值匹配相应的条件来确定请求的API版本。

如表1所示，版本控制组件可支持的配置属性除了api_version、upstream外，还支持自定义规则开关enable_custom、body匹配项items_body、头匹配项items_header等参数。

表1

在本公开一实施例中的版本控制组件的配置如下：

在上述配置示例中，API版本v1没有开启自定义规则属性enable_custom没有开启，API版本v2的自定义规则属性enable_custom设置为开启true状态，当enable_custom设置为开启true状态时，允许在请求中携带用户自定义的参数，例如在HTTP请求的请求头Header或Body中携带多个自定义参数，当版本控制组件接收到请求后，会从请求中提取所携带的自定义参数，并将请求中所携带的自定义参数值与版本控制组件中的自定义规则列表进行匹配，若匹配成功，则选择对应版本的Upstream。通过自定义规则属性可以更加灵活地进行API版本的控制，例如当请求未携带api_version参数，但携带了自定义参数，当自定义参数与组件中预配置的自定义规则列表items_header或items_body所设置的条件匹配时，也可据此确定请求的API版本。

基于以上本公开提供的版本控制方法和组件架构，可实现服务下的Upstream与API版本的绑定，API提供者在开发新版本API时，只需要维护好使用新API版本的服务，不用考虑旧版本的API的兼容问题，旧的API由旧版本的服务提供服务。此外，新版本API没有冗余代码，只需要维护当前版本的API，所以不存在重复多个版本的API代码的情况，项目代码会变得轻量和简洁。

通过本公开提供的技术方案，能够实现统一的API版本管理，API网关做为微服务体系的统一出入口，各微服务的开发者不需要关心API版本的管理问题，只需要将不同版本的API注册到API网关，由API网关统一管理。

通过本公开提供的技术方案，还可实现API版本的动态加载，本公开可通过API网关的管理接口配置多个版本的服务，不需要重启API网关，实现动态加载不同版本，不需要重启或中断服务。

应当认识到，本公开的实施例可以由计算机硬件、硬件和软件的组合、或者通过存储在非暂时性计算机可读存储器中的计算机指令来实现或实施。所述方法可以使用标准编程技术，包括配置有计算机程序的非暂时性计算机可读存储介质在计算机程序中实现，其中如此配置的存储介质使得计算机以特定和预定义的方式操作。每个程序可以以高级过程或面向对象的编程语言来实现以与计算机系统通信。然而，若需要，该程序可以以汇编或机器语言实现。在任何情况下，该语言可以是编译或解释的语言。此外，为此目的该程序能够在编程的专用集成电路上运行。

此外，可按任何合适的顺序来执行本公开描述的过程的操作，除非本公开另外指示或以其他方式明显地与上下文矛盾。本公开描述的过程(或变型和/或其组合)可在配置有可执行指令的一个或多个计算机系统的控制下执行，并且可作为共同地在一个或多个处理器上执行的代码(例如，可执行指令、一个或多个计算机程序或一个或多个应用)、由硬件或其组合来实现。所述计算机程序包括可由一个或多个处理器执行的多个指令。

进一步，所述方法可以在可操作地连接至合适的任何类型的计算平台中实现，包括但不限于个人电脑、迷你计算机、主框架、工作站、网络或分布式计算环境、单独的或集成的计算机平台、或者与带电粒子工具或其它成像装置通信等等。本公开的各方面可以以存储在非暂时性存储介质或设备上的机器可读代码来实现，无论是可移动的还是集成至计算平台，如硬盘、光学读取和/或写入存储介质、RAM、ROM等，使得其可由可编程计算机读取，当存储介质或设备由计算机读取时可用于配置和操作计算机以执行在此所描述的过程。此外，机器可读代码，或其部分可以通过有线或无线网络传输。当此类媒体包括结合微处理器或其他数据处理器实现上文所述步骤的指令或程序时，本公开所述的发明包括这些和其他不同类型的非暂时性计算机可读存储介质。当根据本公开所述的方法和技术编程时，本公开还包括计算机本身。

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

Claims (10)

1.一种API网关中的API版本控制方法，其特征在于，该方法包括：

指定服务的路由组件接收到客户端请求后，基于预设的匹配规则将请求转发给相应的服务组件；

服务组件接收到请求后，将请求转发给版本控制组件；

版本控制组件接收到请求后，从请求中提取API版本参数，根据预配置的API版本与上游服务组件的对应关系表，将请求转发给与请求中API版本参数对应的上游服务组件；

上游服务组件接收到请求后，根据负载均衡策略将请求转发给下挂于该上游服务组件的某个目标组件。

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

当请求中未携带用于指定API版本的API版本参数时，版本控制组件根据服务组件中预设的默认上游服务组件，将请求转发给默认上游服务组件。

3.根据权利要求1所述的方法，其特征在于，

在所述请求的HTTP请求头Header中携带用于指定API版本的API版本参数，版本控制组件根据请求头中携带的API版本参数将请求转发给与API版本参数对应的上游服务组件。

4.根据权利要求2或3所述的方法，其特征在于，

当请求中包括自定义参数时，版本控制组件根据预配置的上游服务组件与自定义规则列表的对应关系，进行请求中的自定义参数与所述自定规则列表中的匹配条件的匹配，将请求转发给与所述自定义规则列表相匹配的上游服务组件。

5.根据权利要求4所述的方法，其特征在于，

所述的API网关为Kong网关；

所述的自定义规则列表包括请求头Header对应的自定义规则列表和请求体Body对应的自定义规则列表。

6.一种API网关中的API版本控制装置，其特征在于，该装置包括：

路由组件，用于根据预设的匹配规则对请求进行匹配，将匹配的请求转发给相应的服务组件；

服务组件，用于提供服务入口，在接收到请求后，将请求转发给版本控制组件；

版本控制组件，用于实现指定服务下API版本与上游服务组件的绑定，在接收到请求后，从请求中提取API版本参数，根据预配置的API版本与上游服务组件的对应关系表，将请求转发给与请求中API版本参数对应的上游服务组件；

上游服务组件，用于对客户端请求进行负载平衡，在接收到请求后，根据负载均衡策略将请求转发给下挂的目标组件；

目标组件，用于标识后端服务实例，将请求转发给后端服务实例进行处理。

7.根据权利要求6所述的装置，其特征在于，

当请求中未携带用于指定API版本的API版本参数时，版本控制组件根据服务组件中预设的默认上游服务组件，将请求转发给默认上游服务组件。

8.根据权利要求6所述的装置，其特征在于，

在所述请求的HTTP请求头Header中携带用于指定API版本的API版本参数，版本控制组件根据请求头中携带的API版本参数将请求转发给与API版本参数对应的上游服务组件。

9.根据权利要求7或8所述的装置，其特征在于，

当请求中包括自定义参数时，版本控制组件根据预配置的上游服务组件与自定义规则列表的对应关系，进行请求中的自定义参数与所述自定规则列表中的匹配条件的匹配，将请求转发给与所述自定义规则列表相匹配的上游服务组件。

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

Images