深入探索Spring Cloud Gateway：微服务网关的最佳实践

优质博文：IT-BLOG-CN

Spring Cloud Gateway作为Spring Cloud框架的第二代网关，在功能上要比Zuul更加的强大，性能也更好。随着Spring Cloud的版本迭代，Spring Cloud官方有打算弃用Zuul的意思。在笔者调用了Spring Cloud Gateway的使用和功能上，Spring Cloud Gateway替换掉Zuul的成本上是非常低的，几乎可以无缝切换。Spring Cloud Gateway几乎包含了Zuul的所有功能。

一、网关定义

API网关是一个反向路由，屏蔽内部细节，为调用者提供统一入口，接收所有调用者请求，通过路由机制转发到服务实例。API网关是一组“过滤器Filter”集合，可以实现一系列与核心业务无关的横切面功能，如安全认证、限流熔断、日志监控。

网关在系统中所处的位置：

二、快速开始

网关启动步骤（代码演示）：

【1】添加依赖

    org.springframework.cloud
    spring-cloud-starter-gateway

【2】配置文件

spring:
  cloud:
    gateway:
      discovery: # 启用通过服务发现自动创建路由。
        locator:
          enabled: true
      routes:
        - id: example_route   #路由ID，根据业务自行定义
          uri: lb://example-service  #目标服务的地址，这里使用 lb:// 前缀来表示负载均衡。可以是 HTTP(s) URI 或其他协议的 URI - http://bin.org:80/get。
          predicates:
            - Path=/example/** #predicates: 谓词数组，用于匹配请求。常见的谓词包括 Path、Method、Header 等。
          filters:   #过滤器数组，用于在请求被转发到目标服务之前和之后进行处理。常见的过滤器包括 AddRequestHeader、StripPrefix、RewritePath 等。
            - AddRequestHeader=X-Example, ExampleValue #过滤器会在请求头中添加 X-Example，值为 ExampleValue。
            - StripPrefix=1 #过滤器会移除路径中的第一个前缀。例如，请求路径 /example/test 会变成 /test。
        - id: rate_limited_route
          uri: http://ratelimited.org
          predicates:
            - Path=/ratelimited/**
          filters:
            - RequestRateLimiter=redis-rate-limiter # 限流：通过 RequestRateLimiter 过滤器实现
        - id: retry_route
          uri: http://retry.org
          predicates:
            - Path=/retry/**
          filters:
            - Retry=5 #重试：通过 Retry 过滤器实现。
      default-filters: #default-filters 是全局过滤器数组，适用于所有路由。这个过滤器会在所有响应中添加 X-Response-Default 头，值为 Default。
        - AddResponseHeader=X-Response-Default, Default
      globalcors: #globalcors 用于配置全局的 CORS（跨域资源共享）设置。
        corsConfigurations: #corsConfigurations: 定义 CORS 配置的路径模式。
          '[/**]': #匹配所有路径。
            allowedOrigins: "*" #允许的源，* 表示允许所有源。
            allowedMethods: #允许的 HTTP 方法，包括 GET、POST、DELETE 和 PUT。
              - GET
              - POST
              - DELETE
              - PUT

三、Spring Cloud GateWay 架构图

客户端向Spring Cloud Gateway发出请求。 在Gateway Handler Mapping中找到请求相对匹配路由（这个时候就用到predicate），则将其发送到Gateway web handler处理。 handler处理请求时会经过一系列的过滤器链。 过滤器链被虚线划分的原因是过滤器链可以在发送代理请求之前或之后执行过滤逻辑。 先执行所有pre过滤器逻辑，然后进行代理请求。 在发出代理请求之后，收到代理服务的响应之后执行post过滤器逻辑。这跟Zuul的处理过程很类似。在执行所有pre过滤器逻辑时，往往进行了鉴权、限流、日志输出等功能，以及请求头的更改、协议的转换；转发之后收到响应之后，会执行所有post过滤器的逻辑，在这里可以响应数据进行了修改，比如响应头、协议的转换等。在上面的处理过程中，有一个重要的点就是将请求和路由进行匹配，这时候就需要用到predicate，它是决定了一个请求走哪一个路由。

四、SpringColoud GateWay 核心组件

集合上面的配置和架构图进行说明

【1】Route路由： Gateway的基本构建模块，它由ID、目标URL、断言集合和过滤器集合组成。如果聚合断言结果为真，则匹配到该路由。

Route路由-动态路由实现原理： 配置变化Apollo + 服务地址实例变化Nacos。Spring Cloud Gateway通过RouteDefinitionLocator和RouteRefreshListener等组件实现动态路由。

先看下配置信息，方便后面原理的理解：SpringCloudGateway bootstrap.yml的配置如下：

spring:
  application:
    name: gateway-service
  cloud:
    nacos:
      discovery:
        server-addr: ${
   NACOS_SERVER_ADDR:localhost:8848}
    apollo:
      bootstrap:
        enabled: true
      meta: ${
   APOLLO_META:localhost:8080}

application.yml的配置如下：

spring:
  cloud:
    gateway:
      discovery:
        locator:
          enabled: true