CN115604199B - 一种云原生平台微服务网关的服务路由方法和系统 - Google Patents

Abstract

本申请公开了一种云原生平台微服务网关的服务路由方法和系统，该微服务网关包括多个网关实例，多个网关实例位于不同的命名空间中，当接收到访问请求时，对访问请求进行解析，进而确定访问请求指向的云原生平台中部署的目标服务，然后基于目标服务位于第一命名空间中，将访问请求路由到第一命名空间中的第一网关实例，以由第一网关实例将访问请求路由到目标服务。如此，将多个网关实例分别部署在不同的命名空间中，实现对网关实例的资源隔离，使得各命名空间中的服务占用的资源不会相互影响，且应用管理员能够根据命名空间中所有服务的负载情况对该命名空间对应的网关实例所占用的资源进行单独配置，提高了云原生平台微服务网关治理的灵活性。

Description

一种云原生平台微服务网关的服务路由方法和系统

技术领域

本申请涉及云原生技术领域，特别涉及一种云原生平台微服务网关的服务路由方法、系统、计算机可读存储介质和电子设备。

背景技术

微服务(Micro Service，简称服务)是一种软件架构风格，是以开发一组小型服务的方式作为一个独立的业务系统，通过围绕具体业务构建多个服务，共同组成完整的业务系统，并将各服务部署到云原生平台上，不同服务之间采用轻量级的通信机制进行通信，从而对外提供数据处理能力。为了便于管理，需要为服务提供统一的外部访问入口、负载均衡、认证鉴权、流量管控、路由转发等功能。

相关技术中，通过在云原生平台上部署HTTP网关以实现上述负载均衡、认证鉴权、流量管控、路由转发等功能。然而，随着业务系统的扩展，云原生平台中部署的服务数量越来越多，采用统一入口的HTTP网关出现如下问题：一方面，由于所有服务共用网关入口，当某一服务负载压力增大时，将会占用HTTP网关大量的资源，导致其他服务的访问受到影响；另一方面，当HTTP网关的性能出现瓶颈时，应用管理员无法根据服务自身的特点对网关所占用的资源进行动态调整，只能请求云原生平台管理员进行统一配置，资源配置的灵活性较差。

因此，需要提供一种针对上述现有技术不足的改进技术方案。

发明内容

本申请的目的在于提供一种云原生平台微服务网关的服务路由方法、系统、计算机可读存储介质和电子设备，以解决或缓解上述现有技术中存在的问题。

为了实现上述目的，本申请提供如下技术方案：

本申请提供了一种云原生平台微服务网关的服务路由方法，所述微服务网关包括多个网关实例，所述多个网关实例位于不同的命名空间中，所述方法包括：

响应于接收到访问请求，对所述访问请求进行解析，以确定所述访问请求指向的目标服务；其中，所述目标服务为部署在云原生平台上任一服务；

基于所述目标服务位于第一命名空间中，将所述访问请求路由至所述第一命名空间中的第一网关实例，以由所述第一网关实例将所述访问请求路由至所述目标服务。

上述方案中，所述对所述访问请求进行解析，以确定所述访问请求指向的目标服务，具体为：

对所述访问请求进行解析，以获取所述访问请求中的请求行；其中，所述请求行中记载有所述访问请求指向的访问路径；

基于预先设置的配置信息中记载的服务与访问路径的对应关系，确定所述访问请求指向的目标服务。

上述方案中，所述微服务网关还包括多个网关控制面实例，所述多个网关控制面实例用于管理对应的网关实例；其中，所述第一网关控制面实例位于所述第一命名空间中；

对应地，在将所述目标服务的访问请求路由至所述第一命名空间中的第一网关实例之前，所述方法还包括：

创建所述第一命名空间，并将所述目标服务纳入所述第一命名空间中；

在所述第一命名空间中创建和运行所述第一网关控制面实例和所述第一网关实例；所述第一网关控制面实例用于管理所述第一网关实例。

上述方案中，所述第一网关控制面实例用于管理所述第一网关实例，具体为：

所述第一网关控制面实例基于所述配置信息在所述第一网关实例中植入第一功能插件；

对应地，所述第一网关实例将所述访问请求路由至所述目标服务，具体为：

所述第一网关控制面实例使用所述第一功能插件，并基于所述配置信息中记载的对应于第一网关实例的关键字键值对，对所述访问请求的请求头进行改写，使其能够对所述目标服务正常访问。

上述方案中，所述云原生平台中还部署有路由资源对象，所述路由资源对象用于定义所述云原生平台中的服务路由规则；

对应地，所述第一网关控制面实例用于管理所述第一网关实例，具体为：

所述第一网关控制面实例监听所述云原生平台中所述路由资源对象的变化情况；

响应于监听到所述路由资源对象发生变化，所述第一网关控制面实例根据变化后的路由资源对象更新所述第一网关实例的配置信息，以使所述第一网关实例符合变化后的服务路由规则。

上述方案中，所述第一命名空间中还包括资源配置对象，所述资源配置对象用于定义所述第一命名空间的资源阈值，所述第一命名空间的资源阈值用于限制所述第一命名空间中所有资源对象的资源占用总和的范围。

上述方案中，所述微服务网关还包括第二网关控制面实例和第二网关实例，所述第二网关控制面实例和所述第二网关实例位于第二命名空间中，所述第二网关控制面实例用于管理所述第二网关实例；所述方法还包括：

所述第二网关控制面实例基于所述配置信息在所述第二网关实例中植入第二功能插件，来为所述第一网关实例和所述第二网关实例提供不同的增强功能。

本申请实施例还提供一种云原生平台微服务网关的服务路由系统，包括多个网关实例，所述多个网关实例位于不同的命名空间中，所述系统包括：

解析单元，配置为响应于接收到访问请求，对所述访问请求进行解析，以确定所述访问请求指向的目标服务；其中，所述目标服务为部署在云原生平台上任一服务；

路由单元，配置为基于所述目标服务位于第一命名空间中，将所述访问请求路由至所述第一命名空间中的第一网关实例，以由所述第一网关实例将所述访问请求路由至所述目标服务。

本申请实施例还提供一种计算机可读存储介质，其上存储有计算机程序，所述计算机程序为如上任一所述的云原生平台微服务网关的服务路由方法。

本申请实施例还提供一种电子设备，包括：存储器、处理器、以及存储在所述存储器中并可在所述处理器上运行的程序，所述处理器执行所述程序时实现如上任一所述的云原生平台微服务网关的服务路由方法。

有益效果：

本申请的技术方案中，将微服务网关拆分成多个网关实例，多个网关实例位于不同的命名空间中，当接收到访问请求时，对访问请求进行解析，进而确定访问请求指向的云原生平台中部署的目标服务，然后基于目标服务位于第一命名空间中，将访问请求路由到第一命名空间中的第一网关实例，以由第一网关实例将访问请求路由到目标服务。如此，将云原生平台的资源划归多个命名空间，以实现对不同网关实例的资源隔离，并将目标服务与第一网关实例组织到第一命名空间中，从而实现为云原生平台中属于不同命名空间的服务设置不同的网关入口，各网关入口之间相互隔离，即使某一服务的负载增大，也不会对其他服务产生影响；此外，由于不同的服务对应于不同的网关实例，使得应用管理员能够根据服务的负载情况对网关实例所占用的资源进行动态配置，提高了云原生平台的资源配置灵活性和利用效率。

附图说明

构成本申请的一部分的说明书附图用来提供对本申请的进一步理解，本申请的示意性实施例及其说明用于解释本申请，并不构成对本申请的不当限定。其中：

图1为HTTP网关工作原理示意图；

图2为相关技术中使用统一网关入口进行服务路由的逻辑示意图；

图3为本申请的一些实施例提供的云原生平台微服务网关的服务路由方法的流程示意图；

图4为本申请的一些实施例提供的云原生平台微服务网关的服务路由方法的逻辑示意图；

图5为本申请的一些实施例提供的云原生平台微服务网关的服务路由系统的结构示意图；

图6为根据本申请的一些实施例提供的电子设备的结构示意图；

图7为根据本申请的一些实施例提供的电子设备的硬件结构图。

具体实施方式

下面将参考附图并结合实施例来详细说明本申请。各个示例通过本申请的解释的方式提供而非限制本申请。实际上，本领域的技术人员将清楚，在不脱离本申请的范围或精神的情况下，可在本申请中进行修改和变型。例如，示为或描述为一个实施例的一部分的特征可用于另一个实施例，以产生又一个实施例。因此，所期望的是，本申请包含归入所附权利要求及其等同物的范围内的此类修改和变型。

在以下描述中，所涉及的术语“第一/第二/第三”仅仅是区别类似的对象，不代表对对象的特定排序，可以理解地，“第一/第二/第三”在允许的情况下可以互换特定的顺序或先后次序，以使这里描述的本申请实施例能够以除了在这里图示或描述的以外的顺序实施。

除另有定义，本文所使用的所有的技术和科学术语与属于本公开的技术领域的技术人员通常理解的含义相同。本文中所使用的术语只是为了描述本公开实施例的目的，不是旨在限制本公开。

为了便于理解本申请的技术方案，下面对HTTP网关的相关技术进行说明。

在实现一个完整的业务应用开发的场景下，会涉及到诸多功能模块，传统的“单体应用(monolithic application)”是将应用程序的所有功能模块都打包成一个独立单元的应用程序架构，并由应用程序直接提供对外的流量请求处理，应用程序接口的管理直接从代码层面进行维护。

随着业务需求的快速发展变化，敏捷性、灵活性和可扩展性需求不断增长，单体应用的架构已经越来越难以满足业务需求。

为此，在云原生场景下，一个应用(application，APP)被拆解成多个独立的服务，每个服务又对应有多个服务实例。通过上述架构，基于微服务的拆解，提高了应用的敏捷性、灵活性和可扩展性，但大量的服务又给外部访问的管理和维护带来了不小压力，相应的成本也大大增加。为了解决上述问题，生产实践中引入了HTTP网关，以提供统一的服务管理和维护，从而节约应用开发过程中的服务管理成本。

图1示出的HTTP网关的工作流程逻辑图，如图1所示，当客户端某个应用向云原生平台的服务发送流量请求时，HTTP网关会根据预设的规则对请求进行身份鉴权，若身份鉴权不通过，则判定该请求为异常请求，并对其进行拦截；若身份鉴权通过，则将客户端的请求以负载均衡的模式分配到后端的服务A或服务B，由服务A或服务B对请求进行处理。服务A或服务B对请求进行处理后，将处理结果返回给HTTP网关，HTTP网关将处理结果返回给客户端。为了加快请求处理的速度，HTTP网关还可以先将处理结果缓存，再返回给客户端，这样，当客户端再次请求相同内容时，HTTP网关就可以将缓存内容作为请求响应返回。HTTP网关还提供统一的日志记录，以便进行链路追踪，方便出现问题时进行问题排查。通过HTTP网关提供的统一的身份鉴权、负载均衡、限流等功能，使得实际应用开发场景下无需关心对请求的鉴权、限流、负载均衡等一系列问题，提高了应用开发效率。

虽然HTTP网关使得应用接口实现了精细化管理，并能够基于统一的基础功能对外提供服务，然而，随着业务系统的扩展，应用所拆分出的服务数量越来越多，管理也越来越复杂，应用规模的扩大导致现有的统一服务管理存在如下问题：

1、不同服务之间的负载压力相互影响。在业务系统运行过程中，不同服务面临着不同的负载压力。传统的HTTP网关对不同服务采用统一的网关入口对外承载压力，当某一服务的负载增大时，将会占用HTTP网关较多的资源，导致其他服务受到影响。

2、虽然现有的HTTP网关在管理服务接口时，提供基于权限的资源隔离，也就是由云原生平台管理员基于权限为每个服务分配资源，但是，这种基于权限分配的管理，仅仅能够实现逻辑上的权限划分，所有的服务仍共用HTTP网关底层的计算资源(硬件/网络资源等)，比如CPU、内存、网络带宽等，这种底层计算资源的共用模式使应用管理员无法根据服务的资源需求进行灵活配置，只能由云原生平台管理员进行统一配置，降低了管理效率。

申请人经过对HTTP网关的运行机理进行深入研究后发现，现有的HTTP网关深层的运行机理如图2所示，HTTP网关由一个网关实例(又称网关入口)和多个后端网关组成，并通过控制面组件基于不同的权限建立每个后端网关与不同应用(App)之间的对应关系，由此实现多服务接入。由于网关实例、多个后端网关、控制面组件共用同一组硬件/网络资源，随着某些服务负载压力的扩大，必然对对应于同一网关实例的其他服务造成影响。

为此，本申请提供一种原生平台微服务网关的服务路由方法、系统、计算机可读存储介质和电子设备，通过将微服务网关拆分成多个网关实例，多个网关实例位于不同的命名空间中，将云原生平台的资源划归多个命名空间，以实现对不同网关实例的资源隔离，并将服务与网关实例组织到同一命名空间中，从而实现为云原生平台中属于不同命名空间的服务设置不同的网关实例。当接收到访问请求时，微服务网关对访问请求进行解析，进而确定访问请求指向的云原生平台中部署的目标服务，然后基于目标服务位于第一命名空间中，将访问请求路由到第一命名空间中的第一网关实例，以由第一网关实例将访问请求路由到目标服务，由于不同服务的访问请求由位于不同命名空间中的网关实例进行处理，避免了不同命名空间中的服务之间的不同负载压力产生的影响。

示例性方法

本申请实施例提供一种云原生平台微服务网关的服务路由方法，如图3、图4所示，该微服务网关包括多个网关实例，多个网关实例位于不同的命名空间中，该方法包括：

步骤S101、响应于接收到访问请求，对访问请求进行解析，以确定访问请求指向的目标服务。

其中，目标服务为部署在云原生平台上任一服务。

这里，微服务网关是部署在云原生平台边界上提供给外部访问内部微服务的统一入口，微服务网关主要用于处理所有的非业务功能，比如鉴权、限流、负载均衡等，网关实例则是微服务网关在云原生平台中对应的具体实现，也就是微服务网关的实例，因此简称“网关实例”。

在云原生平台中，所有的内容均被抽象为“资源”，比如网关是云原生平台所管理的资源之一。资源在实例化之后叫做一个“实例”，比如网关被实例化后叫做网关实例。网关资源是抽象的，不占用云原生平台的计算资源，而网关实例则是具体的，需要占用对应的计算资源，比如CPU、硬盘、内存、网络带宽等。

需要说明的是，与传统的HTTP网关由一个网关实例作为网关入口不同，本申请实施例所提供的微服务网关包括多个网关实例，多个网关实例位于不同的命名空间中。

其中，命名空间是云原生平台为资源提供的一种组织机制，通过将云原生平台上的资源组织到不同的命名空间中，从而为资源提供一个作用域，实现资源的逻辑隔离，以方便不同的资源进行使用和管理。本申请实施例中，通过将不同的网关实例划分到不同的命名空间中，可以实现不同的服务对应不同的网关入口，从而将不同服务的外部访问入口进行隔离，减少因不同服务之间的资源竞争对服务稳定性和可靠性造成影响。

本申请实施例中，访问请求指的是从云原生平台外部向部署在云原生平台上的任一服务发起的请求，这种客户端与服务之间的访问请求所产生的流量也称为南北流量。本申请实施例所提供的方法能够针对云原生平台下海量服务的南北流量进行有效管理，降低服务的维护成本，并提高云原生平台的资源利用率。

其中，微服务网关是位于客户端与服务的中间层，用于将来自客户端的访问请求路由到云原生平台中的对应服务上。为了便于描述，把客户端的访问请求所指向的服务称为目标服务。

可以理解，访问请求中包含多种信息，如访问路径、请求的统一资源定位符(Uniform Resource Locator，URL)、请求方法(Get、Post)、请求头(Headers)、请求Cookies等。当接收到来自客户端的访问请求时，微服务网关对该访问请求进行解析，获取访问请求的内容，以确定访问请求所指向的目标服务。

为了确定访问请求所指向的目标服务，在一些实施例中，对访问请求进行解析，以确定访问请求指向的目标服务，具体为：对访问请求进行解析，以获取访问请求中的请求行。其中，请求行中记载有访问请求指向的访问路径。基于预先设置的配置信息中记载的服务与访问路径的对应关系，确定访问请求指向的目标服务。

具体来说，访问请求的请求报文具体可以分为请求行、请求头和请求体三部分。其中，请求行中记载有请求方法、请求路径(即访问请求指向的访问路径)和协议名称及版本号；请求头中记载有多个属性，格式为“属性名:属性值”，客户端可以通过在请求头中设置属性的方式向目标服务提供信息；请求体将多个请求参数的数据以键值对的形式编码成一个格式化串，客户端可以通过将请求参数的数据编入请求体来向目标服务传递请求参数。

本申请实施例中，通过对访问请求的请求报文进行解析，可以先将请求报文拆解为请求行、请求头和请求体三部分，进而从请求行中获取访问请求指向的访问路径。

需要特别说明的是，基于特定场景下的使用需求，本申请实施例允许对微服务网关进行相应配置，使得访问请求指向的访问路径既可以通过对访问请求中的请求行记载的访问路径进行解析获取，也可以通过对访问请求中的请求头(Headers)记载的属性进行解析获取，还可以从请求Cookies中获取，本申请实施例对此不作限定。

此外，对访问请求进行解析，既可以获取访问请求指向的访问路径，还可以根据微服务网关的配置信息中设置的访问路径前缀、请求方法、请求头参数，来对访问请求进行合法性认证，只有通过合法性认证的访问请求才会被正常路由，否则直接丢弃。

举例来说，如果在微服务网关的配置信息中设置有访问路径前缀：/user，请求方法：get/post，那么对访问请求进行解析后，仅访问路径前缀为/user，并且请求方法为get或者post的访问请求才能通过合法性认证，被正常路由，其它访问请求将直接被丢弃。

此外，为了能够基于访问路径确定访问请求指向的目标服务，在接收针对目标服务的访问请求之前，还需要在微服务网关的配置信息中建立服务与访问路径的对应关系。

本申请实施例中，可以通过监听云原生平台中相关资源的变化情况以建立服务与访问路径的对应关系。以Kubernetes为例，Ingress是Kubernetes中用于为云原生平台中的服务提供外部访问的访问入口的资源，Ingress的资源配置文件记录有从外部访问云原生平台内部服务的访问路径与服务之间的对应关系。基于此，微服务网关可以通过API-Server监听Ingress的资源配置文件的变化，根据Ingress的资源配置文件中的访问路径与服务之间的对应关系，在微服务网关中同步建立服务与访问路径的对应关系。

可以理解，在一些应用场景中，也可以由应用管理员通过自定义的方式建立服务与访问路径的对应关系。此外，为了方便操作，可以将相关功能统一封装成可视化界面，应用管理员可以通过可视化界面输入上述配置信息，以减少录入错误。

在配置信息中建立服务与访问路径的对应关系之后，即可根据访问请求指向的访问路径，确定访问请求指向的目标服务。

步骤S102、基于目标服务位于第一命名空间中，将访问请求路由至第一命名空间中的第一网关实例，以由第一网关实例将访问请求路由至目标服务。

目标服务作为云原生平台中的一种资源，其资源对象(实例)创建时，必然位于某个命名空间中。若目标服务创建时未指定命名空间，默认情况下，云原生平台会将其运行在系统预设的命名空间中；若目标服务创建时明确指定命名空间，则云原生平台会将目标服务运行在所指定的命名空间中。

为了便于描述，把目标服务所在的命名空间称为第一命名空间。通过解析目标服务的配置信息即可确定目标服务所在的第一命名空间。

需要说明的是，为了实现对目标服务的访问，在第一命名空间中部署和运行有第一网关实例。在确定目标服务所在的第一命名空间之后，将访问请求路由至第一命名空间中的第一网关实例，由第一网关实例将访问请求路由至目标服务。如此，由第一命名空间中的第一网关实例对目标服务的访问请求进行路由转发，实现了不同服务之间网关入口的相互隔离，使得各个服务的负载压力不会相互影响。

为了维护微服务网关的配置信息以及对网关实例的生命周期进行管理，在一些实施例中，微服务网关还包括多个网关控制面实例，多个网关控制面实例用于管理对应的网关实例；其中，第一网关控制面实例位于第一命名空间中；对应地，在将目标服务的访问请求路由至第一命名空间中的第一网关实例之前，该方法还包括：创建第一命名空间，并将目标服务纳入第一命名空间中；在第一命名空间中创建和运行第一网关控制面实例和第一网关实例；第一网关控制面实例用于管理第一网关实例。

本申请实施例中，网关控制面实例作为微服务网关的控制面组件，用于管理对应的网关实例，而网关实例作为微服务网关的数据面组件，用于对外提供服务接入的入口。每个网关实例均与网关控制面实例相对应，且该网关实例与对应的网关控制面实例位于相同的命名空间中。为了便于描述，将管理第一网关实例的网关控制面实例称为第一网关控制面实例。可以理解，第一网关实例与第一网关控制面实例均位于第一命名空间中。

其中，第一网关控制面实例用于管理第一网关实例。具体来说，第一网关控制面实例对第一网关实例的管理包括但不限于：第一网关控制面实例根据云原生平台中配置的服务路由规则动态更新第一网关实例中相应的配置信息，以最大限度减少访问请求连接的中断；监控第一网关实例的健康状态，并根据所监控到的第一网关实例的健康状态对第一网关实例相应的后端网关进行调整，以维持第一网关实例高效可靠地运行。

实际应用中，为了方便应用管理员对网关实例和大量的应用进行管理，本申请实施例将多个网关控制面实例封装成统一的网关控制台，允许应用管理员通过图形化、易操作的交互式界面分别对各自对应的网关实例进行管理，以实现微服务网关和服务接口的管理。

为了使第一网关实例能够对目标服务的访问请求进行正确路由，在将目标服务的访问请求路由至第一命名空间中的第一网关实例之前，首先创建第一命名空间，其中，第一命名空间可以通过输入指令的方式创建，也可以根据配置文件创建第一命名空间；然后，将目标服务纳入到第一命名空间中，其中，目标服务所在的第一命名空间可以在创建目标服务时以键值对的方式指定，也可以在目标服务创建完成后通过输入指令方式将所在命名空间指向第一命名空间；接着，在第一命名空间中创建和运行第一网关控制面实例和第一网关实例。

具体创建第一网关控制面实例和第一网关实例时，可以将第一网关控制面实例与第一网关实例以绑定的方式进行部署，比如部署在同一容器组(Pod)中；也可将第一网关控制面实例与第一网关实例分别进行部署，比如部署在不同的容器组中。其中，第一网关控制面实例可以Deployment的方式部署，第一网关实例可以Deployment的方式或Daemonset的方式部署；或者第一网关控制面实例和第一网关实例均以Deployment的方式部署，本申请实施例对此不作限定。

进一步地，在第一网关控制面实例和第一网关实例都采用Deployment的方式部署时，本申请实施例支持对第一网关控制面实例与第一网关实例分别进行动态扩容/缩容。应当理解，在将第一网关控制面实例和第一网关实例以Deployment的方式部署在容器组中时，云原生平台提供的横向自动扩容控制器(Horizontal Pod Autoscaler，HPA)能够基于监控指标数据对第一网关控制面实例和第一网关实例的副本数量进行调整。比如说，当监控到服务的负载压力增大时，对第一网关实例进行弹性扩容，以保证微服务网关的高可用性，当监控到服务的负载压力变小时，对第一网关实例进行弹性缩容，以节约资源。

虽然第一网关控制面实例能够根据云原生平台中配置的服务路由规则动态更新第一网关实例中相应的配置信息，使得访问请求能够正确路由到目标服务；但是，服务路由规则仅记载了访问路径与目标服务之间的对应关系，当目标服务本身发生变化，第一网关实例无法感知该变化，导致目标服务无法正常访问，为此，在一些实施例中，第一网关控制面实例用于管理第一网关实例，具体为：第一网关控制面实例基于配置信息在第一网关实例中植入第一功能插件；对应地，第一网关实例将访问请求路由至目标服务，具体为：第一网关控制面实例使用第一功能插件，并基于配置信息中记载的对应于第一网关实例的关键字键值对，对访问请求的请求头进行改写，使其能够对目标服务正常访问。

本申请实施例中，第一网关实例将独立的功能性组件封装成插件，每一个插件对应一个过滤器(Filter)，可以在微服务网关中按照需要的顺序通过配置信息植入多个过滤器，这些按顺序配置的过滤器形成过滤器链，其能够针对目标服务的访问请求进行拦截，每个过滤器负责对该访问请求执行特定的操作或任务，比如负载均衡、鉴权、访问路径重写、请求头改写等，客户端发送的访问请求依次在这些过滤器之间传递，直到被路由到目标服务。

为了识别目标服务本身发生的变化并对第一网关实例进行适应性配置，本申请实施例中，第一网关控制面实例基于预设的配置信息，在第一网关实例中植入第一功能插件，以在目标服务发生变化时，使得第一网关实例能够自动适配这种变化，并能够将访问请求正确路由到变化后的目标服务。

实际应用中，当目标服务发生变化时，应用管理员可以通过图形化界面将目标服务变化的信息以关键字键值对(key-value)的形式写入微服务网关的配置信息中，同时记录该关键字键值对与第一网关实例之间的对应关系，以由第一功能插件基于配置信息中记载的对应于第一网关实例的关键字键值对，对访问请求的请求头中记载的属性进行改写，使得目标服务能够被正常访问。

其中，第一网关控制面实例可以将第一功能插件与第一网关实例进行绑定部署，比如将其植入至第一网关实例所在的容器组中；也可以将第一功能插件与第一网关实例进行分别部署，比如将其植入至与第一网关实例所在容器组不同的容器组中。可以理解，当第一功能插件与第一网关实例进行分别部署时，二者可以根据动态负载压力进行分别扩容/缩容，以满足不同的需求。

具体实施时，在第一网关实例中植入第一功能插件后，第一网关控制面实例将第一功能插件设置为针对目标服务的访问请求过滤器链中的一个环节。当接收到客户端发送的针对目标服务的访问请求时，第一功能插件对该访问请求进行拦截，并基于配置信息中记载的对应于第一网关实例的关键字键值对，对访问请求的请求头中记载的属性进行改写，以将访问请求指向变化后的目标服务，从而使客户端能够对目标服务进行正常访问。

本申请实施例中，通过第一功能插件对访问请求的请求头进行改写，使得即使目标服务本身发生变化，第一网关实例也能动态适配变化后的目标服务，从而客户端在发出访问请求时无需根据目标服务的变化进行任何改动，即可按原有方式对目标服务进行正常访问，使得目标服务的变化对用户无感知。此外，通过第一网关控制面实例进行配置，并以插件方式实现对第一网关实例功能的扩展，大大增加了微服务网关的灵活性。

为了对第一网关实例的服务路由规则进行动态更新，在一些实施例中，云原生平台中还部署有路由资源对象，路由资源对象用于定义云原生平台中的服务路由规则；对应地，第一网关控制面实例用于管理第一网关实例，具体为：第一网关控制面实例监听云原生平台中路由资源对象的变化情况；响应于监听到路由资源对象发生变化，第一网关控制面实例根据变化后的路由资源对象更新第一网关实例的配置信息，以使第一网关实例符合变化后的服务路由规则。

本申请实施例中，云原生平台中的路由资源对象用于定义云原生平台中的服务路由规则，其中，服务路由规则用于定义服务与访问路径的对应关系。具体来说，当客户端向云原生平台中的目标服务发送访问请求时，访问请求中携带的访问路径为外部访问路径，微服务网关根据访问请求指向的访问路径，确定访问请求指向的目标服务的服务路径，并通过目标服务的服务路径将访问请求路由至目标服务。

以Kubernetes为例，路由资源对象例如可以是Kubernetes原生的Ingress资源对象，或者自定义的HTTP Proxy资源对象。在Kubernetes系统中，Ingress资源对象或HTTPProxy资源对象的配置文件中记录有服务路由规则，例如，访问路径，路径匹配方式，服务标识等。

实际应用中，第一网关控制面实例作为控制面组件，能够对路由资源对象进行管理，比如增加、更新、删除路由资源对象，并根据路由资源对象的变化动态更新第一网关实例的配置信息。

其中，动态更新第一网关实例的配置信息通过如下步骤实现：第一网关控制面实例通过云原生平台提供的监听接口实时监听路由资源对象的变化情况，当监听到路由资源对象发生变化时，比如发生增加、更新、删除的事件，表示服务路由规则发生了变化，第一网关控制面实例访问云原生平台提供的统一访问接口(比如API-Server)，从云原生平台获取变化后的路由资源对象的内容，并将这些变化后的内容转换为符合第一网关实例要求的配置信息，以使得第一网关实例符合变化后的服务路由规则。通过动态更新服务路由规则，使得第一网关实例能够不间断对外提供服务路由能力，极大降低了路由变动成本，减少丢失的链接带来的业务影响，提升了业务应用的可靠性。

为了对云原生平台中的资源进行有效配置和管理，在一些实施例中，第一命名空间中还包括资源配置对象，资源配置对象用于定义第一命名空间的资源阈值，第一命名空间的资源阈值用于限制第一命名空间中所有资源对象的资源占用总和的范围。

基于前述说明可知，本申请的微服务网关包括多个网关实例，多个网关实例位于不同的命名空间中，从而实现基于命名空间的计算资源隔离，使得不同网关实例的计算资源不会因负载压力不同而产生相互影响。

本申请实施例中，资源配置对象用于为第一命名空间的资源消耗总量提供限制，也就是定义第一命名空间的资源阈值，当第一命名空间中新增资源对象的导致所有资源占用总和超过所定义的资源阈值时，该新增资源对象的请求将会被拒绝，并返回报错信息。

其中，第一命名空间的资源阈值至少包括计算资源阈值和网络资源阈值，计算资源阈值包括CPU限额和内存限额，网络资源则包括网络带宽限额。

本申请实施例中，资源配置对象可以由应用管理员通过云原生平台的统一访问接口在第一命名空间中创建，也可以由应用管理员通过可视化界面创建，并在创建时指定其所属命名空间为第一命名空间。

当第一命名空间中创建资源配置对象时，云原生平台中的资源配置系统会跟踪第一命名空间中的所有资源对象的计算资源使用情况，以确保所有资源对象使用的计算资源不超过资源配置对象中所定义的资源阈值。

基于资源配置对象，使得云原生平台中的资源被多个用户(或者多个团队)共享、不同应用管理员管理不同应用时，可以通过基于角色(Role)的访问控制(RBAC)机制将命名空间与用户权限绑定，并在命名空间中创建资源配置对象，实现对计算资源或网络资源的调节和控制，使得不同应用能够独立地、动态地配置所需的计算资源或网络资源。

应当理解，当云原生平台的计算资源或网络资源总和小于各命名空间的资源阈值总和的情况下，各命名空间之间可能存在计算资源或网络资源竞争，此时，可以由云原生平台管理员修改云原生平台中各命名空间的资源阈值，使其满足云原生平台的计算资源或网络资源总和的限制；也可以在云原生平台中设置资源竞争调节机制，比如先到先得机制，以实现计算资源或网络资源存在竞争情景下的资源分配。

在一些实施例中，微服务网关还包括第二网关控制面实例和第二网关实例，第二网关控制面实例和第二网关实例位于第二命名空间中，第二网关控制面实例用于管理第二网关实例；该方法还包括：第二网关控制面实例基于配置信息在第二网关实例中植入第二功能插件，来为第一网关实例和第二网关实例提供不同的增强功能。

本申请实施例中，第二网关实例为微服务网关的多个网关实例中除第一网关实例以外的某一网关实例，第二网关控制面实例用于管理第二网关实例，且第二网关实例和第二网关控制面实例均位于第二命名空间中。

基于前述说明可知，微服务网关将独立的功能性组件封装成插件，因此，第二网关控制面实例基于配置信息在第二网关实例中植入第二功能插件，第二功能插件对应一个过滤器，由于多个网关实例位于不同的命名空间中，彼此之间实现逻辑上的隔离，第二功能插件与第一功能插件实现的功能可以不同，从而为第一网关实例和第二网关实例提供不同的增强功能。例如，第二功能插件可以为第二网关实例提供与第一网关实例不同的身份验证策略，或者提供不同的限流策略等。

综上所述，本申请中，将微服务网关拆分成多个网关实例，多个网关实例位于不同的命名空间中，当接收到访问请求时，对访问请求进行解析，进而确定访问请求指向的云原生平台中部署的目标服务，然后基于目标服务位于第一命名空间中，将访问请求路由到第一命名空间中的第一网关实例，以由第一网关实例将访问请求路由到目标服务。如此，将云原生平台的资源划归多个命名空间，以实现对不同网关实例的资源隔离，并将目标服务与第一网关实例组织到第一命名空间中，从而实现为云原生平台中属于不同命名空间的服务设置不同的网关入口，各网关入口之间相互隔离，即使某一服务的负载增大，也不会对其他服务产生影响；此外，由于不同的服务对应于不同的网关实例，使得应用管理员能够根据服务的负载情况对网关实例所占用的资源进行动态配置，提高了云原生平台的资源配置灵活性和利用效率。

本申请实施例中，通过将网关的数据面拆分为多个网关实例，由相应的网关控制面实例对其生命周期进行管理，并提供配置信息的动态更新，使网关实例能够不间断对外提供服务路由能力，避免因配置信息更新导致链接中断给业务带来的影响。

本申请实施例所提供的方法能够针对云原生平台下海量服务的南北流量进行有效管理，降低服务的维护成本，并提高云原生平台的资源利用率。

示例性系统

本申请实施例还提供一种云原生平台微服务网关的服务路由系统，如图5所示，该系统包括多个网关实例，多个网关实例位于不同的命名空间中，系统包括：解析单元501、路由单元502。其中：

解析单元501，配置为响应于接收到访问请求，对访问请求进行解析，以确定访问请求指向的目标服务；其中，目标服务为部署在云原生平台上任一服务；

路由单元502，配置为基于目标服务位于第一命名空间中，将访问请求路由至第一命名空间中的第一网关实例，以由第一网关实例将访问请求路由至目标服务。

本申请实施例提供的云原生平台微服务网关的服务路由系统，能够实现上述任一实施例提供的云原生平台微服务网关的服务路由方法的流程、步骤，并达到相同的技术效果，在此不再一一赘述。

示例性设备

图6为根据本申请的一些实施例提供的电子设备的结构示意图；如图6所示，该电子设备包括：

一个或多个处理器601；

计算机可读介质，可以配置为存储一个或多个程序602，一个或多个处理器601执行一个或多个程序602时，实现如下步骤：响应于接收到访问请求，对访问请求进行解析，以确定访问请求指向的目标服务；其中，目标服务为部署在云原生平台上任一服务；基于目标服务位于第一命名空间中，将访问请求路由至第一命名空间中的第一网关实例，以由第一网关实例将访问请求路由至目标服务。

图7为根据本申请的一些实施例提供的电子设备的硬件结构；如图7所示，该电子设备的硬件结构可以包括：处理器701、通信接口702、计算机可读介质703和通信总线704。

其中，处理器701、通信接口702、计算机可读存储介质703通过通信总线704完成相互间的通信。

可选地，通信接口702可以为通信模块的接口，如GSM模块的接口。

其中，处理器701具体可以配置为：响应于接收到访问请求，对访问请求进行解析，以确定访问请求指向的目标服务；其中，目标服务为部署在云原生平台上任一服务；基于目标服务位于第一命名空间中，将访问请求路由至第一命名空间中的第一网关实例，以由第一网关实例将访问请求路由至目标服务。

处理器701可以是通用处理器，包括中央处理器(central processing unit，简称CPU)、网络处理器(Network Processor，简称NP)等，还可以是数字信号处理器(DSP)、专用集成电路(ASIC)、现成可编程门阵列(FPGA)或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件。可以实现或者执行本申请实施例中的公开的各方法、步骤及逻辑框图。通用处理器可以是微处理器或者该处理器也可以是任何常规的处理器等。

本申请实施例的电子设备以多种形式存在，包括但不限于：

(1)移动通信设备：这类设备的特点是具备移动通信功能，并且以提供话音、数据通信为主要目标。这类终端包括：智能手机(例如：iPhone)、多媒体手机、功能性手机，以及低端手机等。

(2)超移动个人计算机设备：这类设备属于个人计算机的范畴，有计算和处理功能，一般也具备移动上网特性。这类终端包括：PDA、MID和UMPC设备等，例如iPad。

(3)便携式娱乐设备：这类设备可以显示和播放多媒体内容。该类设备包括：音频、视频播放器(例如：iPod)，掌上游戏机，电子书，以及智能玩具和便携式车载导航设备。

(4)服务器：提供计算服务的设备，服务器的构成包括处理器、硬盘、内存、系统总线等，服务器和通用的计算机架构类似，但是由于需要提供高可靠的服务，因此在处理能力、稳定性、可靠性、安全性、可扩展性、可管理性等方面要求较高。

(5)其他具有数据交互功能的电子装置。

需要指出，根据实施的需要，可将本申请实施例中描述的各个部件/步骤拆分为更多部件/步骤，也可以将两个或多个部件/步骤或者部件/步骤的部分操作组合成新的部件/步骤，以实现本申请实施例的目的。

上述根据本申请实施例的方法可在硬件、固件中实现，或者被实现为可存储在记录介质(诸如CD ROM、RAM、软盘、硬盘或磁光盘)中的软件或计算机代码，或者被实现通过网络下载的原始存储在远程记录介质或非暂时机器存储介质中并将被存储在本地记录介质中的计算机代码，从而在此描述的方法可被存储在使用通用计算机、专用处理器或者可编程或专用硬件(诸如ASIC或FPGA)的记录介质上的这样的软件处理。可以理解，计算机、处理器、微处理器控制器或可编程硬件包括可存储或接收软件或计算机代码的存储组件(例如，RAM、ROM、闪存等)，当软件或计算机代码被计算机、处理器或硬件访问且执行时，实现在此描述的云原生平台微服务网关的服务路由方法。此外，当通用计算机访问用于实现在此示出的方法的代码时，代码的执行将通用计算机转换为用于执行在此示出的方法的专用计算机。

本领域普通技术人员可以意识到，结合本文中所公开的实施例描述的各示例的单元及方法步骤，能够以电子硬件、或者计算机软件和电子硬件的结合来实现。这些功能究竟以硬件还是软件方式来执行，取决于技术方案的特定应用和涉及约束条件。专业技术人员可以对每个特定的应用来使用不同方法来实现所描述的功能，但是这种实现不应认为超出本申请实施例的范围。

需要说明的是，本说明书中的各个实施例均采用递进的方式描述，各个实施例之间相同相似的部分互相参见即可，每个实施例重点说明的都是与其他实施例的不同之处。尤其，对于设备及系统实施例而言，由于其基本相似于方法实施例，所以描述得比较简单，相关之处参见方法实施例的部分说明即可。

以上所描述的设备及系统实施例仅仅是示意性的，其中作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元提示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部模块来实现本实施例方案的目的。本领域普通技术人员在不付出创造性劳动的情况下，即可以理解并实施。

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

Claims (10)

1.一种云原生平台微服务网关的服务路由方法，其特征在于，所述微服务网关包括多个网关实例，所述多个网关实例位于不同的命名空间中，所述方法包括：

响应于接收到访问请求，对所述访问请求进行解析，以确定所述访问请求指向的目标服务；其中，所述目标服务为部署在云原生平台上任一服务；

基于所述目标服务位于第一命名空间中，将所述访问请求路由至所述第一命名空间中的第一网关实例，以由所述第一网关实例将所述访问请求路由至所述目标服务；

所述微服务网关运行在业务系统中，不同的服务对应于不同的网关实例，以实现任一所述服务的负载变化不会对其他服务产生影响。

2.根据权利要求1所述的云原生平台微服务网关的服务路由方法，其特征在于，所述对所述访问请求进行解析，以确定所述访问请求指向的目标服务，具体为：

对所述访问请求进行解析，以获取所述访问请求中的请求行；其中，所述请求行中记载有所述访问请求指向的访问路径；

基于预先设置的配置信息中记载的服务与访问路径的对应关系，确定所述访问请求指向的目标服务。

3.根据权利要求2所述的云原生平台微服务网关的服务路由方法，其特征在于，所述微服务网关还包括多个网关控制面实例，所述多个网关控制面实例用于管理对应的网关实例；其中，所述第一网关控制面实例位于所述第一命名空间中；

对应地，在将所述目标服务的访问请求路由至所述第一命名空间中的第一网关实例之前，所述方法还包括：

创建所述第一命名空间，并将所述目标服务纳入所述第一命名空间中；

在所述第一命名空间中创建和运行所述第一网关控制面实例和所述第一网关实例；所述第一网关控制面实例用于管理所述第一网关实例。

4.根据权利要求3所述的云原生平台微服务网关的服务路由方法，其特征在于，所述第一网关控制面实例用于管理所述第一网关实例，具体为：

所述第一网关控制面实例基于所述配置信息在所述第一网关实例中植入第一功能插件；

对应地，所述第一网关实例将所述访问请求路由至所述目标服务，具体为：

所述第一网关控制面实例使用所述第一功能插件，并基于所述配置信息中记载的对应于第一网关实例的关键字键值对，对所述访问请求的请求头进行改写，使其能够对所述目标服务正常访问。

5.根据权利要求4所述的云原生平台微服务网关的服务路由方法，其特征在于，所述云原生平台中还部署有路由资源对象，所述路由资源对象用于定义所述云原生平台中的服务路由规则；

对应地，所述第一网关控制面实例用于管理所述第一网关实例，具体为：

所述第一网关控制面实例监听所述云原生平台中所述路由资源对象的变化情况；

响应于监听到所述路由资源对象发生变化，所述第一网关控制面实例根据变化后的路由资源对象更新所述第一网关实例的配置信息，以使所述第一网关实例符合变化后的服务路由规则。

6.根据权利要求1所述的云原生平台微服务网关的服务路由方法，其特征在于，所述第一命名空间中还包括资源配置对象，所述资源配置对象用于定义所述第一命名空间的资源阈值，所述第一命名空间的资源阈值用于限制所述第一命名空间中所有资源对象的资源占用总和的范围。

7.根据权利要求4所述的云原生平台微服务网关的服务路由方法，其特征在于，所述微服务网关还包括第二网关控制面实例和第二网关实例，所述第二网关控制面实例和所述第二网关实例位于第二命名空间中，所述第二网关控制面实例用于管理所述第二网关实例；所述方法还包括：

所述第二网关控制面实例基于所述配置信息在所述第二网关实例中植入第二功能插件，来为所述第一网关实例和所述第二网关实例提供不同的增强功能。

8.一种云原生平台微服务网关的服务路由系统，其特征在于，包括多个网关实例，所述多个网关实例位于不同的命名空间中，所述系统包括：

解析单元，配置为响应于接收到访问请求，对所述访问请求进行解析，以确定所述访问请求指向的目标服务；其中，所述目标服务为部署在云原生平台上任一服务；

路由单元，配置为基于所述目标服务位于第一命名空间中，将所述访问请求路由至所述第一命名空间中的第一网关实例，以由所述第一网关实例将所述访问请求路由至所述目标服务；

所述微服务网关运行在业务系统中，不同的服务对应于不同的网关实例，以实现任一所述服务的负载变化不会对其他服务产生影响。

9.一种计算机可读存储介质，其上存储有计算机程序，其特征在于，所述计算机程序为如权利要求1-7任一所述的云原生平台微服务网关的服务路由方法。

10.一种电子设备，其特征在于，包括：存储器、处理器、以及存储在所述存储器中并可在所述处理器上运行的程序，所述处理器执行所述程序时实现如权利要求1-7任一所述的云原生平台微服务网关的服务路由方法。

Images