Spring Cloud - API 网关 (Spring Cloud Gateway)

微服务架构 —— API 网关 (Spring Cloud Gateway)

1. 核心理论：为什么需要 API 网关？

在微服务架构中，一个客户端请求（例如打开一个商品详情页）可能需要调用多个后台服务（商品服务、库存服务、评论服务等）。如果没有统一的入口，会带来诸多问题：

  • 客户端逻辑复杂: 客户端需要维护所有微服务的地址，并自己处理服务组合逻辑。
  • 认证授权繁琐: 每个微服务都需要独立实现一套认证和授权逻辑，导致代码重复。
  • 运维成本高: 难以进行统一的日志记录、流量监控和限流。
  • 跨域问题: Web 前端直接调用不同域名的服务会遇到浏览器的跨域限制。

API 网关 (API Gateway) 正是解决这些问题的“银弹”。它作为所有微服务的统一入口，像一个“总前台”或“守门人”，负责接收所有外部请求，并根据一定的规则将请求路由到正确的内部服务。

网关的核心职责：

  • 请求路由 (Routing): 根据请求的路径、域名、Header 等信息，将请求转发到正确的微服务。这是网关最核心的功能。
  • 统一鉴权 (Authentication & Authorization): 在网关层对用户进行统一的身份认证和权限校验，后端服务无需再关心认证问题，只需关注业务逻辑。
  • 协议转换 (Protocol Translation): 可以将外部的 HTTP/RESTful 请求转换为内部的 RPC 调用，对异构系统非常友好。
  • 统一的横切关注点 (Cross-Cutting Concerns): 在网关层可以轻松实现统一的日志记录、监控、限流熔断、黑白名单等，避免在每个服务中重复实现。

2. Spring Cloud Gateway 核心概念

Spring Cloud Gateway 是 Spring Cloud 生态中用于取代 Zuul 1.x 的新一代网关。它基于 Spring 5、Spring Boot 2 和 Project Reactor，是一个完全异步非阻塞的网关，性能非常高。

其核心由三大组件构成：

  • 路由 (Route): 这是网关最基本的组成部分。一个路由包含一个唯一的 ID、一个目标 URI、一组断言和一组过滤器。如果所有断言都为真，则匹配该路由。

  • 断言 (Predicate): 这是路由的匹配条件。当一个请求进来时，Gateway 会用断言来判断这个请求是否应该被当前路由处理。断言可以匹配请求的各种属性，例如路径 (Path)、请求方法 (Method)、Header、Host 等。只有所有断言都匹配成功，路由才会生效。

  • 过滤器 (Filter): 这是路由的加工逻辑。过滤器可以在请求被路由到下游服务之前（pre-filter）或下游服务返回响应之后（post-filter）对请求或响应进行修改。例如，可以添加一个请求头、记录请求日志、修改响应体等。过滤器分为 GatewayFilter 和 GlobalFilter 两种。

工作流程

Spring Cloud Gateway 的工作流程可以被清晰地描绘成一个请求通过一系列检查和处理步骤的旅程。

[客户端 Client]
      |
      | 1. 发起 HTTP 请求 (Request)
      v
+-------------------------------------------------------------+
|                  [Spring Cloud Gateway]                       |
|                                                             |
|  +------------------+   2. Gateway 根据请求，           |
|  | Gateway Handler  |      将其分发给 Web Handler。       |
|  |    Mapping       | ----------------------------------> |
|  +------------------+                                     |
|          |              3. Handler Mapping 通过         |
|          |                 Predicate (断言) 找到          |
|          v              匹配的 Route (路由)。             |
|  +------------------+                                     |
|  |   Gateway Web    |   4. 请求进入过滤器链进行处理。        |
|  |     Handler      | ----------------------------------> |
|  +------------------+                                     |
|          |                                                |
|          v                                                |
|  +-------------------------------------------------------+  |
|  |                 [过滤器链 Filter Chain]                 |  |
|  |                                                     |  |
|  | [Global PreFilter 1] -> [GatewayFilter (pre) 2] ... |  |
|  +-------------------------------------------------------+  |
|          |                                                |
|          | 5. 请求经过所有 pre-filter 处理后，被转发。       |
|          v                                                |
+-------------------------------------------------------------+
      |
      | 6. 负载均衡 (Load Balancer) & HTTP 请求到下游微服务
      v
[目标微服务 Microservice]
      |
      | 7. 微服务返回 HTTP 响应 (Response)
      v
+-------------------------------------------------------------+
|                  [Spring Cloud Gateway]                       |
|                                                             |
|  +-------------------------------------------------------+  |
|  |                 [过滤器链 Filter Chain]                 |  |
|  |                                                     |  |
|  | ... [GatewayFilter (post) 2] -> [Global PostFilter 1] |  |
|  +-------------------------------------------------------+  |
|          ^                                                |
|          | 8. 响应沿着过滤器链反向传递，被 post-filter 处理。|
|          |                                                |
+-------------------------------------------------------------+
      |
      | 9. Gateway 将最终响应返回给客户端
      v
[客户端 Client]

详细步骤分解：

  1. 客户端请求：客户端向 Spring Cloud Gateway 发起请求。
  2. Handler Mapping：Gateway 的 GatewayHandlerMapping 组件负责接收请求，并根据一系列的断言 (Predicate) 来判断这个请求应该由哪个路由 (Route) 来处理。
  3. 路由匹配：如果请求满足了某个路由的所有断言条件，那么这个路由就被匹配成功。
  4. Web Handler 与过滤器链：请求被传递给 GatewayWebHandler。WebHandler 会将请求放入一个过滤器链 (Filter Chain) 中。
  5. Pre-Filtering (前置过滤)：请求在被实际转发到下游服务之前，会经过一系列过滤器的“pre”阶段处理。这些过滤器可以修改请求头、记录请求日志、进行鉴权等。过滤器分为全局过滤器（GlobalFilter）和路由指定的局部过滤器（GatewayFilter）。
  6. 请求转发：请求通过所有前置过滤器的处理后，Gateway 会利用负载均衡客户端（如 Spring Cloud LoadBalancer）从注册中心获取目标服务的实例，并将请求转发过去。
  7. 下游服务响应：目标微服务处理请求，并返回响应。
  8. Post-Filtering (后置过滤)：响应会沿着过滤器链反向传递回来，并经过所有过滤器的“post”阶段处理。在这个阶段，可以修改响应头、响应体内容等。
  9. 返回客户端：最终，处理完毕的响应被 Gateway 返回给原始的客户端。

3. 配置示例 (application.yml)

Gateway 的配置非常直观，通常在 application.yml 中完成。

server:
  port: 9527

spring:
  application:
    name: api-gateway
  cloud:
    nacos:
      discovery:
        # 指向 Nacos Server，让网关自己也注册进去，并能发现其他服务
        server-addr: 127.0.0.1:8848
    gateway:
      routes:
        # 这是一个路由规则的配置，可以配置多个
        # 规则ID，必须唯一
        - id: order_route
          # 目标服务的URI。lb:// 表示从注册中心获取服务并进行负载均衡
          uri: lb://order-service
          # 断言（匹配条件）：当请求路径匹配 /order/** 时，此规则生效
          predicates:
            - Path=/order/**
          # 过滤器（可选）：对此路由生效的过滤器
          filters:
            # 例如，移除请求路径的第一部分（/order）
            - StripPrefix=1

        # 这是另一个路由规则
        - id: product_route
          uri: lb://product-service
          predicates:
            - Path=/product/**

      # 开启从注册中心动态创建路由的功能（可选）
      # 它会为注册中心里的每个服务，自动创建一个路由规则，
      # 规则是：Path=/服务名/**
      discovery:
        locator:
          enabled: true
          # 将服务名转为小写
          lower-case-service-id: true
  • lb://order-service: lb 是负载均衡 (Load Balancer) 的缩写。这行配置告诉 Gateway，不要去一个写死的 IP 地址，而是去 Nacos（或其他注册中心）查找一个名为 order-service 的服务，并把请求发给它。如果该服务有多个实例，Gateway 会自动进行负载均衡。
  • discovery.locator.enabled: true: 这是一个非常方便的自动化配置。启用后，Gateway 会自动从注册中心发现服务，并为每个服务创建一个默认的路由。例如，对于 order-service，会自动创建一个匹配 /order-service/** 路径的路由。这在开发阶段非常有用，可以省去手动配置 routes 的麻烦。
posted @ 2026-01-21 16:27  我是刘瘦瘦  阅读(1)  评论(0)    收藏  举报