CN109672612A - Api网关系统 - Google Patents

Abstract

本发明公开了一种API网关系统，所述方法包括：DNS负载均衡器，用于接收不同来源的HTTP服务访问请求，对所述HTTP服务访问请求进行处理，将处理后的HTTP服务访问请求负载均衡到基于OpenResty的API Gataway网关集群；将所述微服务返回的数据发送到用户；基于OpenResty的API网关集群，包括多个OpenResty API网关，用于对所述HTTP服务访问请求进行身份认证和权限认证，并将所述HTTP服务访问请求负载到不同的Web/Mobile API网关，或者，将所述HTTP服务访问请求直接发送到相应的微服务；将所述微服务返回的数据发送到DNS负载均衡器；Web/Mobile API网关，用于将所述HTTP服务访问请求路由到适当的微服务，并将所述微服务返回的数据反馈给所述基于OpenResty的API网关集群。

Description

API网关系统

技术领域

本发明涉及通信领域，尤其涉及一种API网关系统。

背景技术

API Gateway(API GW/API网关)是企业IT在系统边界上提供给外部访问内部接口服务的统一入口。API网关是将各系统对外暴露的服务聚合起来，所有要调用这些服务的系统都需要通过API网关进行访问，基于这种方式网关可以对API进行统一管控，例如：认证、鉴权、流量控制、协议转换、监控等等。API网关的流行得益于近几年微服务架构的兴起，原本一个庞大的业务系统被拆分成许多粒度更小的系统进行独立部署和维护，这种模式势必会带来更多的跨系统交互，企业API的规模也会成倍增加，API网关(或者微服务网关)就逐渐成为了微服务架构的标配组件。同时随着越来越多的系统被以微服务的形式开发或重构，API网关所承受的压力也越来越大。本发明旨在基于已有的Nginx软件，提出一种新型、高效的API网关设计和具体实现方法，把Nginx这层改造成基于OpenResty的API网关。通过这种API网关，可以大大提高微服务架构下的服务认证、鉴权、协议转换等的速度，提高服务访问效率。

两种典型的传统API网关设计架构：

1、单节点网关

单节点的API网关为每个客户端提供不同的API，而不是提供一种通用的API。图1是现有技术中一个单节点网关的典型实现。经典的服务端App和浏览器前后端分离App都通过一个单独的API网关入口，访问后台不同的微服务提供者。

这种单节点网关的不足在于，一方面，不支持动态扩展，系统每多一个服务，就需要部署或者修改负载均衡器，同时因为无法做到动态的开关服务，若要下线某个服务，需要运维人员将服务地址从负载均衡器中移除。另一方面，因为是单节点负责整个后台微服务的路由，往往这个API网关就成了整个系统的性能瓶颈所在，在系统访问量骤增的时候，无法快速的将相关的服务访问派发给后台正确的微服务程序。

2、Backends for frontends网关

这种模式是针对不同的客户端来实现一个不同的API网关。如图2所示，分别针对Web应用程序、移动端应用程序、公共程序分别开发不同的三个API网关程序，这三个不同类型的API网关，将来源不同的服务请求分别路由给后台微服务提供者。

这种Backends for frontends网关的不足之处在于，一方面，配置复杂，运维成本高。系统每多一个服务，分别要部署或者修改多个负载均衡器，同时因为无法做到动态的开关服务，若要下线某个服务，需要运维人员将服务地址从负载均衡器中移除。另一方面，每个不同的网关分别负责来不不同网络的服务请求，因此无法在多个网关之间进行负载均衡，往往会出现不同的网关上负载不均的情况。

传统的API网关实现，无论是单节点网关，还是Backends for frontends网关，都存在不足。通常情况下，API网关要做很多工作，它作为一个系统的后端总入口，承载着所有服务的组合路由转换等工作，随着后端业务的不断扩展，传统网关的灵活性差的问题逐渐暴露出来。除此之外，API网关才承担着安全，限流，缓存，日志，监控，重试，熔断等功能职责，在高并发的情况下，传统的API网关实现就会出现性能瓶颈。

发明内容

本发明实施例提供一种API网关系统，用以解决现有技术中的上述问题。

本发明实施例提供一种API网关系统，包括：

DNS负载均衡器，用于接收不同来源的HTTP服务访问请求，对所述HTTP服务访问请求进行处理，将处理后的HTTP服务访问请求负载均衡到基于OpenResty的API Gataway网关集群；将所述微服务返回的数据发送到用户；

基于OpenResty的API网关集群，包括多个OpenResty API网关，用于对所述HTTP服务访问请求进行身份认证和权限认证，并将所述HTTP服务访问请求负载到不同的Web/Mobile API网关，或者，将所述HTTP服务访问请求直接发送到相应的微服务；将所述微服务返回的数据发送到DNS负载均衡器；

Web/Mobile API网关，用于将所述HTTP服务访问请求路由到适当的微服务，并将所述微服务返回的数据反馈给所述基于OpenResty的API网关集群。

优选地，所述DNS负载均衡器进一步用于：

在用户在登陆页完成登录操作后，生成一个登录SESSION信息，并设置所述登录SESSION信息的实效时间，并保存在用户的cookie中。

优选地，所述DNS负载均衡器具体用于：

接收不同来源的HTTP服务访问请求，对所述HTTP服务访问请求中的cookie信息进行验证，如果验证通过，则对所述HTTP服务访问请求进行处理，将处理后的HTTP服务访问请求负载均衡到基于OpenResty的API Gataway网关集群。

优选地，所述DNS负载均衡器进一步用于：

当需要撤掉一台OpenResty API网关时，先关闭监听套接字，但是继续为当前连接的客户提供服务，在所有客户端的服务完成后，再将进程关闭；

当有一台新的OpenResty API网关注册时，在预定时间段内，以预设步长逐渐将转发给其的HTTP服务访问请求增加到预设值。

优选地，所述OpenResty API网关具体包括：

策略模块，用于根据具体需求，设置超时策略、缓存策略、熔断策略、以及重试策略，并根据所述超时策略、缓存策略、熔断策略、以及重试策略对所述HTTP服务访问请求进行处理；

监控模块，用于对所述微服务进行监控；

日志模块，用于对所述OpenResty API网关进行日志记录；

流控模块，用于对微服务、用户、和/或APP进行流量控制；

注册模块，用于发现新的微服务，并对新的微服务进行注册；

接口控制模块，用于对连接微服务的接口版本进行控制，将HTTP服务访问请求路由到不同版本的微服务上；

重写模块，用于对HTTP服务访问请求的路由进行重写，并根据重写后的路由对HTTP服务访问请求进行路由。

优选地，所述流控模块具体用于：

步骤1，设置流量控制阈值，生成流量控制策略，其中，所述流量控制阈值为单位时间内的调用次数，设置所述设置流量控制阈值的操作具体包括以下至少之一：

为每个微服务建立分组信息，并设置微服务分组的流量控制阈值

为微服务分别设置相应的流量控制阈值；

为使用微服务的普通用用户设置相应的流量控制阈值；

为使用微服务的APP分别设置相应的流量控制阈值；

为使用微服务的某一个或多个特殊用户设置相应的流量控制阈值；

步骤2，将流量控制策略绑定到相应的微服务上；

步骤3，根据所述流量控制策略对微服务、用户、和/或APP进行流量控制。

优选地，所述监控模块具体用于：

根据报警参数设置相应的报警规则；

将所述报警规则关联相应的微服务；

根据所述报警规则对相应的微服务进行监控。

优选地，所述报警参数用于包括：

Http请求状态码、API响应时间、API总体请求次数、流入流量、和/或流出流量。

采用本发明实施例，能够大大提高微服务架构下的服务认证、鉴权、协议转换等的速度，提高服务访问效率。

上述说明仅是本发明技术方案的概述，为了能够更清楚了解本发明的技术手段，而可依照说明书的内容予以实施，并且为了让本发明的上述和其它目的、特征和优点能够更明显易懂，以下特举本发明的具体实施方式。

附图说明

通过阅读下文优选实施方式的详细描述，各种其他的优点和益处对于本领域普通技术人员将变得清楚明了。附图仅用于示出优选实施方式的目的，而并不认为是对本发明的限制。而且在整个附图中，用相同的参考符号表示相同的部件。在附图中：

图1是现有技术中一个单节点网关的典型实现的示意图；

图2是现有技术中Backends for frontends API网关的示意图；

图3是本发明实施例中API网关系统的示意图。

具体实施方式

本发明实施例基于已有的Nginx软件，提出一种新型、高效的API网关设计和具体实现方法，把Nginx这层改造成基于OpenResty的API网关。通过这种API网关，可以大大提高微服务架构下的服务认证、鉴权、协议转换等的速度，提高服务访问效率。

下面将参照附图更详细地描述本公开的示例性实施例。虽然附图中显示了本公开的示例性实施例，然而应当理解，可以以各种形式实现本公开而不应被这里阐述的实施例所限制。相反，提供这些实施例是为了能够更透彻地理解本公开，并且能够将本公开的范围完整的传达给本领域的技术人员。

根据本发明的实施例，提供了一种API网管系统，如图3所示，具体包括：

DNS负载均衡器，用于接收不同来源的HTTP服务访问请求，对所述HTTP服务访问请求进行处理，将处理后的HTTP服务访问请求负载均衡到基于OpenResty的API Gataway网关集群；将所述微服务返回的数据发送到用户；

所述DNS负载均衡器进一步用于：

在用户在登陆页完成登录操作后，生成一个登录SESSION信息，并设置所述登录SESSION信息的实效时间，并保存在用户的cookie中。

所述DNS负载均衡器具体用于：

接收不同来源的HTTP服务访问请求，对所述HTTP服务访问请求中的cookie信息进行验证，如果验证通过，则对所述HTTP服务访问请求进行处理，将处理后的HTTP服务访问请求负载均衡到基于OpenResty的API Gataway网关集群。

所述DNS负载均衡器进一步用于：

当需要撤掉一台OpenResty API网关时，先关闭监听套接字，但是继续为当前连接的客户提供服务，在所有客户端的服务完成后，再将进程关闭；

当有一台新的OpenResty API网关注册时，在预定时间段内，以预设步长逐渐将转发给其的HTTP服务访问请求增加到预设值。

基于OpenResty的API网关集群，包括多个OpenResty API网关，用于对所述HTTP服务访问请求进行身份认证和权限认证，并将所述HTTP服务访问请求负载到不同的Web/Mobile API网关，或者，将所述HTTP服务访问请求直接发送到相应的微服务；将所述微服务返回的数据发送到DNS负载均衡器；

所述OpenResty API网关具体包括：

策略模块，用于根据具体需求，设置超时策略、缓存策略、熔断策略、以及重试策略，并根据所述超时策略、缓存策略、熔断策略、以及重试策略对所述HTTP服务访问请求进行处理；

监控模块，用于对所述微服务进行监控；

日志模块，用于对所述OpenResty API网关进行日志记录；

流控模块，用于对微服务、用户、和/或APP进行流量控制；

注册模块，用于发现新的微服务，并对新的微服务进行注册；

接口控制模块，用于对连接微服务的接口版本进行控制，将HTTP服务访问请求路由到不同版本的微服务上；

重写模块，用于对HTTP服务访问请求的路由进行重写，并根据重写后的路由对HTTP服务访问请求进行路由。

所述流控模块具体用于：

步骤1，设置流量控制阈值，生成流量控制策略，其中，所述流量控制阈值为单位时间内的调用次数，设置所述设置流量控制阈值的操作具体包括以下至少之一：

为每个微服务建立分组信息，并设置微服务分组的流量控制阈值

为微服务分别设置相应的流量控制阈值；

为使用微服务的普通用用户设置相应的流量控制阈值；

为使用微服务的APP分别设置相应的流量控制阈值；

为使用微服务的某一个或多个特殊用户设置相应的流量控制阈值；

步骤2，将流量控制策略绑定到相应的微服务上；

步骤3，根据所述流量控制策略对微服务、用户、和/或APP进行流量控制。

所述监控模块具体用于：

根据报警参数设置相应的报警规则；

将所述报警规则关联相应的微服务；

根据所述报警规则对相应的微服务进行监控。

所述报警参数用于包括：

Http请求状态码、API响应时间、API总体请求次数、流入流量、和/或流出流量。

Web/Mobile API网关，用于将所述HTTP服务访问请求路由到适当的微服务，并将所述微服务返回的数据反馈给所述基于OpenResty的API网关集群。

以下对本发明上述技术方案进行详细说明。

本发明实施例的API网关物理部署架构实现如图3所示本发明实施例的API网关，包括请求处理、无状态特性、流量控制、监控告警等功能。

1)请求处理设计

本发明实施例的API网关，包括DNS负载均衡器、OpenResty API网关、Web/MobileApi网关、以及微服务集群。本发明实施例实现的API网关对请求的处理，可以分为三个阶段：接受请求、路由并转发请求、接受服务的返回数据并返回给请求者。具体步骤如下：

(1)接受请求

针对Web APP访问、移动端APP访问、公共APP访问等不同来源的HTTP服务访问请求，由DNS负载均衡器进行请求处理和路由分派。

(2)路由并转发请求

DNS负载均衡器，将HTTP请求流量负载均衡到基于OpenResty的API Gataway网关集群，在这个流程我们可以使用像传统开源的支持高并发高访问量API网关程序在做第一层流量的防护，通过API网关的身份认证、权限认证，才能到达后端的服务。在这里，本方案实现的API网关支持算法签名，支持SSL加密功能。同时在路由转发过程中实现了监控、日志、流控等策略，以及服务的发现和注册，接口的版本控制，路由重写等。

然后再由这些OpenResty API网关把请求再负载到不同的Web/Mobile Api网关，在这里我们做聚合服务这个操作，具体体现是需要微服务开发人员来需要写代码实现的。这期间对于有需求的接口，我们可以应用超时，缓存，熔断，重试等策略。

(3)接受服务的返回数据并返回给请求者

当这些不同的Web APP、移动端APP、公共APP的访问请求，被最终路由到恰当的微服务，并由这些微服务处理完毕后，由OpenResty API网关接收微服务返回的数据，并通过Web浏览器、手机客户端等不同的形式返回给最终用户。

2)API网关无状态设计

为保证API网关层高可用，易于伸缩，快速启动，本发明实施例将API网关设计成无状态的。相比传统实现通常将用户的状态数据使用session对象来封装，而本方案的设计是采用我们是采用cookie+session服务器的方式实现。具体步骤如下：

(1)用户在登录页完成登录操作后，服务器会生成一个登录session信息，保存起来，设置个失效时间，并设置到用户的cookie里。

(2)用户后续的每次请求里会带着这个cookie信息，服务端会对这个cookie信息进行校验，通过了就认为是合法用户，执行请求操作。

(3)当需要撤掉一台网关服务的时候，不是直接结束网关进程，而是先关闭监听套接字，但是继续为当前连接的客户提供服务，所有客户端的服务完成后，在把进程关闭。

(4)当网关监听到有一台新的服务注册上来时，考虑到有些服务启动后，刚开始会有许多初始化的工作，此时服务对请求的响应速度是比较慢的。如果一开始就给这台服务分配太多的压力，有可能导致服务瞬间被压垮。为了避免这种情况，网关层需要考虑支持Slow Start特性。即，经过一段时间，逐渐把压力增加到预设的值。

3)流量控制设计

流控作为API网关的主要功能，一直是API网关设计的重点。本方案设计的API网关，支持用户、应用和例外流控，可以根据用户的重要性来配置不同流控，从而可以保证大用户的权益；本方案设计的流控粒度包括：分钟、小时、天。

本方案设计的API网关能从API分组、API、用户、APP四个维度进行流量控制，当流量超过设置阈值时，API网关会直接返回错误信息(错误码403，有明确的因流控被拒的错误信息)给请求者，不会再继续调用API提供者的后端服务，从而保护了后端服务不被攻击。同时我们还具有精准流控，实时生效的特点。具体实现如下：

(1)API分组流控

首先，需要为每个API建立分组信息。每个API分组在建立的时候，默认设置了分组的QPS为500，指该分组下所有API的QPS之和为500，该配置信息可根据实际应用需求进行设置。

(2)API流控设置

API流控用于通道内的业务分层，API提供者可以根据后端服务能力和业务的重要程度来区分API，可分别设置不同的流量控制，以保证重要业务的延续性。API流控须小于分组流控。用户流控用于在API上的用户分层，API提供者可以为普通用户设置流量控制，防止用户间相互挤占资源。APP流控须小于用户流控。具体操作方法如下：

(a)建立流控策略

API流量控制指单位时间内的调用次数控制，可设置的单位时间包括：分钟、小时、天三个粒度。其中分钟级别的流控适合配置在调用频繁，请求量大的API上，防攻击，因为不能长时间中断调用，所以单位时间不能设置太长；小时、天级别的流控适合配置在敏感型API上，比如发短信API，获取验证码API等，限制调用频率。

(b)设置特殊流控策略

特殊流控，主要用于对用户或APP分层，API提供者可以设置API上某个用户(或某个APP)的单独流控，可以大于或小于用户流控。

(c)绑定API

将上述设置的流控策略绑定到API上，即可生效。同时针对不同环境的API(如测试、线上)，可分别绑定不同的API策略。

4)监控告警设计

在API网关开放API服务后，及时处理API服务异常，是API开放者关注的重点。本发明实施例设计的API网关具有的API监控报警功能，通过简单的配置，即可实现API的监控报警。具体步骤如下：

(a)设置报警规则

本发明实施例设计的API网关提供了Http请求状态码、API响应时间、API总体请求次数、流入流量、流出流量等五个维度的规则，可以从这五个方面，配置关心的报警规则。

比如HttpStatusCode，有Code2XX，Code4XX，Code5XX可选。其中，Code2XX：表示API请求成功；Code4XX：表示客户端错误，可能是参数错误等；Code5XX：表示服务端错误，这个对于API开放者来说，一般需要重点监控。

(b)关联资源多维度设置

关联资源指该报警规则应用的资源。在关联报警资源时，可进行多维度配置，有API维度和应用分组维度，和全部资源可选。满足多样化的配置需求。其中，API维度下，用户可以手动关联某个Region下的一个API或者多个API；应用分组维度下，可以选择不同Region的资源，作为监控的关联资源。

综上所述，在本发明实施例中：

1)请求处理功能

本发明实施例设计的API网关采用多级路由策略，将原始的Web APP、移动端APP、公共APP的访问请求，经过负载均衡和两级处理后，最终路由到对应的业务应用微服务。同时在这一过程中支持对访问请求进行身份认证、安全、监控、日志、流控等管理。

2)无状态设计

本方案将API网关设计成无状态的，从而能够保证API网关层高可用，易于伸缩，快速启动。

3)流量控制功能

本方案设计的API网关，支持用户、应用和例外流控，可以根据用户的重要性来配置不同流控，从而可以保证大用户的权益。

4)监控告警功能

本方案设计的API网关提供实时、可视化的API监控，包括：调用量、调用方式、响应时间、错误率，让您能够清楚的了解API的运行状况和用户的行为习惯。

本发明实施例的有益效果如下：

(一)高性能

传统的API网关使用基于线程的并发模型(Thread-based concurrency)，为每一个请求分配一个线程或进程。这种模型编程简单，可以将处理一个完整请求的代码编写在一个代码路径中。这种模型的弊端是，随着线程(进程)数的上升，操作系统在这些线程(进程)之间的频繁切换，将急剧降低系统的性能。

(二)高可用

对服务管理来说，分为前端服务管理与后端服务管理。前端服务指的是网关层暴露给客户端使用的服务API，后端服务指的是服务层提供的业务服务API。一个服务暴露给客户端使用，除了网关层和服务层提供服务的代码外，还需要配置前端服务与后端服务的映射关系。本方案设计的API网关可以通过配置前后端服务映射的方式，解耦网关层对服务层的依赖。当服务层的API(例如服务名、参数名等)发生变化时，只需调整映射关系，无需对网关层的代码进行调整。网关层按照映射，自动装配服务层API所需要的数据格式。这样，网关层团队与服务层团队可以相互不受干扰地开发各自的服务。

显然，本领域的技术人员应该明白，上述的本发明的各模块或各步骤可以用通用的计算装置来实现，它们可以集中在单个的计算装置上，或者分布在多个计算装置所组成的网络上，可选地，它们可以用计算装置可执行的程序代码来实现，从而，可以将它们存储在存储装置中由计算装置来执行，并且在某些情况下，可以以不同于此处的顺序执行所示出或描述的步骤，或者将它们分别制作成各个集成电路模块，或者将它们中的多个模块或步骤制作成单个集成电路模块来实现。这样，本发明不限制于任何特定的硬件和软件结合。

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

Claims (8)

1.一种API网关系统，其特征在于，包括：

DNS负载均衡器，用于接收不同来源的HTTP服务访问请求，对所述HTTP服务访问请求进行处理，将处理后的HTTP服务访问请求负载均衡到基于OpenResty的API Gataway网关集群；将所述微服务返回的数据发送到用户；

基于OpenResty的API网关集群，包括多个OpenResty API网关，用于对所述HTTP服务访问请求进行身份认证和权限认证，并将所述HTTP服务访问请求负载到不同的Web/MobileAPI网关，或者，将所述HTTP服务访问请求直接发送到相应的微服务；将所述微服务返回的数据发送到DNS负载均衡器；

Web/Mobile API网关，用于将所述HTTP服务访问请求路由到适当的微服务，并将所述微服务返回的数据反馈给所述基于OpenResty的API网关集群。

2.如权利要求1所述的系统，其特征在于，所述DNS负载均衡器进一步用于：

在用户在登陆页完成登录操作后，生成一个登录SESSION信息，并设置所述登录SESSION信息的实效时间，并保存在用户的cookie中。

3.如权利要求2所述的系统，其特征在于，所述DNS负载均衡器具体用于：

接收不同来源的HTTP服务访问请求，对所述HTTP服务访问请求中的cookie信息进行验证，如果验证通过，则对所述HTTP服务访问请求进行处理，将处理后的HTTP服务访问请求负载均衡到基于OpenResty的API Gataway网关集群。

4.如权利要求2所述的系统，其特征在于，所述DNS负载均衡器进一步用于：

当需要撤掉一台OpenResty API网关时，先关闭监听套接字，但是继续为当前连接的客户提供服务，在所有客户端的服务完成后，再将进程关闭；

当有一台新的OpenResty API网关注册时，在预定时间段内，以预设步长逐渐将转发给其的HTTP服务访问请求增加到预设值。

5.如权利要求1所述的系统，其特征在于，所述OpenResty API网关具体包括：

策略模块，用于根据具体需求，设置超时策略、缓存策略、熔断策略、以及重试策略，并根据所述超时策略、缓存策略、熔断策略、以及重试策略对所述HTTP服务访问请求进行处理；

监控模块，用于对所述微服务进行监控；

日志模块，用于对所述OpenResty API网关进行日志记录；

流控模块，用于对微服务、用户、和/或APP进行流量控制；

注册模块，用于发现新的微服务，并对新的微服务进行注册；

接口控制模块，用于对连接微服务的接口版本进行控制，将HTTP服务访问请求路由到不同版本的微服务上；

重写模块，用于对HTTP服务访问请求的路由进行重写，并根据重写后的路由对HTTP服务访问请求进行路由。

6.如权利要求5所述的系统，其特征在于，所述流控模块具体用于：

步骤1，设置流量控制阈值，生成流量控制策略，其中，所述流量控制阈值为单位时间内的调用次数，设置所述设置流量控制阈值的操作具体包括以下至少之一：

为每个微服务建立分组信息，并设置微服务分组的流量控制阈值

为微服务分别设置相应的流量控制阈值；

为使用微服务的普通用用户设置相应的流量控制阈值；

为使用微服务的APP分别设置相应的流量控制阈值；

为使用微服务的某一个或多个特殊用户设置相应的流量控制阈值；

步骤2，将流量控制策略绑定到相应的微服务上；

步骤3，根据所述流量控制策略对微服务、用户、和/或APP进行流量控制。

7.如权利要求5所述的系统，其特征在于，所述监控模块具体用于：

根据报警参数设置相应的报警规则；

将所述报警规则关联相应的微服务；

根据所述报警规则对相应的微服务进行监控。

8.如权利要求7所述的系统，其特征在于，所述报警参数用于包括：

Http请求状态码、API响应时间、API总体请求次数、流入流量、和/或流出流量。