微服务网关首选：Spring Cloud Gateway 核心功能与实战指南

一、引言

在微服务架构日益普及的当下，服务间的通信管理变得愈发关键。Spring Cloud Gateway 作为 Spring Cloud 生态中的关键组件，以其独特的设计和强大的功能，为微服务架构提供了高效的 API 网关解决方案。API 网关是一个搭建在客户端和微服务之间的服务，我们可以在 API 网关中处理一些非业务功能的逻辑，例如权限验证、监控、缓存、请求路由等。

二、Spring Cloud Gateway 核心概念

Spring Cloud Gateway 是基于 Spring Boot 和 Spring WebFlux 构建的响应式 API 网关，在微服务架构中，它就像是整个系统的 “大门”，所有从外部进入微服务系统的请求都要经过它。它的主要工作包括把请求合理地转发到对应的微服务上（路由），控制请求的流量（流量管理），以及保障系统的安全（安全防护）等 。

其核心由路由（Route）、断言（Predicate）、过滤器（Filter）三大组件构成：

• 路由：可以理解为一条条转发规则，每一条规则都有一个独一无二的 ID ，用来标识这条规则。同时，它还包含目标 URI，即请求最终要被转发到的地址；断言集合则像是一组条件，只有请求满足这些条件，才会触发这条路由规则；过滤器集合可以在请求转发前或者响应返回后对请求或响应进行处理。​
• 断言：它的作用是对请求进行匹配判断，依据请求的各种属性，比如请求路径（Path）、请求方法（Method）、请求头信息（Header）等来决定是否匹配。Spring Cloud Gateway 提供了超过 10 种内置的断言工厂，像 Path 断言工厂能匹配请求路径，Header 断言工厂可匹配请求头，Query 断言工厂用于匹配请求参数等。例如，Path=/user/** 这个断言表示只要请求路径是以 /user/ 开头，就满足匹配条件。​
• 过滤器：分为全局过滤器和路由过滤器。全局过滤器对所有的路由都生效，就像一个 “通用管家”，对所有经过网关的请求和响应都进行处理；路由过滤器则只对特定的路由起作用，是 “专属管家”，只处理某个具体路由相关的请求和响应，它们都能实现对请求或响应的动态修改，比如添加请求头、修改响应体等。

三、Gateway的工作流程

• 客户端将请求发送到 Spring Cloud Gateway 上。
• Spring Cloud Gateway 通过 Gateway Handler Mapping 找到与请求相匹配的路由，将其发送给 Gateway Web Handler。
• Gateway Web Handler 通过指定的过滤器链（Filter Chain），将请求转发到实际的服务节点中，执行业务逻辑返回响应结果。
• 过滤器之间用虚线分开是因为过滤器可能会在转发请求之前（pre）或之后（post）执行业务逻辑。
• 过滤器（Filter）可以在请求被转发到服务端前，对请求进行拦截和修改，例如参数校验、权限校验、流量监控、日志输出以及协议转换等。
• 过滤器可以在响应返回客户端之前，对响应进行拦截和再处理，例如修改响应内容或响应头、日志输出、流量监控等。
• 响应原路返回给客户端。

四、Predicate 断言

spring Cloud Gateway 通过 Predicate 断言来实现 Route 路由的匹配规则。简单点说，Predicate 是路由转发的判断条件，请求只有满足了 Predicate 的条件，才会被转发到指定的服务上进行处理。

常见的 Predicate 断言如下表（假设转发的 URI 为 http://localhost:8001）。

五、实战案例

5.1 基础环境搭建

(1) 依赖配置：在构建基于 Spring Cloud Gateway 的企业级网关时，首先要确保项目的依赖配置正确。在 Maven 的 pom.xml 文件中，添加核心依赖：

<dependency>
    <groupId>org.springframework.cloud</groupId>
    <artifactId>spring-cloud-starter-gateway</artifactId>
    <version>4.2.4</version>
</dependency>

<dependency>
    <groupId>org.springframework.cloud</groupId>
    <artifactId>spring-cloud-starter-loadbalancer</artifactId>
    <version>4.3.0</version>
</dependency>

(2) 基础路由配置：在application.yml文件中进行基础路由配置，实现路径重写与负载均衡。假设我们有一个用户服务order-service，希望将所有以/order/开头的请求转发到该服务，并移除请求路径中的/order/前缀：

server:
  port: 8081
spring:
  main:
    web-application-type: reactive
  application:
    name: gateway-service
  cloud:
    nacos:
      config:
        server-addr: 127.0.0.1:8848
      discovery:
        server-addr: 127.0.0.1:8848
    gateway:
      routes: # 网关路由配置
        - id: product-service-route  # 路由id，自定义，只要唯一即可
          # uri: http://127.0.0.1:8081 # 路由的目标地址 http就是固定地址
          uri: lb://product-service # 路由的目标地址 lb就是负载均衡，后面跟服务名称
          predicates:  # 路由断言，也就是判断请求是否符合路由规则的条件
            - Path=/product/**
        - id: order-service-route # 路由id，自定义，只要唯一即可
          uri: lb://order-service # 路由的目标地址 lb就是负载均衡，后面跟服务名称
          predicates: # 路由断言，也就是判断请求是否符合路由规则的条件
            - Path=/order/**
    ***patibility-verifier:
      enabled: false
  config:
    import: nacos:gateway-service.yaml?group=DEFAULT_GROUP

上述配置中，id为路由的唯一标识；uri使用lb://order-service表示通过负载均衡的方式将请求转发到名为order-service的服务实例上，这要求order-service已经在服务注册中心（如 Nacos）中注册；predicates中的Path=/order/**表示匹配所有以/order/开头的请求路径；

5.2 进阶功能实现

分布式追踪集成：为了在复杂的微服务架构中更好地跟踪请求的处理流程，快速定位问题，我们结合 Sleuth+Zipkin 实现全链路追踪。

首先，在项目的pom.xml中添加 Sleuth 和 Zipkin 的依赖：

<dependencies>
    <!-- Sleuth依赖，用于生成和传递追踪信息 -->
    <dependency>
        <groupId>org.springframework.cloud</groupId>
        <artifactId>spring-cloud-starter-sleuth</artifactId>
    </dependency>
    <!-- Zipkin依赖，用于收集和展示追踪数据 -->
    <dependency>
        <groupId>org.springframework.cloud</groupId>
        <artifactId>spring-cloud-starter-zipkin</artifactId>
    </dependency>
</dependencies>

然后，在application.yml中配置 Sleuth 和 Zipkin：

spring:
  sleuth:
    sampler:
      probability: 1.0 # 采样率设置为1.0，表示全部采集
  zipkin:
    base-url: http://localhost:9411 # Zipkin服务器地址

六、主流网关的对比选型

在实际项目中，我们往往会面临多种网关技术的选择，Spring Cloud Gateway 与 Nginx、Zuul 1.x 各有千秋，适用于不同的场景。

Nginx 是一款高性能的 Web 服务器和反向代理服务器，采用异步非阻塞的事件驱动模型，在处理静态资源和高并发请求方面表现出色。它通过配置文件实现基本的路由和负载均衡功能，不过对于复杂的动态路由和业务逻辑，通常需要借助 Lua 脚本进行扩展 。在电商项目中，Nginx 常被用于静态资源的缓存和分发，如图片、CSS、JS 文件等，能有效减轻后端服务器的压力。

Zuul 1.x 是 ***flix 开源的网关组件，在 Spring Cloud 生态早期被广泛应用。它基于 Servlet 的同步阻塞模型，提供了动态路由、过滤器等功能，与 ***flix 的其他组件（如 Eureka、Hystrix）集成度较高。但在高并发场景下，由于线程阻塞的问题，性能表现相对较弱，且其路由配置相对静态，动态更新不够灵活 。在一些传统的企业级微服务项目中，如果对系统的兼容性和稳定性要求较高，且并发量不是特别大，Zuul 1.x 仍能发挥作用。

Spring Cloud Gateway 则凭借其响应式编程模型、丰富的功能特性以及与 Spring Cloud 生态的深度集成，成为了微服务架构的首选网关。它支持动态路由、流量治理、安全防护等一系列功能，并且通过 Java 代码或配置文件就能轻松实现复杂的业务逻辑 。在互联网金融项目中，Spring Cloud Gateway 可以结合服务注册中心，根据不同的业务场景和用户权限，动态地将请求路由到相应的微服务实例上，同时利用其限流和熔断功能，保障系统在高并发下的稳定运行。

七、小结

Spring Cloud Gateway 凭借其强大的路由能力、丰富的流量治理功能和深度的生态集成，成为微服务架构中网关的首选方案。通过合理运用动态路由、熔断限流、安全防护等特性，开发者能够快速构建高可用、可扩展的企业级网关。随着微服务架构的普及，掌握 Spring Cloud Gateway 核心技术已成为 Java 开发者的必备技能。

Tips: 为了大家快速高效的学习，已经将文章提交到了git仓库，涵盖后端大部分技术，以及后端学习路线，仓库内容会持续更新，建议 Star 收藏 以便随时查看https://gitee.***/bxlj/java-article。