CN114253707B - 一种基于api网关的微服务请求方法 - Google Patents

Abstract

本发明公开了一种基于API网关的微服务请求方法，该方法包括：获取客户端的路由请求，并对所述请求进行签名校验，所述路由请求包括静态路由或服务注册发现；在签名校验通过后，对所述请求进行路由，并通过所述API网关内的插件对所述请求进行处理；向客户端返回用户请求对应的微服务，通过丰富的插件能力提供IP黑白名单、限流、认证、降级、缓存等能力；提供网关、服务等不同维度的运行时监控和告警能力来实时监控请求处理情况，提供调用审计以及统计功能对请求进行统计分析，提高了现有API网关的适用性，提高用户的使用体验。

Description

一种基于API网关的微服务请求方法

技术领域

本申请涉及计算机领域，更具体地，涉及一种基于API网关的微服务请求方法。

背景技术

API网关作为微服务架构中的核心组件，是流量的核心出入口，用于连接所有微服务和API。使用时，调用方仅需依赖API网关，而不需要维护多个微服务的访问地址。API网关在接收到请求时，需要对请求进行路由。

近年来，随着微服务概念的提出，基于微服务架构的开发和集成模式逐渐成为热点。在微服务架构下，为了保护内部服务而设计的一道屏障，通过提供高性能的API托管服务以帮助应用服务的开发人员便捷地对外提供服务，不用考虑安全控制、流量控制、审计日志等问题。在企业信息化环境中，由于不同系统间存在大量的API接口互相调用，因此需要对系统间服务调用进行服务订阅、调用管理以便清晰地看到各系统调用关系。

然而，虽然API网关能够通过企业内外部应用对企业内服务的访问进行有效的管理和监控，但是随着产业链上下游企业信息化交互程度的深入，企业间的横向应用集成需求变得愈发强烈，现有的API网关的微服务技术不能满足用户的需求

因此，提供一种基于API网关的微服务请求方法，用以提高现有API网关的适用性，提高用户的使用体验是目前有待解决的技术问题。

发明内容

本发明提供一种基于API网关的微服务请求方法，用以解决现有技术中API网关的适用性低，无法根据需求自定义网关的功能的问题。

该方法包括：

获取客户端的路由请求，并对所述请求进行签名校验，所述路由请求包括静态路由或服务注册发现；

在签名校验通过后，对所述请求进行路由，并通过所述API网关内的插件对所述请求进行处理；

向客户端返回用户请求对应的微服务。

在本申请一些实施例中，对所述请求进行签名校验具体为：

通过网关加载签名认证Fillter，完成对签名功能的支持；

检查请求的公共参数是否合法，所述公共参数包含签名算法的版本、日期等；

在所述公共参数合法后，获取请求方法及请求规范URI；

基于生成信息合成待签名字符串，所述生成信息包括规范查询字符串、已签名Header及规范Header；

发送所述待签名字符串对认证服务进行校验；

根据验证结果判断签名是否正确，对所述请求进行路由；

如果不正确，则签名不正确，返回给调用方签名不匹配的结果。

在本申请一些实施例中，所述插件包括缓存插件及认证插件。

在本申请一些实施例中，所述缓存插件的工作流程具体为：

判断是否绑定插件且满足cache条件；

若是则计算缓存key，并判断本地缓存是否命中；

若否则继续其他处理并将所述请求转发至后端服务。

在本申请一些实施例中，若是则计算缓存key，并判断本地缓存是否命中之后，还包括：

若本地缓存命中，则使用缓存结果响应，并向客户端返回响应结果；

若本地缓存未命中，则判断Redis缓存是否命中；

若Redis缓存命中，则判断次级缓存是否填充；

若Redis缓存未命中，则继续其他处理并将所述请求转发至后端服务。

在本申请一些实施例中，判断次级缓存是否填充，具体为：

若所述次级缓存填充，则写入本地缓存，并使用缓存结果响应，并向客户端返回响应结果；

若所述次级缓存未填充，则直接使用缓存结果响应，并向客户端返回响应结果。

在本申请一些实施例中，继续其他处理并将所述请求转发至后端服务之后，具体为：

在继续其他处理并将所述请求转发至后端服务后，获取响应，并判断是否满足写入缓存条件；

若满足写入缓存条件，则写入缓存，并响应客户端；

若不满足写入缓存条件，则直接响应客户端。

在本申请一些实施例中，所述认证插件的工作流程，具体为：

在绑定super-auth插件后，判断所述请求中是否携带认证信息；

若是，则确定所述super-auth认证鉴权是否通过；

若否，则拒绝客户端访问。

在本申请一些实施例中，确定所述super-auth认证鉴权是否通过，具体为：

若通过验证，则在所述请求中添加认证信息，并继续其他处理并将所述请求转发至后端服务；

若未通过验证，则判断是否允许匿名访问。

在本申请一些实施例中，判断是否允许匿名访问。具体为：

若允许，则继续其他处理并将所述请求转发至后端服务；

若不允许，则拒绝客户端的访问。

通过应用以上技术方案，获取客户端的路由请求，并对所述请求进行签名校验，所述路由请求包括静态路由或服务注册发现；在签名校验通过后，对所述请求进行路由，并通过所述API网关内的插件对所述请求进行处理；向客户端返回用户请求对应的微服务，在Istio实现上增强了Istio的功能，扩展了Istio控制面以及数据面，开发多款自研插件以及提供自研aggra框架便于用户根据自己需求进行功能扩展，提高了现有API网关的适用性，提高用户的使用体验。

附图说明

为了更清楚地说明本申请实施例中的技术方案，下面将对实施例描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本申请的一些实施例，对于本领域技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。

图1示出了本发明实施例提出的一种基于API网关的微服务请求方法的流程示意图；

图2示出了本发明实施例提出的一种缓存插件的流程示意图；

图3示出了本发明实施例中提出的一种认证插件的流程示意图。

具体实施方式

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

本申请实施例提供一种基于API网关的微服务请求方法，如图1所示，包括以下步骤：

步骤S101，获取客户端的路由请求，并对所述请求进行签名校验，所述路由请求包括静态路由或服务注册发现。

操作系统是用户与计算机硬件系统之间的接口，用户通过操作系统的帮助，可以快速、有效和安全、可靠地操纵计算机系统中的各类资源，以处理自己的程序。为使用户能方便地使用操作系统，OS又向用户提供了如下两类接口：

(1)用户接口：操作系统专门为用户提供了“用户与操作系统的接口”，通常称为用户接口。该接口支持用户与OS之间进行交互，即由用户向OS请求提供特定的服务，而系统则把服务的结果返回给用户。

(2)程序接口：操作系统向编程人员提供了“程序与操作系统的接口”，简称程序接口，又称应用程序接口API(Application Programming Interface)。该接口是为程序员在编程时使用的，系统和应用程序通过这个接口，可在执行中访问系统中的资源和取得OS的服务，它也是程序能取得操作系统服务的唯一途径。大多数操作系统的程序接口是由一组系统调用(system call)组成，每一个系统调用都是一个能完成特定功能的子程序[2]。

应用程序接口又称为应用编程接口，是一组定义、程序及协议的集合，通过API接口实现计算机软件之间的相互通信。API的一个主要功能是提供通用功能集。API同时也是一种中间件，为各种不同平台提供数据共享。程序设计的实践中，编程接口的设计首先要使软件系统的职责得到合理划分。良好的接口设计可以降低系统各部分的相互依赖，提高组成单元的内聚性，降低组成单元间的耦合程度，从而提高系统的可维护性和可扩展性。

微服务(或微服务架构)是一种云原生架构方法，其中单个应用程序由许多松散耦合且可独立部署的较小组件或服务组成。这些服务通常有自己的堆栈，包括数据库和数据模型；通过REST API，事件流和消息代理的组合相互通信；它们是按业务能力组织的，分隔服务的线通常称为有界上下文。尽管有关微服务的许多讨论都围绕体系结构定义和特征展开，但它们的价值可以通过相当简单的业务和组织收益更普遍地理解：可以更轻松地更新代码。团队可以为不同的组件使用不同的堆栈。组件可以彼此独立地进行缩放，从而减少了因必须缩放整个应用程序而产生的浪费和成本，因为单个功能可能面临过多的负载。

静态路由(Static Routing)是一种路由的方式，它的路由项是手动配置的，并不是动态决定的。静态路由与动态路由不同，它是固定不变的，即使网络状况已经改变或是重新被组态。一般地，静态路由是由网络管理员逐项加入路由表中去的。

首先，路由器会检查数据帧目标地址字段中的数据链路标识。(如果它包含了路由器接口标识符或广播标识符，那么路由器将从帧中剥离出数据包并传递给网络层)。在网络层，路由器将检查数据包的目标地址。(如果目标地址是路由器接口的IP地址或是所有主机的广播地址，那么需要进一步检查数据包的协议字段，然后再把被封装的数据发送给适当的内部进程)。除此之外，所有其他的目标地址都需要进行路有选择，这里的目标地址可能是另一个网络的主机地址，该网络或者与路由相连，或者不直接连接在路由器上，目标地址还可能是一个定向的广播地址，这种地址有明确的网络地址或子网地址并且主机位全部为1，这些地址也是可以路由的。

在数据库中，每个路由表项最少包括以下两种字段：

1、目标地址：这是路由器可以到达的网络地址。路由器可能会有多条路径到达相同的地址或是相同主网IP地址的下一组等长或变长的子网。

2、指向目标的指针：指针不是指向路由器的直连目标网络就是指向直连网络内的另一台路由地址，或者是到这个链路的本地接口。更接近目标网络一跳的路由器叫下一跳(next hop)路由器。

路由不可达的过程：如果数据包的目标地址不能匹配到任何一条路由表项，那么数据包将被丢弃，同时一个“目标网络不可达”的ICMP消息将会被发送给源地址。

服务注册就是将提供某个服务的模块信息(通常是这个服务的ip和端口)注册到1个公共的组件上去(比如:zookeeper\consul)。

服务发现就是新注册的这个服务模块能够及时的被其他调用者发现。不管是服务新增和服务删减都能实现自动发现。

在微服务时代，我们所有的服务都被劲量拆分成最小的粒度，原先所有的服务都在混在1个server里，现在就被按照功能或者对象拆分成N个服务模块，这样做的好处是深度解耦，1个模块只负责自己的事情就好，能够实现快速的迭代更新。坏处就是服务的管理和控制变得异常的复杂和繁琐，人工维护难度变大。还有排查问题和性能变差(服务调用时的网络开销)。

在不用服务注册之前，一般将其他模块的ip和端口写死在自己的配置文件里，甚至写死在代码里，每次要去新增或者移除1个服务的实例的时候，就得去通知其他所有相关联的服务去修改。随之而来的就是各个项目的配置文件的反复更新、每隔一段时间大规模的ip修改和机器裁撤，非常的痛苦。通过服务注册和发现的方式，维护各个服务IP列表的更新，各个模块只需要向名字服务中心去获取某个服务的IP就可以了，不用再写死IP。整个服务的维护也变得轻松了很多。彻底解放了双手！

服务注册是一个记录当前可用的微服务实例的网络信息数据库，是服务发现机制的主要核心，服务注册表查询api、管理api，使用查询api获得可用服务的实例，使用管理api实现注册、注销。节点启动后，会在Eureka Server中进行注册，这样EurekaServer中的服务注册表中将会存储所有可用服务节点的信息，服务节点的信息可以在界面中直观的看到。

为了进行签名校验，在本申请的优选实施例中，对所述请求进行签名校验具体为：

通过网关加载签名认证Fillter，完成对签名功能的支持；

检查请求的公共参数是否合法，所述公共参数包含签名算法的版本、日期等；

在所述公共参数合法后，获取请求方法及请求规范URI；

基于生成信息合成待签名字符串，所述生成信息包括规范查询字符串、已签名Header及规范Header；

发送所述待签名字符串对认证服务进行校验；

根据验证结果判断签名是否正确，对所述请求进行路由；

如果不正确，则签名不正确，返回给调用方签名不匹配的结果。

具体的，API网关校验签名的具体步骤为：

1、网关加载签名认证Fillter，完成对签名功能的支持；

2、检查请求的公共参数是否合法，包含签名算法的版本、日期等；如果签名合法则进入步骤3，如果不合法跳转到步骤11执行；

3、获取请求方法；

4、获取请求规范URI；

5、生成规范查询字符串；

6、生成已签名Header；

7、生成规范Header；

8、合成待签名字符串；

9、发送上述信息去认证服务(service-auth)进行校验；

10、根据返回结果，判断签名是否正确，如果正确则进入下一阶段，如果不正确则执行步骤11。

11、签名不正确，返回给调用方签名不匹配的结果。

从步骤中可以看出，API网关会依赖认证服务(service-auth)去校验签名，这是因为AK/SK的信息网关不会存储，统一由签名认证服务来管理。

在本申请一些实施例中，所述插件包括缓存插件及认证插件。

具体的，其一API网关的缓存是有效降低真正的API提供方的压力，从而一步步减少API服务提供者的应用容器、应用缓存和数据库的的压力。其二API网关的缓存可以有效降低后台API的访问时间，从API网关直接访问缓存，如果命中缓存，那么就无需请求真正的API提供方，大大降低访问时间。

对于一些幂等的get请求，可以在网关层面根据业务方指定的缓存头做一层缓存，存储到Redis等二级缓存中，这样一些重复的请求，可以在网关层直接处理，而不用打到业务线，降低业务方的压力，另外如果业务方节点挂掉，网关也能够返回自身的缓存。

需要说明的是，上述插件包括但不限于缓存插件及认证插件，本领域技术人员可以根据实际需要进行插件的更换和添加，以满足使用需求。

步骤S102，在签名校验通过后，对所述请求进行路由，并通过所述API网关内的插件对所述请求进行处理。

在签名校验通过后，对所述请求进行路由，并通过所述API网关内的插件对所述请求进行处理，以实现对请求的快速响应，寻找对应的微服务。

为了保证缓存插件的正常工作，在本申请一些实施例中，所述缓存插件的工作流程具体为：

判断是否绑定插件且满足cache条件；

若是则计算缓存key，并判断本地缓存是否命中；

若否则继续其他处理并将所述请求转发至后端服务。

如图2所示，判断是否绑定插件且满足cache条件；若是则计算缓存key，并判断本地缓存是否命中；若否则继续其他处理并将所述请求转发至后端服务。

为了保证缓存插件的正常工作，在本申请一些实施例中，若是则计算缓存key，并判断本地缓存是否命中之后，还包括：

若本地缓存命中，则使用缓存结果响应，并向客户端返回响应结果；

若本地缓存未命中，则判断Redis缓存是否命中；

若Redis缓存命中，则判断次级缓存是否填充；

若Redis缓存未命中，则继续其他处理并将所述请求转发至后端服务。

具体的，若本地缓存命中，则使用缓存结果响应，并向客户端返回响应结果；若本地缓存未命中，则判断Redis缓存是否命中；若Redis缓存命中，则断次级缓存是否填充；若Redis缓存未命中，则继续其他处理并将所述请求转发至后端服务

为了保证缓存插件的正常工作，判断次级缓存是否填充，具体为：

若所述次级缓存填充，则写入本地缓存，并使用缓存结果响应，并向客户端返回响应结果；

若所述次级缓存未填充，则直接使用缓存结果响应，并向客户端返回响应结果。

具体的，若所述次级缓存填充，则写入本地缓存，并使用缓存结果响应，并向客户端返回响应结果；若所述次级缓存未填充，则直接使用缓存结果响应，并向客户端返回响应结果。

为了保证缓存插件的正常工作，在本申请一些实施例中，继续其他处理并将所述请求转发至后端服务之后，具体为：

在继续其他处理并将所述请求转发至后端服务后，获取响应，并判断是否满足写入缓存条件；

若满足写入缓存条件，则写入缓存，并响应客户端；

若不满足写入缓存条件，则直接响应客户端。

为了保证认证插件的正常工作，在本申请一些实施例中，如图3所示，所述认证插件的工作流程，具体为：

在绑定super-auth插件后，判断所述请求中是否携带认证信息；

若是，则确定所述super-auth认证鉴权是否通过；

若否，则拒绝客户端访问。

为了保证认证插件的正常工作，在本申请一些实施例中，确定所述super-auth认证鉴权是否通过，具体为：

若通过验证，则在所述请求中添加认证信息，并继续其他处理并将所述请求转发至后端服务；

若未通过验证，则判断是否允许匿名访问。

为了保证认证插件的正常工作，判断是否允许匿名访问。具体为：

若允许，则继续其他处理并将所述请求转发至后端服务；

若不允许，则拒绝客户端的访问。

步骤S3，向客户端返回用户请求对应的微服务。

本方案中的API网关提供了丰富的路由配置能力，基于Path、Host、Method、Header、Query进行路由。在请求路由时，支持静态路由和服务注册发现两种方式，并且目前支持对接多个注册中心，包括K8s，Consul以及Eureka注册中心。提供针对多服务实例的软负载均衡能力，同时支持多维度的分流；在请求处理阶段，通过丰富的插件能力提供IP黑白名单、限流、认证、降级、缓存等能力；提供网关、服务等不同维度的运行时监控和告警能力来实时监控请求处理情况，提供调用审计以及统计功能对请求进行统计分析。

负载均衡：有两个用途，1.将负载均衡的分配到多个处理节点上，减少单个处理节点的请求量，提升整体系统的性能。2.作为流量入口，对请求方屏蔽服务节点的部署细节，实现对业务方无感的扩容。

可以分为两大类：一类是代理类的负载均衡服务；另一类是客户端负载均衡服务。

代理类的负载均衡服务以单独的服务方式部署，请求先经过负载均衡服务，由负载均衡服务选出一个合适的服务节点后，来实现流量的分发。常见的比较著名的代理服务有lvs和nginx；LVS一般称为四层负载；Nginx一般称为七层负载。lvs性能比nginx好，但lvs工作在tcp层，请求的URL是七层的概念，不能针对URL做更细致的请求分发，而且LVS也没有提供探测后端服务是否存活的机制。一般这么认为LVS适合在入口处承担大流量的请求分发，Nginx部署在业务服务器之前做更细维度的请求分发。

客户端负载均衡，也就是把负载均衡的服务内嵌在客户端中。这类一般会结合注册中心使用，客户端从注册中心中获取服务的列表，根据策略选取一个合适的节点，分发请求到该节点。

负载均衡策略一般可分为两类：静态策略、动态策略

静态策略：指选择服务节点时，不会参考后端服务的实际运行状态。常见的静态策略有：轮询、加权轮询、hash算法等

动态策略：会参考后端服务的一些特性，来决定要选择哪个服务节点。负载均衡服务收集后端服务的调用信息，例如连接数、响应时间等，根据收集的信息进行负载均衡。

限流对于每个业务组件来说，可以说都是一个必须的组件，如果限流做不好的话，当请求量突增时，很容易导致业务方的服务挂掉，比如双11、双12等大促时，接口的请求量是平时的数倍，如果没有评估好容量，又没有做限流的话，很容易服务整个不可用，因此需要根据业务方接口的处理能力，做好限流策略，相信大家都见过淘宝、百度抢红包时的降级页面。

因此一定要在接入层做好限流策略，对于非核心接口可以直接将降级掉，保障核心服务的可用性，对于核心接口，需要根据压测时得到的接口容量，制定对应的限流策略。限流又分为几种:

1、单机。单机性能比较高，不涉及远程调用，只是本地计数，对接口RT影响最小。但需要考虑下限流数的设置，比如是针对单台网关、还是整个网关集群，如果是整个集群的话，需要考虑到网关缩容、扩容时修改对应的限流数。

2、分布式。分布式的就需要一个存储节点维护当前接口的调用数，比如redis、sentinel等，这种方式由于涉及到远程调用，会有些性能损耗，另外也需要考虑到存储挂掉的问题，比如redis如果挂掉，网关需要考虑降级方案，是降级到本地限流，还是直接将限流功能本身降级掉。

另外还有不同的策略:简单计数、令牌桶等，大部分场景下其实简单计数已经够用了，但如果需要支持突发流量等场景时，可以采用令牌桶等方案。还需要考虑根据什么限流，比如是IP、接口、用户维度、还是请求参数中的某些值，这里可以采用表达式，相对比较灵活。

通过应用以上技术方案，获取客户端的路由请求，并对所述请求进行签名校验，所述路由请求包括静态路由或服务注册发现；在签名校验通过后，对所述请求进行路由，并通过所述API网关内的插件对所述请求进行处理；向客户端返回用户请求对应的微服务，在Istio实现上增强了Istio的功能，扩展了Istio控制面以及数据面，开发多款自研插件以及提供自研aggra框架便于用户根据自己需求进行功能扩展，提高了现有API网关的适用性，提高用户的使用体验。

最后应说明的是：以上实施例仅用以说明本申请的技术方案，而非对其限制；尽管参照前述实施例对本申请进行了详细的说明，本领域的普通技术人员当理解：其依然可以对前述各实施例所记载的技术方案进行修改，或者对其中部分技术特征进行等同替换；而这些修改或者替换，并不驱使相应技术方案的本质脱离本申请各实施例技术方案的精神和范围。

Claims (6)

1.一种基于API网关的微服务请求方法，其特征在于，所述方法包括：

获取客户端的路由请求，并对所述请求进行签名校验，所述路由请求包括静态路由或服务注册发现；

在签名校验通过后，对所述请求进行路由，并通过所述API网关内的插件对所述请求进行处理；

向客户端返回用户请求对应的微服务；

其中，所述插件包括缓存插件及认证插件；

所述认证插件的工作流程，具体为：在绑定super-auth插件后，判断所述请求中是否携带认证信息，若是，则确定所述super-auth认证鉴权是否通过，若否，则拒绝客户端访问；

确定所述super-auth认证鉴权是否通过，具体为，若通过验证，则在所述请求中添加认证信息，并继续其他处理并将所述请求转发至后端服务，若未通过验证，则判断是否允许匿名访问；

对所述请求进行签名校验具体为：

通过网关加载签名认证Fillter，完成对签名功能的支持；

检查请求的公共参数是否合法，所述公共参数包含签名算法的版本、日期等；

在所述公共参数合法后，获取请求方法及请求规范URI；

基于生成信息合成待签名字符串，所述生成信息包括规范查询字符串、已签名Header及规范Header；

发送所述待签名字符串对认证服务进行校验；

根据验证结果判断签名是否正确，对所述请求进行路由；

如果不正确，则签名不正确，返回给调用方签名不匹配的结果。

2.如权利要求1所述的方法，其特征在于，所述缓存插件的工作流程具体为：

判断是否绑定插件且满足cache条件；

若是则计算缓存key，并判断本地缓存是否命中；

若否则继续其他处理并将所述请求转发至后端服务。

3.如权利要求2所述的方法，其特征在于，若是则计算缓存key，并判断本地缓存是否命中之后，还包括：

若本地缓存命中，则使用缓存结果响应，并向客户端返回响应结果；

若本地缓存未命中，则判断Redis缓存是否命中；

若Redis缓存命中，则判断次级缓存是否填充；

若Redis缓存未命中，则继续其他处理并将所述请求转发至后端服务。

4.如权利要求3所述的方法，其特征在于，判断次级缓存是否填充，具体为：

若所述次级缓存填充，则写入本地缓存，并使用缓存结果响应，并向客户端返回响应结果；

若所述次级缓存未填充，则直接使用缓存结果响应，并向客户端返回响应结果。

5.如权利要求2所述的方法，其特征在于，继续其他处理并将所述请求转发至后端服务之后，具体为：

在继续其他处理并将所述请求转发至后端服务后，获取响应，并判断是否满足写入缓存条件；

若满足写入缓存条件，则写入缓存，并响应客户端；

若不满足写入缓存条件，则直接响应客户端。

6.如权利要求1所述的方法，其特征在于，判断是否允许匿名访问，具体为：

若允许，则继续其他处理并将所述请求转发至后端服务；

若不允许，则拒绝客户端的访问。