CN116232804A - 基于微服务架构的api网关 - Google Patents

Abstract

本发明属于API网关领域，尤其是基于微服务架构的API网关，包括路由转发模块、聚合服务模块、负载均衡模块、安全认证模块、日志记录模块、数据转换模块、流量控制模块、熔断模块、服务升降级模块、缓存模块和服务重试模块，所述路由转发模块与服务聚合模块连接，所述服务聚合模块与负载均衡模块连接，所述负载均衡模块与安全认证模块连接，所述安全认证模块与日志记录模块连接，所述日志记录模块与数据转换模块连接，所述数据转换模块与流量控制模块连接，所述流量控制模块与熔断模块连接，所述熔断模块与服务升降级模块连接，本发明开发维护简单，节约人力成本和维护成本，高性能，节约设备成本，提高系统吞吐能力。

Description

基于微服务架构的API网关

技术领域

本发明涉及API网关技术领域，尤其涉及基于微服务架构的API网关。

背景技术

API网关是一个服务器，是系统的唯一入口。从面向对象设计的角度看，它与外观模式类似，API网关封装了系统内部架构，为每个客户端提供一个定制的API，它可能还具有其它职责，如身份验证、监控、负载均衡、缓存、请求分片与管理、静态响应处理、流量控制、日志、重试、熔断等，在考虑客户端与每个已部署的微服务直接通信时，应考虑以下挑战：如果微服务向客户端公开了细粒度的API，则客户端应向每个微服务请求，在典型的单页中，可能需要进行多次服务器往返，才能满足请求，对于低网络运行的设备(例如移动设备)，这可能更糟；微服务中存在的多种通信协议(例如gRpc，thrift，REST，AMQP等)使客户端采用所有这些协议带来挑战性和使其笨重；必须在每个微服务中实现通用网关功能(例如身份验证，授权，日志记录)；在不中断客户端连接的情况下，很难在微服务中进行更改，例如，在合并或划分微服务时，可能需要重新编码客户端的部分，为了解决上述问题，我们提出了基于微服务架构的API网关；

发明内容

本发明的目的是为了解决现有技术中存在的缺点，而提出的基于微服务架构的API网关。

为了实现上述目的，本发明采用了如下技术方案：

基于微服务架构的API网关，包括路由转发模块、聚合服务模块、负载均衡模块、安全认证模块、日志记录模块、数据转换模块、流量控制模块、熔断模块、服务升降级模块、缓存模块和服务重试模块，所述路由转发模块与服务聚合模块连接，所述服务聚合模块与负载均衡模块连接，所述负载均衡模块与安全认证模块连接，所述安全认证模块与日志记录模块连接，所述日志记录模块与数据转换模块连接，所述数据转换模块与流量控制模块连接，所述流量控制模块与熔断模块连接，所述熔断模块与服务升降级模块连接，所述服务升降级模块与缓存模块连接，所述缓存模块与服务重试模块连接。

优选的，所述路由转发模块根据请求的host，url规则转发到指定的服务。

优选的，所述聚合服务模块使得客户端只需要发送一个请求到网关，网关针对该请求，向多个目标微服务发送请求，将请求结果整合后返回给客户端。

优选的，所述负载均衡模块用于减少或停止向实例转发请求。

优选的，所述安全认证模块进行身份验证，身份验证通过后才转发给后面的服务，转发的时候也会带上身份信息。

优选的，所述日志记录模块既可以作为我们后续事件查询使用，也可以作为系统的性能监控使用。

优选的，所述数据转换模块将不同客户端传输进来的数据转换成同一种类型再转发给内部微服务上。

优选的，所述流量控制模块通过对并发访问请求数量进行控制或者一个时间窗口内的的请求数量进行控制来保护系统，一旦达到控制速率则可以拒绝服务、排队或等待。

本发明中，所述基于微服务架构的API网关的有益效果：

本发明开发维护简单，节约人力成本和维护成本，高性能，节约设备成本，提高系统吞吐能力。

附图说明

图1为本发明提出的基于微服务架构的API网关的框图；

图2为本发明提出的基于微服务架构的API网关的应用图。

具体实施方式

下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本发明一部分实施例，而不是全部的实施例。

实施例一

参照图1-2，基于微服务架构的API网关，包括路由转发模块、聚合服务模块、负载均衡模块、安全认证模块、日志记录模块、数据转换模块、流量控制模块、熔断模块、服务升降级模块、缓存模块和服务重试模块，路由转发模块与服务聚合模块连接，服务聚合模块与负载均衡模块连接，负载均衡模块与安全认证模块连接，安全认证模块与日志记录模块连接，日志记录模块与数据转换模块连接，数据转换模块与流量控制模块连接，流量控制模块与熔断模块连接，熔断模块与服务升降级模块连接，服务升降级模块与缓存模块连接，缓存模块与服务重试模块连接。

路由转发模块

API网关是内部微服务的对外唯一入口，所以外面全部的请求都会先发到这个API网关上，然后由API网关来根据不同的请求去路由到不同的微服务节点上。例如可以根据路径来转发、也可以根据参数来转发。并且由于内部微服务实例也会随着业务调整不停的变更，增加或者删除节点，API网关可以与服务注册模块进行协同工作，保证将外部请求转发到最合适的微服务实例上面去。

聚合服务模块

前面的路由处理的是一个请求直接由对应服务来处理的场景。微服务中每个服务提供的是系统的一部分功能，所以可能一个完整的功能需要由多个微服务来提供服务，这可能就需要客户端为了完成某个功能发送多次请求。这会导致几个问题：多次的网络请求会影响系统性能、客户端需要调用多个服务，对于前端开发人员来说，开发体验不够友好。所以，网关需要提供「聚合服务」的功能，即客户端只需要发送一个请求到网关，网关针对该请求，向多个目标微服务发送请求，将请求结果整合后返回给客户端。

负载均衡模块

既然API网关是内部微服务的单一入口，所以API网关在收到外部请求之后，还可以根据内部微服务每个实例的负荷情况进行动态的负载均衡调节。一旦内部的某个微服务实例负载很高，甚至是不能及时响应，则API网关就通过负载均衡策略减少或停止向这个实例转发请求。当所有的内部微服务实例都处理不过来的时候，API网关还可以采用限流或熔断的形式阻止外部请求，以保障整个系统的可用性。

安全认证模块

API网关就像是微服务的大门守卫，每一个请求进来之后，都必须先在API网关上进行身份验证，身份验证通过后才转发给后面的服务，转发的时候一般也会带上身份信息。同时API网关也需要对每一个请求进行安全性检查，例如参数的安全性、传输的安全性等等。

日志记录模块

既然所有的请求都需要走API网关，那么我们就可以在API网关上统一集中的记录下这些行为日志。这些日志既可以作为我们后续事件查询使用，也可以作为系统的性能监控使用。

数据转换模块

因为API网关对外是面向多种不同的客户端，不同的客户端所传输的数据类型可能是不一样的。因此API网关还需要具备数据转换的功能，将不同客户端传输进来的数据转换成同一种类型再转发给内部微服务上，这样，兼容了这些请求的多样性，保证了微服务的灵活性。

流量控制模块

流量控制的目的是通过对「并发访问请求数量进行控制」或者「一个时间窗口内的的请求数量进行控制」来保护系统，一旦达到控制速率则可以拒绝服务、排队或等待。流量控制可以针对整个系统，也可以针对单个接口来进行控制。网关需要控制单位时间内接口允许被调用次数，以保护后端服务，实现用户分级。可以根据接口的重要程度来配置不同流控，从而保障重要业务的稳定运行；支持用户、应用和例外流控，可以根据用户的重要性来配置不同流控，从而可以保证大用户的权益；流控粒度：分钟、小时、天。

熔断模块

当一个服务对外无响应或者响应时间很长时，此种情况下可能会导致请求的大量积压，继而影响整个系统对外提供服务。熔断可以避免此类问题的发生。当一个服务对外无响应或者响应时间过长时，对该服务进行熔断操作。即对该服务的请求立即返回特定的结果，避免请求积压。等一段时间后，恢复服务对外提供服务。如果服务还是无法对外服务，则再次触发熔断。

服务升降级模块

上面的流量控制和熔断都是相对比较「公平」的方法，主要是为了保证系统的可用性。在系统过载的情况下，无差别的对待所有的服务/接口。不过对于一个系统来说，有些服务是核心服务而有些服务是非核心服务，对于核心服务来说，即使在系统过载的情况下也不能拒绝对外服务，否则这个系统实际就失去了它原有的价值。这个时候就需要非核心业务为核心业务让路，即在系统过载的时候，非核心服务让出系统资源，即服务降级，保障核心服务能稳定的对外提供服务。待系统负载正常后，再恢复非核心服务。

缓存模块

对于经常调用的接口，且结果基本不会出现变化的接口，可以对这些接口进行缓存。缓存后的接口，由于请求不会到达目标服务端，可以给系统带来如下好处：

A.减少了请求链路；

B.降低了系统的响应时间；

C.降低了微服务的负载

同时也带来了如下劣势：

A.需要同步缓存与接口结果，增加了开发难度；

B.需要管理缓存，增加运维成本；

在后端并发和处理能力不够的情况下，将缓存前置来提供更好的服务，而且是从网关层统一处理，可简化后端服务处理的复杂度。

服务重试模块

对于某些服务，可能会由于某些原因导致服务短时间内没有响应，例如网路波动，当出现这些情况的时候，默认情况下客户端会直接收到错误消息，对于某些服务，可以通过重试的方式来降低/避免此类问题，即如果某次请求，对应的服务在规定时间内，没有得到响应，则自动再尝试一次/n次，如果成功则返回结果，如果多次尝试后，依然失败，则再返回错误消息，服务重试在某些情况下能提高系统的可用性。

实施例二

本实施例与实施例一的区别在于：(1)、路由转发模块

一般情况下，服务对外提供的是RESTful接口，所以一般路由模块根据请求的host，url等规则转发到指定的服务。考虑到路由规则需要频繁的修改发布，为了发布的便利性，考虑针对规则实现热发布。有几种实现方式：

A.基于数据库

即将路由规则配置到数据库中，当网关收到请求后，从数据库中查询规则进行规则匹配。根据匹配到的规则进行路由。考虑到性能，可以缓存规则，例如缓存到redis中。当修改配置后，需要将修改的数据刷到缓存中。此方式需要实现数据库与缓存的同步逻辑，提供操作界面，需要一定的开发量。

B.基于配置文件

即将路由规则配置到配置文件中，网关启动时直接加载即可。普通的配置文件方式无法动态处理配置，每次修改后都需要启动网关，比较麻烦。对于微服务架构来说，一般会有配置服务器，可以基于配置服务器来实现配置的实时生效。

相对于前一种方法，可以基于微服务基础设施来实现，降低了一定的开发量。

(2)、负载均衡模块

一般负载均衡算法有：

A.随机算法：从多个服务中，随机选择一个服务来处理请求。此算法的问题是，实际无法做到负载均衡，极端情况下可能会导致所有请求都由同一个服务进行处理。且对于有状态的服务，对状态的管理会比较麻烦。

B.加权随机：同随机算法，不同之处是每个服务的权重不同。比如有的服务器性能较好，则可以提高权重，能够处理较多的请求；有的服务器性能较差，则可以降低权重，处理较少的请求。

C.轮询算法：对服务进行排序，将请求按顺序发送给对应的服务来处理。假设有两个服务A，B，第一个请求由A处理，第二个请求则由B处理，第三个请求还由A处理，以次类推。对于有状态的服务，轮询算法对状态处理也比较麻烦。

D.加权轮询：同加权轮询，不同之处是每个服务的权重不同。比如还以上面的例子，A，B权重2:1，则第一个请求A处理，第二个请求还是A处理，第三个请求B处理，第四个请求A处理，以次类推。

E.最小连接算法：根据服务的连接数来判断请求由哪个服务来处理，选择当前连接数最少的服务来处理请求。此算法需要维护每个服务的连接数，比较复杂，不推荐使用。

F.源地址hash：根据请求地址取hash，然后对服务数量取模，由对应的服务来处理对应的请求。此算法可以保证相同用户的请求由同一个服务来处理，可以保障服务端状态。

对于微服务场景来说，优先选择源地址hash：

1、首先，不需要处理随机、轮询这种算法需要处理的服务端Session共享的问题；

2、其次，实现简单；

3、最后，考虑服务的变动不会太频繁，前期用户量也不会很大，使用源地址hash的性价比最高。

(3)、聚合服务模块

聚合服务有两种方案：

GraphQL：一种用于API的查询语言。使用GraphQL有三种可选方案

A.在网关前增加一个聚合服务Server，基于GraphQL来实现服务聚合(也可以使用编码的形式来处理，此服务主要是IO密集型操作，故可以使用擅长IO密集型操作的技术，比如nodeJs，golang)

B.直接在网关中使用GraphQL来进行服务聚合，此方式需要重启网关

C.网关后增加聚合服务层，用于组装聚合请求

编码：在网关层进行服务请求的处理，针对需要聚合的服务构建微服务请求，将获得的结果构建为最终结果返回。此方案需要编码，发布。对于需要频繁发布的聚合服务，也可以考虑独立「聚合服务」，避免频繁的发布网关，影响系统稳定性。

考虑到GraphQL的学习成本，以及聚合服务的量不是很多，优先考虑在网关中直接进行编码的方式。

(4)、安全认证模块

目前大部分系统采用的都是基于RBAC的认证授权。RBAC模型是目前主流权限控制的理论基础。RBAC(Role-Based Access Control)即：基于角色的权限控制。通过角色关联用户，用户关联权限的方式间接赋予用户权限。RBAC模型可分为：RBAC0、RBAC1、RBAC2、RBAC3四种。其中RBAC0是基础，也是最简单的，相当于底层逻辑，RBAC1、RBAC2、RBAC3都是以RBAC0为基础的升级。具体内容请自行Google。考虑互联网项目对用户角色的区分没有特别的严格(相对后台管理系统)，RBAC0模型就可以满足常规的权限管理系统的需求，所以选择基于RBAC0来实现认证与鉴权。

对于Java来说，主流的认证与鉴权框架是SpringSecurity和Shiro，考虑集成的便利性，选择SpringSecurity作为认证鉴权框架。

实施例三

与实施例一的区别在于：(4)、流量控制模块

一般的流量控制模式有：

控制并发，即限制并发的总数量(比如数据库连接池、线程池)

控制速率，即限制并发访问的速率(如nginx的limitconn模块，用来限制瞬时并发连接数)

控制单位时间窗口内的请求数量(如Guava的RateLimiter、nginx的limitreq模块，限制每秒的平均速率)

控制远程接口调用速率

控制MQ的消费速率

根据网络连接数、网络流量、CPU或内存负载等来限流。

对于微服务场景来说，控制速率是比较合适的流量控制方案。通常情况下，使用令牌桶算法来实现访问速率的控制，常用的令牌桶算法有两种：

漏桶算法：水(请求)先进入到漏桶里，漏桶以一定的速度出水，当水流入速度过大会直接溢出。可以看出漏桶算法能强行限制数据的传输速率，但是某些情况下，系统可能需要允许某种程度的突发访问量，此时可以使用令牌桶算法。

令牌桶算法：系统会以一个恒定的速度向桶里放入令牌。如果请求需要被处理，则需要先从桶里获取一个令牌，当桶里没有令牌可取时，则拒绝服务。令牌桶算法通过发放令牌，根据令牌的rate频率做请求频率限制，容量限制等。

流量控制算法在确定后也是基本不需要变化的，所以对于热部署的需求不是必要的。另外流量控制可以前置，放到接入层来处理，一般的网络接入服务，如nginx是支持流量控制的。如果前期对流量控制没有太多的定制化需求，可以考虑基于nginx来进行处理。

(5)、熔断模块

服务熔断的实现思路：

A.调用失败次数累积达到了阈值(或一定比例)则启动熔断机制

B.此时对调用直接返回错误。待达到设置的时间后(这个时间一般设置成平均故障处理时间，也就是MTTR)，进入半熔断状态

C.此时允许定量的服务请求，如果调用都成功(或一定比例)则认为恢复了，关闭熔断；否则认为还没好，继续熔断

考虑到有较成熟的开源项目，推荐直接使用开源项目来处理。

(6)、服务升降级模块

一种服务升降级的方案可以基于阻塞队列来实现：

A.网关接收到请求后，进入定长的阻塞队列

B.消费线程从消费队列中获取请求来进行处理

C.当生产速率大于消费速率，会导致队列中请求不断增加，当请求数量超过设定的阈值时，根据配置的服务升降级规则判定当前请求是否属于可降级的服务(或者基于队列来判定)，如果属于可降级的服务，则根据配置的降级逻辑对该请求进行处理(比如直接拒绝)；如果请求属于不可降级的服务，则依然添加到请求队列中

考虑到有较成熟的开源项目，推荐直接使用开源项目来处理。

(7)、缓存模块

考虑到网关是集群化部署，所以优先使用集中式缓存方式，即网关中所有需要缓存的数据都集中进行缓存。使用常用的分布式缓存中间件即可，例如redis。

A.基于缓存的网关工作步骤：

B.网关通过加载缓存模块，根据请求URL和参数解析，从缓存中查询数据

C.如果缓存命中(缓存有效期内)，那么直接返回结果

D.如果缓存未命中(缓存失效或者未缓存)，那么请求目标服务

E.请求结果返回网关

F.网关缓存请求结果

G.此处需要注意缓存常见问题：缓存雪崩、缓存击穿、缓存穿透，需要针对性的做好处理。

(8)、服务重试模块

对于服务重试至少需要提供两个功能：

配置：即需要配置哪些接口需要进行重试，重试几次；

执行：针对配置进行重试；

对于配置来说，需要配置请求的超时时间、单次请求的超时时间、重试次数，注意单次请求的超时时间*重试次数要小于请求的超时时间，否则会影响服务重试逻辑。同时，也需要考虑配置的动态生效，以保障网关的稳定性。

对于执行来说，根据配置的次数来进行处理即可。

逻辑实现并不复杂，不过考虑到有较成熟的开源项目，推荐直接使用开源项目来处理。

API网关是一个处于应用程序或服务(提供REST API接口服务)之前的系统，用来管理授权、访问控制和流量限制等，这样REST API接口服务就被API网关保护起来，对所有的调用者透明。因此，隐藏在API网关后面的业务系统就可以专注于创建和管理服务，而不用去处理这些策略性的基础设施。

这样，网关系统就可以代理业务系统的业务服务API。此时网关接收外部其他系统的服务调用请求，也需要访问后端的实际业务服务。在接收请求的同时，可以实现安全相关的系统保护措施。在访问后端业务服务的时候，可以根据相关的请求信息做出判断，路由到特定的业务服务上，或者调用多个服务后聚合成新的数据返回给调用方。网关系统也可以把请求的数据做一些过滤和预处理，同理也可以把返回给调用者的数据做一些过滤和预处理，即根据需要对请求头/响应头、请求报文/响应报文做一些修改。如果不做这些额外的处理，则简单直接代理服务API功能，我们称之为透传。

同时，由于REST API的语言无关性，基于API网关，后端服务可以是任何异构系统，不论Java、.NET、Python，还是PHP、ROR、Node.js等，只要支持PEST API，就可以被API网关管理起来。

以上所述，仅为本发明较佳的具体实施方式，但本发明的保护范围并不局限于此，任何熟悉本技术领域的技术人员在本发明揭露的技术范围内，根据本发明的技术方案及其发明构思加以等同替换或改变，都应涵盖在本发明的保护范围之内。

Claims (8)

1.基于微服务架构的API网关，包括路由转发模块、聚合服务模块、负载均衡模块、安全认证模块、日志记录模块、数据转换模块、流量控制模块、熔断模块、服务升降级模块、缓存模块和服务重试模块，其特征在于，所述路由转发模块与服务聚合模块连接，所述服务聚合模块与负载均衡模块连接，所述负载均衡模块与安全认证模块连接，所述安全认证模块与日志记录模块连接，所述日志记录模块与数据转换模块连接，所述数据转换模块与流量控制模块连接，所述流量控制模块与熔断模块连接，所述熔断模块与服务升降级模块连接，所述服务升降级模块与缓存模块连接，所述缓存模块与服务重试模块连接。

2.根据权利要求1所述的基于微服务架构的API网关，其特征在于，所述路由转发模块根据请求的规则转发到指定的服务。

3.根据权利要求2所述的基于微服务架构的API网关，其特征在于，所述聚合服务模块使得客户端只需要发送一个请求到网关，网关针对该请求，向多个目标微服务发送请求，将请求结果整合后返回给客户端。

4.根据权利要求3所述的基于微服务架构的API网关，其特征在于，所述负载均衡模块用于减少或停止向实例转发请求。

5.根据权利要求4所述的基于微服务架构的API网关，其特征在于，所述安全认证模块进行身份验证，身份验证通过后才转发给后面的服务，转发的时候也会带上身份信息。

6.根据权利要求5所述的基于微服务架构的API网关，其特征在于，所述日志记录模块既可以作为我们后续事件查询使用，也可以作为系统的性能监控使用。

7.根据权利要求6所述的基于微服务架构的API网关，其特征在于，所述数据转换模块将不同客户端传输进来的数据转换成同一种类型再转发给内部微服务上。

8.根据权利要求7所述的基于微服务架构的API网关，其特征在于，所述流量控制模块通过对并发访问请求数量进行控制或者一个时间窗口内的的请求数量进行控制来保护系统，一旦达到控制速率则可以拒绝服务、排队或等待。

Images