• 千万级大型API网关设计


    前言:由于互联网的高速发展,网络数据请求数激增,使得服务器承受的压力越来越大。在早期的系统架构中,为减轻单台服务器的压力,通常使用 Load Balancer 来将网络流量平摊到多个服务器中。如今后端服务的种类和数量在不断变多,传统的 Load Balancer 为主的系统架构的局限性就变得明显起来,于是一款主要工作在七层且具有丰富扩展能力的基础设施便应运而生,那便是 API Gateway。

    一、API网关的概念

    1.1 API网关定义

    API网关 简单来说是一种主要工作在七层、专门用于 API 的管理和流量转发的基础设施,并拥有强大的扩展性。

    网关的角色是作为一个API架构,用来保护、增强和控制对于API服务的访问。它是一个处于应用程序或服务(提供REST API接口服务)之前的系统,用来管理授权、访问控制和流量限制等。这样REST API接口服务就被网关保护起来,对所有的调用者透明。因此,隐藏在API网关后面的业务系统就可以专注于创建和管理服务,无需关心这些策略性的请求。

    网关工作流程如下图:

    1.2 API网关的主要功能

    (1)基础业务功能

    服务发现与注册:提供API接口的注册和发现功能。

    • API路由:根据对外提供的服务接口,收到外部请求后将请求路由至不同的应用程序进行处理。

    • 快速熔断:为不同客户制定不同的安全策略,超过策略时进行熔断,防止外部恶意调用和恶意攻击。

    • 服务降级:不同客户制定不同的并发请求,超过并发量后进行限制。

    • 负载均衡:API网关通常会通过负载均衡配置多台形成高可用,并将请求负载至不同的服务器。

    • 缓存功能:配置缓存功能,根据实际业务需求对数据进行二次加工处理。

    • 日志记录:API管理后台需要记录相关调用日志,用于统计分析和事件溯源。

    (2)基础安全功能

    • 黑白名单:通过IP地址设置白名单限制,只有配置的白名单才能发起接口调用。黑名单是至默认都开放,发现异常调用后配置黑名单,纳入黑名单的不能发起调用。

    • 加密解密:包括https的链路加密(传输通道加密),数据包的加密,数据包中敏感数据加密。

    • 时间戳:提供时间戳,防止重放攻击。

    • 安全认证:对调用方、调用接口进行身份认证,通常调用方需要提前注册,分配客户ID和密钥等信息。 

      图片

    1.3 微服务网关分类

    ①流量网关

    流量网关,顾名思义就是控制流量进入集群的网关,有很多工作需要在这一步做,对于一个服务集群,势必有很多非法的请求或者无效的请求,这时候要将请求拒之门外,降低集群的流量压力。

    定义全局性的、跟具体的后端业务应用和服务完全无关的策略网关就是上图所示的架构模型——流量网关。流量网关通常只专注于全局的Api管理策略,比如全局流量监控、日志记录、全局限流、黑白名单控制、接入请求到业务系统的负载均衡等,有点类似防火墙。Kong 就是典型的流量网关。

    下面是kong的架构图,来自官网:

    这里需要补充一点的是,业务网关一般部署在流量网关之后、业务系统之前,比流量网关更靠近业务系统。通常API网关指的是业务网关。有时候我们也会模糊流量网关和业务网关,让一个网关承担所有的工作,所以这两者之间并没有严格的界线。

    ②业务网关

    当一个单体应用被拆分成许许多多的微服务应用后,也带来了一些问题。一些与业务非强相关的功能,比如权限控制、日志输出、数据加密、熔断限流等,每个微服务应用都需要,因此存在着大量重复的代码实现。而且由于系统的迭代、人员的更替,各个微服务中这些功能的实现细节出现了较大的差异,导致维护成本变高。另一方面,原先单体应用下非常容易做的接口管理,在服务拆分后没有了一个集中管理的地方,无法统计已存在哪些接口、接口定义是什么、运行状态如何。

    网关就是为了解决上述问题。作为微服务体系中的核心基础设施,一般需要具备接口管理、协议适配、熔断限流、安全防护等功能,各种开源的网关产品(比如 zuul)都提供了优秀高可扩展性的架构、可以很方便的实现我们需要的一些功能、比如鉴权、日志监控、熔断限流等。

    与流量网关相对应的就是业务网关,业务网关更靠近我们的业务,也就是与服务器应用层打交道,那么有很多应用层需要考虑的事情就可以依托业务网关,例如在线程模型、协议适配、熔断限流,服务编排等。下面看看业务网关体系结构:


    二、网关必须具备的特点

    1.高性能

    对于高性能而言,网关不应该也不能成为性能的瓶颈,最好使用高性能的编程语言来实现,如 C、C++、Go 和 Java。网关对后端的请求,以及对前端的请求的服务一定要使用异步非阻塞的 I/O 来确保后端延迟不会导致应用程序中出现性能问题。C 和 C++ 可以参看 Linux 下的 epoll 和 Windows 的 I/O Completion Port 的异步 IO 模型,Java 下如 Netty、Spring Reactor 的 NIO 框架。

    2.高可用

    所有的流量或调用都要经过网关,所以网关必须成为一个高可用的组件,它的稳定直接关系到了所有服务的稳定。不能出现单点故障,因此,一个好的网关至少做到以下几点。

    • 集群化 :网关要成为一个集群,并可以自己同步集群数据,而不需要依赖于第三方系统来同步数据。

    • 服务化 :网关还需要做到在不间断的情况下修改配置,一种是像 Nginx reload 配置那样,可以做到不停服务,另一种是最好做到服务化。也就是说,得要有自己的 Admin API 来在运行时修改配置。

    • 持续化 :比如重启,就是像 Nginx 那样优雅地重启。有一个主管请求分发的主进程。当我们需要重启时,新的请求被分配到新的进程中,而老的进程处理完正在处理的请求后就退出。

    3.高扩展

    网关要承接所有的业务流量和请求,所以一定存在或多或少的业务逻辑。而业务逻辑是多变和不确定的,比如,需要在网关上加入一些和业务相关的东西。因此一个好的网关还需要是可以扩展的,并能进行二次开发。当然,像 Nginx 那样通过 Module 进行二次开发的也是可以的。


    三、网关主要功能

    1. 路由功能: 路由是微服务网关的核心能力。通过路由功能微服务网关可以将请求转发到目标微服务。在微服务架构中,网关可以结合注册中心的动态服务发现,实现对后端服务的发现,调用方只需要知道网关对外暴露的服务API就可以透明地访问后端微服务。

    2. 负载均衡: API网关结合负载均衡技术,利用Eureka或者Consul等服务发现工具,通过轮询、指定权重、IP地址哈希等机制实现下游服务的负载均衡。

    3. 统一鉴权: 一般而言,无论对内网还是外网的接口都需要做用户身份认证,而用户认证在一些规模较大的系统中都会采用统一的单点登录(Single Sign On)系统,如果每个微服务都要对接单点登录系统,那么显然比较浪费资源且开发效率低。API网关是统一管理安全性的绝佳场所,可以将认证的部分抽取到网关层,微服务系统无须关注认证的逻辑,只关注自身业务即可。

    4. 限流熔断 : 在某些场景下需要控制客户端的访问次数和访问频率,一些高并发系统有时还会有限流的需求。在网关上可以配置一个阈值,当请求数超过阈值时就直接返回错误而不继续访问后台服务。当出现流量洪峰或者后端服务出现延迟或故障时,网关能够主动进行熔断,保护后端服务,并保持前端用户体验良好。

    5. 灰度发布: 微服务网关可以根据HTTP请求中的特殊标记和后端服务列表元数据标识进行流量控制,实现在用户无感知的情况下完成灰度发布。

    6. 日志审计: 微服务网关可以作为统一的日志记录和收集器,对服务URL粒度的日志请求信息和响应信息进行拦截。

    7. 指标监控: 网关可以统计后端服务的请求次数,并且可以实时地更新当前的流量健康状态,可以对URL粒度的服务进行延迟统计,也可以使用Hystrix Dashboard查看后端服务的流量状态及是否有熔断发生。

    8. 协议转换: API网关的一大作用在于构建异构系统,API网关作为单一入口,通过协议转换整合后台基于REST、AMQP、Dubbo等不同风格和实现技术的微服务,面向Web Mobile、开放平台等特定客户端提供统一服务。

    9. 黑白名单: 微服务网关可以使用系统黑名单,过滤HTTP请求特征,拦截异常客户端的请求,例如DDoS攻击等侵蚀带宽或资源迫使服务中断等行为,可以在网关层面进行拦截过滤。比较常见的拦截策略是根据IP地址增加黑名单。在存在鉴权管理的路由服务中可以通过设置白名单跳过鉴权管理而直接访问后端服务资源。

    10. 文档中心: 网关结合Swagger,可以将后端的微服务暴露给网关,网关作为统一的入口给接口的使用方提供查看后端服务的API规范,不需要知道每一个后端微服务的Swagger地址,这样网关起到了对后端API聚合的效果。


    四、目前主流的网关

    • Spring Cloud Gateway:是springcloud的全新API网关项目,旨在替换zuul的网关服务,基于spring framework5.0+springboot 2.0+webFlux开发,其也实现了异步非阻塞的特性,有较高的性能,其有丰富的过滤器类型,可以根据自身需求来自定义过滤器。

    • Zuul 2.0 : 采用Netty实现异步非阻塞编程模型,一个CPU一个线程,能够处理所有的请求和响应,请求响应的生命周期通过事件和回调进行处理,减少线程数量,开销较小。相比于zuul 1.0,zuul 2.0实现的异步非阻塞的特性,在性能上有较大提升。

    • OpenResty : OpenResty基于 Nginx与 Lua 的高性能 Web 平台,其内部集成了大量精良的 Lua 库、第三方模块以及大多数的依赖项。用于方便地搭建能够处理超高并发、扩展性极高的动态 Web 应用、Web 服务和动态网关。

    • Kong : 基于OpenResty(Nginx + Lua模块)编写的高可用、易扩展的,性能高效且稳定,支持多个可用插件(限流、鉴权)等,开箱即可用,只支持HTTP协议,且二次开发扩展难,缺乏更易用的管理和配置方式

    网关之间的对比如下图:


    总而言之:

    API Gateway 主要用于作为后端的 API 接口代理,提供对外访问不同种类 API 的一个单独入口,并且可以提供独立于后端服务的限流、认证、监控等功能。

    在合理的架构设计下,一般都将 API Gateway 和 Load Balancer 配合使用,使用 Load Balancer 作为整个系统的网络出入口,将流量分发到多个 API Gateway 实例,然后每个 API Gateway 实例分别对请求进行路由、认证、鉴权等操作,这样可以使得整个网络更加稳健、可靠、可扩展。


    参考链接:

    API接口的6大安全风险、3个风险管控措施|附检查清单

    微服务架构必读篇 - 网关

  • 相关阅读:
    [附源码]SSM计算机毕业设计教务系统JAVA
    如何理解GAN神经网络
    性能优化篇(四) GPU Instancing
    国窖1573持续演绎共生魅力,携手马岩松个展感知建筑艺术之美
    03使用Spring基于XML的方式注册第一个组件
    升级降级苹果手机iOS系统工具iMazing2024
    modelsim实现二选一以及D触发器并仿真
    【应用层协议】初始Http,fiddler的使用
    卷积神经网络
    List集合Stream流转PageInfo或Page分页
  • 原文地址:https://blog.csdn.net/CSDN2497242041/article/details/133806210