1. 网关工程全景与Spring Cloud Gateway定位

在单体应用时代,所有功能模块打包成一个进程,客户端直接访问这个进程的 HTTP 端口,请求路径与业务模块一一对应。随着业务拆分,用户服务、订单服务、库存服务各自独立部署,客户端如果继续直连每个服务,就会面临地址列表膨胀、鉴权逻辑重复、跨域配置分散、协议不统一等一连串问题。流量入口从“一个进程的端口”演变为“一组服务的集合”,这正是 API 网关出现的根本动因。

API 网关的核心职责可以概括为五类:路由转发(把外部请求按路径、主机、请求头等条件映射到内部服务)、统一鉴权(在入口处完成令牌校验、权限判定,避免每个服务重复实现)、流量治理(限流、熔断、重试、超时控制)、协议适配与转换(外部 HTTPS/JSON 与内部 HTTP/gRPC 之间的桥接)、可观测性(统一日志、链路追踪、指标采集)。网关不是业务逻辑的容器,而是横切关注点的集中承载点。

在 Spring Cloud 生态中,Spring Cloud Gateway 处于最外层的流量入口位置。它构建在 Spring WebFlux 与 Project Reactor 之上,采用非阻塞的响应式编程模型。与传统的 Servlet 阻塞模型相比,响应式模型用少量线程即可支撑大量并发连接:请求到达后不会占用线程等待下游响应,而是通过事件回调在数据就绪时继续处理。这意味着在同等硬件条件下,网关可以承载更高的并发吞吐,尤其适合作为微服务集群的统一入口。

与 Zuul 的对比是理解 Spring Cloud Gateway 定位的关键。Zuul 1.x 基于 Servlet 阻塞模型,每个请求占用一个线程,高并发下线程池容易成为瓶颈;Zuul 2.x 虽然改为异步非阻塞,但并未整合进 Spring Cloud 的官方技术栈,社区支持与生态集成度有限。Spring Cloud Gateway 从设计之初就与 Spring Cloud 的注册中心、配置中心、负载均衡器无缝协作,是 Spring Cloud 官方推荐的网关方案。

客户端 浏览器 移动 App 第三方系统 HTTPS / JSON 请求 Spring Cloud Gateway 路由匹配 Route Predicate 过滤器链 GatewayFilter 鉴权 / 限流 / 熔断 日志 / 链路追踪 / 指标 响应式模型 · WebFlux + Reactor 用户服务 user-service /api/user/** 订单服务 order-service /api/order/** 库存服务 stock-service /api/stock/** 注册中心 Nacos / Eureka 服务发现 统一流量入口 单体:直连端口 微服务:统一网关

从图中可以看到,客户端不再直接面对多个服务地址,而是统一访问 Spring Cloud Gateway。网关内部依次完成路由匹配、过滤器链处理、鉴权限流等横切逻辑,再通过服务发现将请求转发到具体微服务。这种结构把“入口”从物理端口抽象为逻辑网关,使流量治理、安全策略和可观测性有了统一的落点。

理解 Spring Cloud Gateway 的响应式模型,需要抓住三个关键点。第一,线程模型:WebFlux 默认使用少量事件循环线程(通常与 CPU 核数相关),请求处理不阻塞线程,而是注册回调。第二,背压机制:Reactor 的 Publisher/Subscriber 模型允许下游向上游声明消费能力,避免慢消费者被快速生产者压垮。第三,过滤器链:Gateway 的过滤器分为 GlobalFilter 和 GatewayFilter,前者对所有路由生效,后者绑定特定路由,二者共同构成请求处理管道。

下面给出一个最小可运行的路由配置示例,用于说明网关如何把外部路径映射到内部服务。示例中的服务名与端口均为教学假设,实际使用时需替换为真实注册中心中的服务标识。

spring:
  cloud:
    gateway:
      routes:
        - id: user-service-route
          uri: lb://user-service
          predicates:
            - Path=/api/user/**
          filters:
            - StripPrefix=1
            - AddRequestHeader=X-Gateway-Source, scg
        - id: order-service-route
          uri: lb://order-service
          predicates:
            - Path=/api/order/**
          filters:
            - StripPrefix=1

这段配置的含义是:当请求路径匹配 /api/user/** 时,网关将请求转发到注册中心里名为 user-service 的实例(lb:// 表示走负载均衡),并去掉路径中的第一段 /api,同时添加一个请求头标识来源。匹配 /api/order/** 的请求同理转发到 order-service。启动网关后,访问 http://localhost:8080/api/user/1,如果用户服务正常返回数据,说明路由与转发链路已经打通;如果返回 404 或 503,则应依次检查路由断言是否匹配、服务是否注册成功、负载均衡器是否可用。

响应式模型带来的性能优势并非“无条件更快”,而是在高并发、IO 密集型场景下用更少线程支撑更多连接。如果网关中混入阻塞式调用(如 JDBC 同步查询、Thread.sleep),会阻塞事件循环线程,反而拖垮整体吞吐。因此网关层应保持轻量,把重业务逻辑下沉到下游服务。

综合来看,Spring Cloud Gateway 在微服务架构中承担的是“入口层”角色:对上统一接收客户端流量,对下通过服务发现与负载均衡分发请求,对内集中处理鉴权、限流、日志等横切关注点。它既不是业务服务的替代品,也不是简单的反向代理,而是微服务流量治理的控制面。理解这一点,是后续学习路由断言、过滤器、限流熔断等具体能力的基础。