Spring Cloud Gateway 深度：路由、过滤器链与流量控制Spring Cloud Gateway 是微服

概述

系列定位： 本文是《微服务与云原生架构》系列的第 7 篇。在前 6 篇确立了服务拆分、通信规范、服务治理与通信实现后，本文将聚焦全景图中的“流量治理”板块，构建微服务集群的统一 API 网关层。Spring Cloud Gateway 作为“大门”，接管外部流量的鉴权、路由、限流与熔断，是系统安全与稳定性的第一道防线。

总结性引言： 电商系统已经拆分为订单、库存、支付等多个微服务，它们通过 Nacos 注册发现，使用 Feign 或 Dubbo 内部通信，一切看似井然有序。然而，当浏览器或移动 App 需要调用这些服务时，问题随之浮现：客户端需要记住每个服务的地址吗？如何在不侵入业务代码的情况下统一进行 Token 校验？某个服务实例响应变慢，能否在入口就快速失败？大促流量洪峰，如何针对不同 API 设定精细的限流策略？答案全部落在 Spring Cloud Gateway 上。Gateway 绝非简单的反向代理，它是基于 Project Reactor 非阻塞编程模型、内置路由定位引擎与强大过滤器链的高性能 API 网关。通过 Predicate 工厂匹配路由，通过 GatewayFilter 修改请求与响应，再通过 GlobalFilter 实现负载均衡、限流、熔断等横切面能力。本文将跟踪一次“用户下单”的 HTTP 请求从进入 Gateway 到转发至后端服务的完整旅程，深挖每一步底层原理，并给出电商场景的生产级配置。

核心要点：

路由定位引擎：RouteDefinition 的加载、RoutePredicateHandlerMapping 的匹配流程与 Predicate 工厂定制。
过滤器链架构：GatewayFilter（请求/响应修改）与 GlobalFilter（负载均衡、代理转发）的执行顺序与源码深度。
限流策略：RedisRateLimiter 令牌桶算法，按路由、用户粒度的差异化限流。
熔断与降级：Resilience4JCircuitBreakerFilter 集成与 fallback 降级跳转。
动态路由：基于 Nacos 配置中心的路由热更新，零停机生效。
性能与协同：Netty 连接池调优，与 lb:// 协议及前文通信组件的无缝衔接。

文章组织架构图：

flowchart TD
    subgraph 内部机制
        direction LR
        1[1.Gateway 架构总览与自动装配]
        2[2.路由定位引擎与 Predicate]
        3[3.GatewayFilter 工厂]
        4[4.GlobalFilter 执行链与源码]
    end
    subgraph 流量治理
        direction LR
        5[5.限流集成: RedisRateLimiter]
        6[6.熔断降级: Resilience4j]
    end
    subgraph 生产实践
        direction LR
        7[7.动态路由刷新与 Nacos]
        8[8.性能调优与协议转换]
    end
    9[9.与前后系列的衔接]
    10[10.面试高频专题]
    
    1 --> 2 --> 3 --> 4
    4 --> 5 & 6
    5 --> 7
    6 --> 7
    7 --> 8
    1 & 2 & 3 & 4 & 5 & 6 & 7 & 8 --> 9
    9 --> 10

架构图说明（四层）：

图表主旨概括： 该图将全文 10 个模块划分为内部机制、流量治理、生产实践与知识串联四个逻辑组，展现从 Gateway 启动、请求处理到动态运维与面试巩固的递进认知路径。
逐层/逐元素分解： 模块 1-4 构建核心路由与过滤器认知，是理解一切上层能力的基础；模块 5-6 在此之上叠加限流与熔断两大流控能力；模块 7-8 解决生产环境动态配置与性能问题；模块 9 缝合系列知识；模块 10 面向面试场景系统化巩固。
设计原理映射： 这种组织方式符合“先理解内核，再叠加特性，最后回归工程实践”的学习闭环。路由与过滤器是 Gateway 的骨架，限流熔断是其肌肉，动态刷新与调优则是让系统健壮运行的血脉。
工程联系与关键结论： Spring Cloud Gateway 是微服务集群的“统一前厅”，通过声明式路由、可插拔过滤器与响应式编程模型，将流量治理能力从各服务下沉到入口网关，大幅降低了运维复杂度。掌握 Gateway，就是掌握了通往整个微服务集群的“控制闸门”。

1. Gateway 架构总览与自动装配

Spring Cloud Gateway 构建在 Spring WebFlux 和 Reactor Netty 之上，其核心是非阻塞、事件驱动的运行时。与传统的 Servlet 网关（如 Zuul 1.x）不同，Gateway 不会为每个请求分配一个线程，而是依赖少量线程处理大量并发连接，这使得它在高并发场景下具有天然的吞吐量优势。

1.1 核心组件自动装配

入口启动器是 GatewayAutoConfiguration，通过 @Configuration 和大量 @ConditionalOnBean、@ConditionalOnClass 等条件注解，按需装配核心组件。主要 Bean 的创建逻辑如下：

RouteLocator：实际上容器中注册的是 CachingRouteLocator，它装饰了 CompositeRouteLocator（组合了 PropertiesRouteDefinitionLocator、DiscoveryClientRouteDefinitionLocator、RouteDefinitionRepository 的实现等）。CachingRouteLocator 的核心特点是维护一个 Map<String, List<Route>> 缓存，并监听 RefreshRoutesEvent 事件以清空缓存重新加载。
RoutePredicateHandlerMapping：通过构造函数注入 RouteLocator 和 GatewayProperties，其 Order 默认设为 1，优先于其他 HandlerMapping。
FilteringWebHandler：接收 List<GlobalFilter>，在执行时将全局过滤器与路由特定的 GatewayFilter 组合成链。
各种 Predicate 与 Filter 工厂：例如 PathRoutePredicateFactory、AddRequestHeaderGatewayFilterFactory，通过 @Configuration 的内部 @Bean 方法注册。

Gateway 与 Spring WebFlux 共享同一套 DispatcherHandler 核心调度逻辑，但 Gateway 并不依赖任何 Controller。其请求处理完全由路由驱动。当请求到达 Netty 的 IO Worker 线程后，会经过 Reactor Netty 的 HTTP 编解码，然后进入 WebFlux 的 DispatcherHandler。DispatcherHandler 会遍历所有 HandlerMapping（包括 RoutePredicateHandlerMapping）寻找处理器。如果找到匹配的路由，则交由对应的 WebHandler（即 FilteringWebHandler）处理；如果没有任何路由匹配，则 DispatcherHandler 返回 404。

1.2 请求处理宏观流程

通过以下时序图可以清晰观察请求从进入 Netty 到返回响应的完整路径：

sequenceDiagram
    participant Client as 客户端
    participant Netty as Reactor Netty
    participant Codec as HTTP Codec
    participant Dispatcher as DispatcherHandler
    participant HandlerMapping as RoutePredicateHandlerMapping
    participant FilteringWebHandler as FilteringWebHandler
    participant GlobalFilters as GlobalFilter Chain
    participant RouteFilters as GatewayFilter Chain
    participant Backend as 后端服务

    Client->>Netty: HTTP Request
    Netty->>Codec: 解码为 ServerHttpRequest
    Codec->>Dispatcher: handle(request)
    Dispatcher->>HandlerMapping: getHandler(request)
    HandlerMapping->>HandlerMapping: 遍历 RouteLocator 路由 Predicate
    HandlerMapping-->>Dispatcher: 返回 FilteringWebHandler + Route
    Dispatcher->>FilteringWebHandler: handle(request)
    FilteringWebHandler->>GlobalFilters: 执行全局过滤器（前置）
    GlobalFilters-->>RouteFilters: 进入路由特定过滤器链
    RouteFilters-->>GlobalFilters: 代理请求到 Backend
    Backend-->>RouteFilters: 响应
    RouteFilters-->>GlobalFilters: 响应经过过滤器后置处理
    GlobalFilters-->>FilteringWebHandler: 响应
    FilteringWebHandler-->>Dispatcher: 响应
    Dispatcher-->>Codec: 编码
    Codec-->>Netty: 发送字节
    Netty-->>Client: HTTP Response

图表主旨概括： 该时序图描绘了从客户端发起请求到网关响应返回的完整生命周期，突出关键组件的职责与交互顺序。 逐层/逐元素分解： 首先由 Netty 和 HTTP Codec 完成网络层处理；DispatcherHandler 将请求路由到 RoutePredicateHandlerMapping，后者匹配路由并返回处理器；FilteringWebHandler 作为处理器，将全局过滤器和路由特定过滤器编织成链，最终由 NettyRoutingFilter 发起代理调用后端，响应按链返回。 设计原理映射： 全链路异步非阻塞，保证了网关线程不会被阻塞等待，提升了吞吐量。责任链模式将路由、过滤、代理等职责分离，便于扩展。 工程联系与关键结论： 理解此时序图是分析网关性能瓶颈和排查问题的基础。任何过滤器的阻塞都会影响整个链路的吞吐，因此所有过滤器实现必须非阻塞。Gateway 的性能优势源于 Reactor Netty 的事件驱动和零拷贝机制。

2. 路由定位引擎与 Predicate 工厂

2.1 RouteDefinition 的加载与转换

网关路由的元数据被抽象为 RouteDefinition，包含 id、uri、predicates、filters 以及 metadata 等。RouteDefinition 的加载途径有三种：

配置文件：PropertiesRouteDefinitionLocator 从 spring.cloud.gateway.routes 配置列表中读取。代码示例：

spring:
  cloud:
    gateway:
      routes:
        - id: order-service
          uri: lb://order-service
          predicates:
            - Path=/orders/**
          filters:
            - StripPrefix=1

服务发现自动生成：DiscoveryClientRouteDefinitionLocator 会为注册中心（如 Nacos、Eureka）中的每个服务自动生成一个路由，规则为 path=/serviceId/**，uri=lb://serviceId。这需要通过 spring.cloud.gateway.discovery.locator.enabled=true 开启，并允许配置大小写转换、谓词过滤器。
自定义动态源：实现 RouteDefinitionRepository 接口（可继承 InMemoryRouteDefinitionRepository 或完全自定义），从数据库、配置中心等动态拉取路由定义。Gateway 提供了一个 CachingRouteDefinitionLocator 包装以上 Locator，并缓存定义。

RouteDefinitionRouteLocator 负责将 RouteDefinition 转换为 Route 对象。对于每一个 RouteDefinition，它会遍历 predicates 列表，调用对应的 RoutePredicateFactory 生成 Predicate<ServerWebExchange>；同样遍历 filters 列表，调用 GatewayFilterFactory 生成 GatewayFilter。最终，一个 Route 对象包含组合后的谓词（所有谓词的与运算）和有序的过滤器列表。

2.2 RoutePredicateHandlerMapping 源码剖析

RoutePredicateHandlerMapping 实现了 HandlerMapping，核心方法 getHandlerInternal 返回 Mono<Object>。简化版关键代码逻辑：

@Override
protected Mono<?> getHandlerInternal(ServerWebExchange exchange) {
    return routeLocator.getRoutes()
        .filter(route -> route.getPredicate().test(exchange))
        .next()
        .map(route -> {
            // 将匹配的 Route 放入 exchange 属性
            exchange.getAttributes().put(GATEWAY_ROUTE_ATTR, route);
            // 返回 FilteringWebHandler
            return webHandler;
        });
}

要点：

routeLocator.getRoutes() 返回 Flux<Route>，这是所有已加载路由的响应式流。
filter 操作符顺序测试每个路由的谓词，直到找到第一个满足条件的路由。
next() 返回第一个匹配的路由的 Mono，若都不匹配则为空，最终返回 404。
如果 CachingRouteLocator 启用了缓存，getRoutes() 返回缓存值，避免每次请求都重新构建。

这种机制决定了路由的匹配顺序很重要。为了防止宽泛路由抢夺请求，应确保更具体的路由有更高的优先级（通过 order 属性或定义顺序）。

2.3 内置 Predicate 工厂详解

Gateway 内置了大量 Predicate 工厂，构建了多维匹配能力：

Path：Path=/orders/**。支持 Ant 风格路径模式，内部使用 PathPattern 或 AntPathMatcher 解析。
Header：Header=X-Request-Id, \d+。检查请求头是否满足正则表达式。
Query：Query=red, gree.。检查查询参数。
Method：Method=GET,POST。限定 HTTP 方法。
Host：Host=**.example.com。基于主机名匹配。
RemoteAddr：RemoteAddr=192.168.1.0/24。限制客户端 IP，支持 CIDR。
Cookie：Cookie=session, .+。检查存在性及正则匹配。
Weight：Weight=group1, 80。需要配合 Weight 过滤器使用，用于按权重分流。
Before / After / Between：基于时间匹配，较少用于生产。

每个 Predicate 工厂都继承了 AbstractRoutePredicateFactory<C>，通过 shortcutFieldOrder() 支持快捷配置。Predicate 之间的组合是 AND 关系，即只有当所有断言都满足时，路由才匹配。

2.4 自定义 Predicate 实现

实现一个基于 JWT Token 中角色进行路由的 Predicate。需继承 AbstractRoutePredicateFactory<Config>，在 apply 中返回 GatewayPredicate 的函数式接口。

@Component
public class RoleRoutePredicateFactory extends AbstractRoutePredicateFactory<RoleRoutePredicateFactory.Config> {

    public RoleRoutePredicateFactory() {
        super(Config.class);
    }

    @Override
    public Predicate<ServerWebExchange> apply(Config config) {
        return exchange -> {
            // 实际应从安全上下文或解析 JWT 获取角色
            String token = exchange.getRequest().getHeaders().getFirst("Authorization");
            String role = extractRoleFromJWT(token); // 抽象方法
            return config.getRole().equals(role);
        };
    }

    @Override
    public List<String> shortcutFieldOrder() {
        return Collections.singletonList("role");
    }

    @Data
    public static class Config {
        private String role;
    }
}

配置中使用：- id: admin_route，uri: lb://admin-service，predicates: - Role=ADMIN。这使得只有角色为 ADMIN 的请求被路由到管理后台。

2.5 路由匹配流程示意图

flowchart TB
    A[请求到达] --> B[RoutePredicateHandlerMapping]
    B --> C["获取所有 Route (Flux<Route>)"]
    C --> D[Route1: Predicate测试]
    D --> E{通过?}
    E -- No --> F[Route2: Predicate测试]
    F --> G{通过?}
    G -- No --> H[...]
    H --> I[未匹配: 返回404]
    E -- Yes --> J[匹配成功]
    G -- Yes --> J
    J --> K[将 Route 存入 exchange 属性]
    K --> L[返回 FilteringWebHandler]

图表主旨概括： 此流程图清晰地展示了路由匹配的决策过程，强调顺序性和短路特性。 逐层/逐元素分解： HandlerMapping 获取所有路由的响应式流，并依次应用谓词测试，一旦某个路由的谓词返回 true，则立即停止后续测试，选定该路由。 设计原理映射： 基于 Flux.filter().next() 的响应式流操作，保证了非阻塞顺序匹配。order 优先级的设计可解决路由冲突。 工程联系与关键结论： 生产环境中建议精确路径的路由放在前面，通配符放在后面。可通过 -1 的 order 让管理类路由最先匹配。精确配置路由顺序是避免 404 的关键。

3. GatewayFilter 工厂：请求与响应修改

GatewayFilter 作用于某个特定路由，由 GatewayFilterFactory 产生。Gateway 内置了众多过滤器，可以修改请求头、参数、路径，修改响应头、状态码，甚至重定向。

3.1 内置过滤器详解

AddRequestHeader：AddRequestHeader=X-Gateway-Timestamp, %{timestamp}。利用 SpEL 表达式动态添加请求头。
AddRequestParameter：添加查询参数。
RemoveRequestHeader：移除敏感头，如 Cookie。
SetRequestHeader：覆盖已有头。
RewritePath：RewritePath=/api/(?<segment>.*), /$\{segment}。利用正则捕获组重写路径，常用于去除公共前缀或版本号，是 StripPrefix 的灵活版。
StripPrefix：StripPrefix=1 剥离路径的第一节。
PrefixPath：在路径前添加前缀。
RedirectTo：发出重定向响应。
SetStatus：直接修改响应状态码。
Retry：结合 Resilience4j 实现重试，配置次数、状态码、方法等。
RequestSize：限制请求体大小，超限返回 413。

3.2 自定义 GatewayFilter：注入 TraceId

在电商系统中，全链路追踪是基础能力。网关作为入口，负责生成或传递 TraceId。

@Component
public class TraceIdGatewayFilterFactory extends AbstractGatewayFilterFactory<Object> {

    @Override
    public GatewayFilter apply(Object config) {
        return (exchange, chain) -> {
            String traceId = exchange.getRequest().getHeaders().getFirst("X-Trace-Id");
            if (traceId == null) {
                traceId = UUID.randomUUID().toString();
            }
            // 修改请求，添加 TraceId
            ServerHttpRequest request = exchange.getRequest().mutate()
                    .header("X-Trace-Id", traceId)
                    .build();
            // 继续过滤链，并使用修改后的请求
            return chain.filter(exchange.mutate().request(request).build());
        };
    }
}

路由配置：

spring:
  cloud:
    gateway:
      routes:
        - id: order-service
          uri: lb://order-service
          predicates:
            - Path=/orders/**
          filters:
            - TraceId

4. GlobalFilter 执行链与核心源码

GlobalFilter 应用于所有路由，执行顺序由 @Order 或 Ordered 接口控制。Gateway 的整个代理过程实际上是一系列 GlobalFilter 协作完成。

4.1 执行链顺序常量与机制

关键 GlobalFilter 的顺序常量（数值越小越早执行）：

NettyWriteResponseFilter (WRITE_RESPONSE_FILTER_ORDER = -1)：将响应数据写回客户端。
NettyRoutingFilter (Integer.MAX_VALUE 附近，实际为 Routes.ROUTING_FILTER_ORDER = 2147483647)：真正发起代理请求。
LoadBalancerClientFilter (LOAD_BALANCER_CLIENT_FILTER_ORDER = 10100)：用于解析 lb:// 协议。
ReactiveLoadBalancerClientFilter 替代前者（同序）。
RemoveCachedBodyFilter、AdaptCachedBodyGlobalFilter：处理请求体缓存，供多个过滤器读取。

FilteringWebHandler 将 GlobalFilter 列表与从 Route 中获取的 GatewayFilter 列表合并，通过 AnnotationAwareOrderComparator 排序，组合成 DefaultGatewayFilterChain。执行时按顺序遍历，每个过滤器可以在调用 chain.filter() 之前和之后插入逻辑，形成完整的环绕链。

4.2 NettyRoutingFilter 源码剖析

当路由的 URI 的 scheme 为 http 或 https 时，NettyRoutingFilter 生效。其 filter 方法核心逻辑：

// 获取请求 URL
URI requestUrl = exchange.getAttributeOrDefault(GATEWAY_REQUEST_URL_ATTR, exchange.getRequest().getURI());
// 构造 HttpClient 请求
return httpClient.headers(headers -> {
    headers.add(exchange.getRequest().getHeaders());
    headers.remove(HttpHeaders.HOST); // Netty 会自动添加
})
.request(method)
.uri(requestUrl)
.send((req, conn) -> {
    // 发送请求体并接收响应体
    return conn.inbound().receive().aggregate().cast(ByteBuf.class);
})
.timeout(responseTimeout)
.doOnRequest(...)
// 响应处理：将后端响应封装为 ClientResponse，设置到 exchange 中
.then(response -> {
    exchange.getAttributes().put(CLIENT_RESPONSE_ATTR, response);
    return Mono.empty();
});

整个代理过程完全异步，使用 Reactor Netty 的连接池。HttpClient 的配置通过 GatewayHttpProperties 定义，连接池参数直接影响网关吞吐。

4.3 LoadBalancerClientFilter 与 ReactiveLoadBalancerClientFilter

当 URI 协议为 lb:// 时（如 lb://order-service），ReactiveLoadBalancerClientFilter 拦截请求，执行服务发现与负载均衡：

ServiceInstance instance = loadBalancer.choose(serviceId).block(); // 响应式变体用 Mono
URI backendUri = URI.create(instance.getUri().toString() + path);
exchange.getAttributes().put(GATEWAY_REQUEST_URL_ATTR, backendUri);

此过滤器执行于 NettyRoutingFilter 之前，因此后者拿到的已经是真实的物理地址。它直接桥接了 Spring Cloud LoadBalancer，实现了与 Nacos 等服务发现的联动（见第 5 篇）。负载均衡算法默认轮询，可配置随机或自定义。

4.4 过滤器链执行顺序图

flowchart TD
    A[FilteringWebHandler] --> B["AdaptCachedBodyGlobalFilter (Order: -1000+)"]
    B --> C["... 用户自定义 GlobalFilter ..."]
    C --> D["ReactiveLoadBalancerClientFilter (Order: 10100)"]
    D --> E["NettyRoutingFilter (Order: MAX)"]
    E --> F["后端服务"]
    F --> G["NettyWriteResponseFilter (Order: -1)"]
    G --> H[客户端]

图表主旨概括： 展示请求和响应流经关键 GlobalFilter 的顺序，强调负载均衡解析与代理发起的位置。 逐层/逐元素分解： 请求经过前置缓存过滤器后，到达 ReactiveLoadBalancerClientFilter 将逻辑服务名替换为物理地址，NettyRoutingFilter 发起真实 HTTP 调用，收到响应后经过 NettyWriteResponseFilter 写回客户端。 设计原理映射： 通过固定 Order 值实现职责分离，负载均衡严格先于代理执行，保证代理使用正确地址；响应写入的顺序置于末尾，避免提前提交响应导致错误。 工程联系与关键结论： 故障排查时可通过断点查看 GATEWAY_REQUEST_URL_ATTR 的变化确认负载均衡是否生效。过滤器顺序绝不能随意调整，否则会导致请求转发失败或负载均衡失效。

5. 限流集成：RedisRateLimiter 深度

5.1 KeyResolver 与差异化限流策略

限流的首要步骤是确定限流粒度，这由 KeyResolver 接口完成。它返回一个 Mono<String>，此字符串将作为 Redis 中令牌桶的键。常见实现：

IP 维度：exchange -> Mono.just(exchange.getRequest().getRemoteAddress().getAddress().getHostAddress())
用户维度：exchange -> Mono.just(exchange.getRequest().getHeaders().getFirst("X-User-Id"))
API 维度：exchange -> Mono.just(exchange.getRequest().getPath().value())

不同路由可绑定不同的 KeyResolver Bean，通过 args.key-resolver 指定 SpEL 表达式（如 #{@ipKeyResolver}）。这使得我们在网关层可实施精细化的差异化限流，例如订单创建接口按用户 ID 限流（防止单用户刷单），库存查询接口按 IP 限流（防范爬虫）。

5.2 令牌桶算法与 Lua 脚本

RedisRateLimiter 使用 Redis 的 Lua 脚本保证操作的原子性。关键参数：

replenishRate：令牌填充速率（个/秒）。
burstCapacity：令牌桶最大容量，允许的突发流量。
requestedTokens：每次请求消耗的令牌数（默认为 1）。

Lua 脚本核心步骤：

获取当前时间戳（秒）。
计算自上次填充以来应生成的令牌数：(now - last_refill_time) * rate。
更新桶内令牌数：min(burstCapacity, current_tokens + new_tokens)。
判断 current_tokens >= requested，是则扣减并返回允许，否则返回拒绝。
所有操作在 Redis 中原子执行，并设置键的过期时间避免内存泄漏。

5.3 配置示例

spring:
  cloud:
    gateway:
      routes:
        - id: order_create
          uri: lb://order-service
          predicates:
            - Path=/orders
            - Method=POST
          filters:
            - name: RequestRateLimiter
              args:
                redis-rate-limiter.replenishRate: 10
                redis-rate-limiter.burstCapacity: 20
                key-resolver: "#{@userKeyResolver}"
  redis:
    host: redis-cluster
    port: 6379

5.4 限流令牌桶示意图

flowchart TD
    A[请求到达 RequestRateLimiter] --> B[调用 KeyResolver 获取 key]
    B --> C[组装 Lua 脚本参数]
    C --> D[执行 Redis Lua 脚本]
    D --> E{令牌充足?}
    E -- Yes --> F[扣减令牌, 继续过滤链]
    E -- No --> G[设置响应状态 429, 终止链]

图表主旨概括： 基于 Redis 的令牌桶限流全过程，KeyResolver 决定粒度，Lua 脚本保证原子性。 逐层/逐元素分解： 过滤器先调用 KeyResolver 得到限流键，然后将键和参数传给 RedisRateLimiter.isAllowed()，后者执行 Lua 脚本与 Redis 交互，根据返回值决定放行或拒绝。 设计原理映射： 限流状态外移至 Redis，使网关无状态化，可水平扩展；令牌桶算法可应对突发流量，贴近实际业务场景。 工程联系与关键结论： 双十一大促时，可调整 replenishRate 为 1000，burstCapacity 为 2000，确保瞬时尖峰不丢失请求又能保护后端。Redis 需保证高可用，避免成为单点瓶颈。

6. 熔断降级集成：Resilience4j 过滤器

6.1 集成断路器

当后端服务出现高延迟或失败时，网关应快速失败，防止线程阻塞。Gateway 通过 spring-cloud-starter-circuitbreaker-reactor-resilience4j 提供断路器能力。配置示例：

spring:
  cloud:
    gateway:
      routes:
        - id: inventory
          uri: lb://inventory-service
          predicates:
            - Path=/inventory/**
          filters:
            - name: CircuitBreaker
              args:
                name: inventoryCB
                fallbackUri: forward:/fallback/inventory
resilience4j:
  circuitbreaker:
    configs:
      default:
        slidingWindowSize: 10
        minimumNumberOfCalls: 5
        failureRateThreshold: 50
        waitDurationInOpenState: 10s
    instances:
      inventoryCB:
        baseConfig: default
  timelimiter:
    configs:
      default:
        timeoutDuration: 3s

当断路器打开（OPEN）时，所有请求不再路由到后端，而是被直接转发到 fallbackUri。网关层需提供一个降级端点，如：

@RestController
public class FallbackController {
    @GetMapping("/fallback/inventory")
    public Mono<Map<String, Object>> inventoryFallback() {
        return Mono.just(Map.of("code", 500, "message", "库存服务暂时不可用"));
    }
}

降级响应应当简单、快速，避免再次触发断路器。

6.2 状态流转图

stateDiagram-v2
    [*] --> CLOSED
    state CLOSED {
        [*] --> Counting : 正常统计调用
        Counting --> OPEN : 失败率 >= 阈值
    }
    OPEN --> HALF_OPEN : 等待时间到
    HALF_OPEN --> CLOSED : 试探调用成功
    HALF_OPEN --> OPEN : 试探调用失败
    state OPEN {
        [*] --> Fallback : 所有请求直接 fallback
    }

图表主旨概括： 断路器标准三态模型在 Gateway 中的表现，重点在 OPEN 到 HALF_OPEN 的自我恢复。 逐层/逐元素分解： CLOSED 态下统计失败率，达到阈值变 OPEN；OPEN 态下所有请求走 fallback；经过 waitDurationInOpenState 后变为 HALF_OPEN，允许少量请求通过，成功则切回 CLOSED，失败回到 OPEN。 设计原理映射： 快速失败与自动恢复是防止级联故障的核心。网关作为全局入口，其断路器对保护后端至关重要。 工程联系与关键结论： 需为每个关键路由配置独立断路器，避免一个服务故障拖垮整个网关。fallback URI 应设计为幂等且响应迅速，建议返回静态 JSON 或缓存数据。

7. 动态路由刷新与 Nacos 集成

7.1 实现原理

静态配置的路由在变更时需要重启网关，无法满足云原生持续交付的需求。利用 Nacos 配置中心实现动态路由，核心是自定义 RouteDefinitionRepository。

@Component
public class NacosRouteDefinitionRepository implements RouteDefinitionRepository, ApplicationEventPublisherAware {

    @Value("${nacos.data.id:gateway-routes}")
    private String dataId;

    private ApplicationEventPublisher publisher;
    private final Map<String, RouteDefinition> routes = new ConcurrentHashMap<>();

    @Override
    public Flux<RouteDefinition> getRouteDefinitions() {
        return Flux.fromIterable(routes.values());
    }

    @Override
    public Mono<Void> save(Mono<RouteDefinition> route) { /* 可选实现 */ }
    @Override
    public Mono<Void> delete(Mono<String> routeId) { /* 可选实现 */ }

    @NacosConfigListener(dataId = "${nacos.data.id:gateway-routes}", timeout = 3000)
    public void onChange(String configInfo) {
        // 解析 JSON 更新 routes Map
        // 发布 RefreshRoutesEvent
        publisher.publishEvent(new RefreshRoutesEvent(this));
    }
}

当 Nacos 上的路由 JSON 配置变更，onChange 被回调，更新内存定义并广播 RefreshRoutesEvent。CachingRouteLocator 监听到该事件后，会清空缓存并重新调用 getRouteDefinitions() 构建新路由，整个过程无需重启。

7.2 动态刷新机制图

flowchart LR
    A["Nacos 配置变更 (gateway-routes.json)"] --> B[NacosRouteDefinitionRepository.onChange]
    B --> C[解析 JSON 并更新 ConcurrentHashMap]
    C --> D[发布 RefreshRoutesEvent]
    D --> E[CachingRouteLocator 监听到事件]
    E --> F[清空 routeCache]
    F --> G["重新调用 getRouteDefinitions() 重建 Flux<Route>"]

图表主旨概括： 描述从 Nacos 配置变更到网关路由生效的全自动流程。 逐层/逐元素分解： 运维人员在 Nacos 控制台修改路由配置，客户端长轮询感知变动并回调 onChange；Repository 更新内存定义并发布事件；CachingRouteLocator 清理缓存并重建路由对象。 设计原理映射： 利用 Spring 事件驱动和响应式编程，实现配置与运行时解耦；原子替换缓存保证了请求处理无中断。 工程联系与关键结论： 动态路由允许在秒级内进行灰度发布、故障隔离或 A/B 测试。但必须确保新路由定义的正确性，异常路由会导致大面积 404。

8. 性能调优与协议转换实践

8.1 Netty 连接池与线程池调优

高并发下，Netty 的连接池和 IO 线程配置直接影响网关吞吐量：

spring:
  cloud:
    gateway:
      httpclient:
        connect-timeout: 2000
        response-timeout: 8s
        pool:
          max-connections: 1000           # 后端连接池最大连接数
          max-idle-time: 40s
          acquire-timeout: 5000          # 获取连接超时
          type: elastic                  # 或 fixed
reactor:
  netty:
    ioWorkerCount: 4                     # 通常为 CPU 核数

ioWorkerCount：默认为 Runtime.getRuntime().availableProcessors() * 2，对于 IO 密集型应用可适当调大，但需避免过高线程上下文切换。
max-connections：需大于等于 后端实例数 × 每个实例最大连接数。 acquire-timeout 设置过小会引发大量连接获取失败。
response-timeout 应略低于客户端超时，避免网关成为慢请求的瓶颈。

8.2 与内部通信协议的协同

Gateway 对外提供统一的 REST API，内部可能使用 Feign（HTTP）、Dubbo（RPC）或 gRPC 通信。对于 Feign 服务，只需配置 uri: lb://service-name 即可透明转发 HTTP 请求。对于 Dubbo 服务，网关不原生支持 Dubbo 协议，推荐方案：

泛化调用：在网关侧集成 Dubbo 的泛化调用客户端，根据路由规则转换为 Invocation，无需业务接口 jar，但实现复杂。
协议适配层：要求关键 Dubbo 服务同时提供 HTTP 接口（例如 Spring Web 暴露的 REST），网关走 HTTP，服务内部继续使用 Dubbo。这是最常用的折中方案，平衡了性能与网关兼容性。

不论哪种方案，TraceId 透传必须保证。网关注入的 X-Trace-Id 可通过 Feign 拦截器（见第 6 篇）或 Dubbo 的 RpcContext 隐式参数继续传递，串联全链路。

9. 与前后系列的衔接

第 4 篇（通信模型与 API 设计）：Gateway 是 API 设计规范的强制入口，路由前缀如 /api/v1/orders 对应 API 版本管理，RewritePath 实现版本剥离。
第 5 篇（服务治理）：Gateway 通过 lb:// 与 Nacos 服务发现联动，ReactiveLoadBalancerClientFilter 集成 Spring Cloud LoadBalancer，无感知实例上下线。
第 6 篇（通信实现）：Gateway 聚合外部流量，内部调用 Feign/Dubbo/gRPC 后端，TraceId 从头注入贯穿。
高并发系列第 1 篇（限流算法）：Gateway 中的 RequestRateLimiter 是令牌桶算法在统一入口的工业化应用。
高并发系列第 2 篇（熔断降级）：Resilience4j 集成在网关层提供入口级熔断，避免故障扩散。

10. 面试高频专题

10.1 常规面试题

1. Spring Cloud Gateway 的核心架构是什么？
一句话回答： 基于 WebFlux 的非阻塞 API 网关，通过 Predicate 匹配路由，Filter 链处理请求。
详细解释： Gateway 核心包含 RouteLocator（路由定位器）、Predicate 工厂、GatewayFilter（路由级）和 GlobalFilter（全局级）。请求到达 DispatcherHandler，RoutePredicateHandlerMapping 使用谓词匹配唯一路由，随后 FilteringWebHandler 将全局过滤器和路由特定过滤器组合成链，最终由 NettyRoutingFilter 发起代理请求，响应逆序返回。全部流程基于 Reactor Netty，线程模型非阻塞，适合高并发。
多角度追问：

与 Zuul 1.x 的根本区别？Zuul 1.x 基于 Servlet 阻塞模型，Gateway 非阻塞，连接数不再与线程数绑定，吞吐量显著提升。
路由匹配是短路还是全量？短路，Flux.filter().next() 确保首个匹配即停止。
如何自定义谓词？继承 AbstractRoutePredicateFactory，实现 apply 方法。
加分回答： Gateway 自动装配了大量工厂，可通过 spring.cloud.gateway.routes 轻松配置；同时与 Spring Cloud LoadBalancer、CircuitBreaker、RateLimiter 深度整合，构建完整的入口流量治理方案。

2. 路由定位是如何工作的？如何自定义 Predicate？
一句话回答： RoutePredicateHandlerMapping 遍历所有路由的 Predicate 并测试，首个匹配的路由被选中。
详细解释： 所有路由定义被转换为 Route 对象，每个 Route 包含一个组合 Predicate。匹配时顺序执行 route.getPredicate().apply(exchange)，返回 true 即命中。自定义 Predicate 需继承 AbstractRoutePredicateFactory，定义内部 Config 类和 apply 方法，并可通过 shortcutFieldOrder 支持快捷配置。
多角度追问：

多个路由冲突怎么处理？按 order 升序、再按定义顺序匹配。生产环境将精确路由 order 设低。
灰度发布路由怎么实现？用 Weight 或自定义 Header Predicate 根据版本路由。
Predicate 可以动态修改吗？可以，通过动态路由刷新实现。
加分回答： 可以基于安全角色、请求参数、甚至外部系统状态编写复杂谓词，实现多维度流量调度。

3. GatewayFilter 和 GlobalFilter 有何区别？执行顺序如何控制？
一句话回答： GatewayFilter 作用于特定路由，GlobalFilter 作用于所有路由，顺序由 @Order 控制。
详细解释： GatewayFilter 由路由定义的 filters 部分产生，仅对所属路由生效；GlobalFilter 作为 Spring Bean 对所有请求生效。执行顺序通过 Ordered 接口或 @Order 注解定义，最终在 DefaultGatewayFilterChain 中按 Order 排序执行。关键顺序：负载均衡 (10100) 先于代理 (MAX)，响应写入 (-1) 最后。
多角度追问：

如何让自定义全局过滤器在负载均衡前执行？设置 Order < 10100。
能否在 GatewayFilter 中修改请求体？可以，但需借助缓存 Body 过滤器。
过滤器链异常如何传播？通过 Mono.error 传递给 NettyWriteResponseFilter。
加分回答： 理解过滤链顺序对故障排查至关重要。使用 Gateway 的 debug 日志可以输出实际过滤器链及其顺序。

4. 如何实现基于 Redis 的限流？KeyResolver 如何选择？
一句话回答： 使用 RequestRateLimiter 过滤器，基于 Redis 令牌桶，通过 KeyResolver 决定限流维度。
详细解释： 限流维度由 KeyResolver 决定，如 IP、用户 ID、路径等。RedisRateLimiter 执行 Lua 脚本操作令牌桶，主要参数 replenishRate、burstCapacity。不同的路由可以绑定不同的 KeyResolver，实现按需限流。
多角度追问：

令牌桶与漏桶区别？令牌桶允许一定突发流量，漏桶强制匀速。
Redis 单点故障怎么办？限流降级为默认通过或默认拒绝，取决于业务需求。
如何实现多级限流？组合 GlobalFilter 做 IP 全局限流，GatewayFilter 做路由用户级限流。
加分回答： Lua 脚本性能极高，一次 isAllowed 调用仅需一次 Redis 往返，高并发下表现稳定。

5. Gateway 如何集成熔断降级？fallback 机制是什么？
一句话回答： 通过 CircuitBreaker 过滤器集成 Resilience4j，断路器打开时请求转发到 fallback URI。
详细解释： 在路由中配置 CircuitBreaker 过滤器和 fallbackUri，需提供降级端点。断路器状态根据滑动窗口统计的失败率转换，OPEN 状态下所有请求不走后端，直接调用降级端点。
多角度追问：

fallback 端点如何设计？应返回快速、幂等的静态数据或缓存，避免链式故障。
多个路由能否共享一个断路器？可以，但推荐独立配置，细粒度控制。
fallback 内部是否还走过滤链？转发是内部请求，会再次经过网关的处理器映射和过滤链，需谨慎配置。
加分回答： 可以结合 Resilience4j TimeLimiter 设置超时，防止慢请求堆积，实现双保险熔断。

6. 如何实现路由规则的动态刷新？
一句话回答： 自定义 RouteDefinitionRepository，监听 Nacos 配置变更，发布 RefreshRoutesEvent。
详细解释： 实现 RouteDefinitionRepository 接口，在 @NacosConfigListener 标记的方法中更新内存路由定义，并发布 RefreshRoutesEvent。CachingRouteLocator 收到事件后清空缓存并重建路由。
多角度追问：

刷新过程会丢失请求吗？不会，路由替换是原子性更新缓存。
除了 Nacos 还支持哪些？Apollo、Consul、数据库等均可。
如何验证新路由的有效性？可在发布前进行测试，或实现路由校验过滤器。
加分回答： 动态刷新结合容器化部署，可在秒级完成路由切换，实现零停机发布和流量切换。

7. 如何在 Gateway 中统一处理跨域？
一句话回答： 通过 spring.cloud.gateway.globalcors 配置或自定义 CorsWebFilter。
详细解释： Gateway 通过 YAML 配置全局 CORS 规则，内部会创建 CorsConfigurationSource 应用于所有路由。也可以自定义 WebFilter 更灵活地处理 CORS。
多角度追问：

为何不在后端服务处理 CORS？避免重复配置，且网关更合适。
预检请求（OPTIONS）如何处理？Gateway 可直接响应，而不路由到后端。
安全最佳实践？严格限制 allowedOrigins，不使用通配符 *。
加分回答： 结合 Gateway 的路由匹配，可以为不同路径设置不同的 CORS 策略。

8. Gateway 如何实现请求重试？
一句话回答： 使用 Retry GatewayFilter，可配置次数、状态码、方法等。
详细解释： 内置 Retry 过滤器基于 reactor-extra 的 Retry 操作符，支持 retries、statuses、methods、series 等配置，并可设置 backoff 参数。
多角度追问：

重试对幂等性的影响？一般只对 GET 等安全方法重试。
如何与熔断协调？重试消耗断路器统计窗口，可能导致更快开启。
重试风暴如何避免？限制最大重试次数，配合限流使用。
加分回答： 可以自定义重试策略，比如根据后端返回的特定错误码进行重试。

9. 如何记录全量请求/响应日志而不影响性能？
一句话回答： 利用响应式装饰器和异步日志实现，避免阻塞。
详细解释： 通过自定义 GatewayFilter，使用 exchange.mutate() 装饰请求和响应，并利用 Reactor 的 doOnEach 或 log() 操作符记录，同时使用 AdaptCachedBodyGlobalFilter 缓存请求体以支持多次读取。
多角度追问：

响应体如何多次读取？需要缓存响应体到内存，注意内存消耗。
日志量太大怎么办？采样或异步批量发送到 Kafka。
如何实现选择性记录？根据路径或状态码过滤。
加分回答： 结合 Micrometer 和 Tracing 实现分布式追踪，比记录全量日志更有效。

10. Gateway 与 Kubernetes Ingress 的区别？
一句话回答： Gateway 是功能丰富的应用层 API 网关，Ingress 是 K8s 流量入口，较简单。
详细解释： Gateway 提供限流、熔断、动态路由、认证等功能，深度集成 Spring Cloud 生态。Ingress 更关注 HTTP 路由和 TLS 终结，扩展性有限。通常可将 Gateway 部署在 K8s 集群内，作为 Ingress 后的二级网关。
多角度追问：

Gateway 能替代 Ingress 吗？可以，但需处理 K8s 服务发现。
两者如何协同？外部流量 -> Ingress -> Gateway -> 后端，各自关注不同层面。
性能对比？Gateway 基于 Netty 非阻塞，与 Nginx Ingress 性能接近。
加分回答： 使用 Spring Cloud Kubernetes 可以无缝集成 K8s 服务发现，Gateway 直接使用 lb:// 调用集群内服务。

11. 如何防止 Gateway 本身成为瓶颈或单点？
一句话回答： 部署多实例并前置负载均衡，Gateway 自身无状态，可水平扩展。
详细解释： Gateway 节点依赖外部 Nacos 配置和 Redis 限流，自身无状态，可通过 K8s 或传统方式水平扩展。需确保 Redis 高可用，合理配置连接池和超时。
多角度追问：

会话粘滞（sticky session）问题？一般无状态即可，若需要可在前置 LB 做粘滞。
跨地区部署？需就近接入，Gateway 配合全局负载均衡。
单节点 QPS 上限？受限于 Netty 连接数、内存和 CPU，常见 1~5 万 QPS，通过增加节点线性提升。
加分回答： 生产环境通常会部署多活网关，并利用健康检查和自动扩缩容保证高可用。

10.2 系统设计题深度解析

题目：设计一个支持多业务线独立限流、灰度发布、认证鉴权的高可用网关层，并提供关键配置与调优方案。

10.2.1 需求分析

某电商平台拥有订单、商品、库存、支付等多个业务线。每个业务线有独立的 API，并且都需要统一的认证授权、流量控制、灰度发布能力和高可用保障。具体要求：

多业务线独立限流：订单创建接口限制每用户 10 req/s，查询接口每 IP 100 req/s；库存查询每 IP 50 req/s。
灰度发布：支持基于请求头 X-Version: v2 将部分流量路由到新版本服务实例。
认证鉴权：统一校验 JWT Token，解析用户信息和角色，拒绝非法请求。
高可用与动态路由：路由配置可通过 Nacos 动态更新，网关本身可水平扩展，无单点。
性能要求：支撑整体 10000 QPS，单节点 2000 QPS，P99 延迟 < 500ms。

10.2.2 架构设计

采用 Spring Cloud Gateway 作为统一入口，前置云负载均衡器（如 Nginx、Cloud LB），后端服务注册到 Nacos，利用 Spring Cloud LoadBalancer 进行服务发现。Gateway 通过集成 Resilience4j 进行熔断，RequestRateLimiter 基于 Redis 进行限流。

整体架构图：

flowchart LR 
    subgraph "外部流量"
        Client["客户端"]
    end
    subgraph "高可用网关层"
        LB["负载均衡器 (Nginx/CLB)"]
        GW1["Gateway Instance 1"]
        GW2["Gateway Instance 2"]
        GW3["Gateway Instance ..."]
    end
    subgraph "基础设施"
        Nacos["Nacos 集群"]
        Redis["Redis 集群"]
    end
    subgraph "微服务"
        OrderV1["订单服务 v1"]
        OrderV2["订单服务 v2"]
        Inventory["库存服务"]
        Payment["支付服务"]
    end

    Client --> LB
    LB --> GW1 & GW2 & GW3
    GW1 & GW2 & GW3 --> Nacos
    GW1 & GW2 & GW3 --> Redis
    GW1 --> OrderV1
    GW2 --> OrderV2
    GW3 --> Inventory
    GW1 --> Payment

    classDef external fill:#f1f5f9,stroke:#334155,stroke-width:2px,color:#0f172a
    classDef gateway fill:#ede9fe,stroke:#8b5cf6,stroke-width:2px,color:#3b2f4b
    classDef infra fill:#dbeafe,stroke:#2563eb,stroke-width:2px,color:#1e3a8a
    classDef service fill:#fef3c7,stroke:#d97706,stroke-width:2px,color:#78350f

    class Client external
    class LB,GW1,GW2,GW3 gateway
    class Nacos,Redis infra
    class OrderV1,OrderV2,Inventory,Payment service

组件说明：

负载均衡器：分发流量到多个 Gateway 实例，同时可做 SSL 卸载。
Gateway 集群：无状态节点，集成 Nacos 动态路由、Redis 限流、全局鉴权过滤器。
Nacos：服务注册中心 + 配置中心，存储服务列表及动态路由 JSON。
Redis：存储限流令牌桶状态，高性能读写。
微服务：多版本共存，通过元数据区分。

10.2.3 详细设计

10.2.3.1 认证鉴权过滤器

实现一个 AuthGlobalFilter，Order 为 -100，优先执行。逻辑：从请求头获取 Token，调用内部 JWT 工具包验证，解析用户 ID 和角色，存入 ServerWebExchange 属性或安全上下文。如果 Token 无效，直接返回 401。

10.2.3.2 灰度发布

利用 Nacos 元数据和 LoadBalancer 的 HintBasedLoadBalancer。服务提供者启动时配置 spring.cloud.nacos.discovery.metadata.version=v2。网关路由配置不修改；灰度逻辑通过自定义 LoadBalancer 配置实现：Gateway 使用 HintBasedLoadBalancer，当请求头 X-Version 存在时，将版本号作为 hint 传递给 LoadBalancer，优先匹配对应元数据的实例。若没有对应版本实例，回落至默认版本。

10.2.3.3 多业务线独立限流

在路由配置中为不同路由指定不同的 KeyResolver 和速率参数。例如：

订单创建路由：key-resolver: "#{@userKeyResolver}", replenishRate=10, burstCapacity=20
订单查询路由：key-resolver: "#{@ipKeyResolver}", replenishRate=100, burstCapacity=200
库存查询：key-resolver: "#{@ipKeyResolver}", replenishRate=50, burstCapacity=100

userKeyResolver 从请求头 X-User-Id 获取（由鉴权过滤器注入），ipKeyResolver 获取客户端 IP。

10.2.3.4 熔断降级

为每个关键路由配置独立的断路器，如 orderCB、inventoryCB，并定义对应的 fallback 控制器。

10.2.3.5 动态路由

自定义 NacosRouteDefinitionRepository 监听 gateway-routes.json，内容示例：

[
  {
    "id": "order-create",
    "uri": "lb://order-service",
    "predicates": [{"name": "Path", "args": {"pattern": "/orders"}}, {"name": "Method", "args": {"methods": "POST"}}],
    "filters": [
      {"name": "RequestRateLimiter", "args": {"redis-rate-limiter.replenishRate": "10", "burstCapacity": "20", "key-resolver": "#{@userKeyResolver}"}}
    ]
  }
]

运维只需更新此 JSON，Gateway 自动刷新。

10.2.4 关键请求流程（时序图）

sequenceDiagram
    participant Client
    participant LB
    participant Gateway
    participant Nacos
    participant Redis
    participant OrderService

    Client->>LB: POST /orders (JWT token)
    LB->>Gateway: 负载请求
    Gateway->>Gateway: AuthGlobalFilter 校验JWT，注入 X-User-Id
    Gateway->>Gateway: RoutePredicateHandlerMapping 匹配到 order-create 路由
    Gateway->>Gateway: RequestRateLimiter 调用 KeyResolver 获取 user123
    Gateway->>Redis: EVAL lua_script user123 ...
    Redis-->>Gateway: allowed
    alt 限流拒绝
        Gateway-->>Client: 429 Too Many Requests
    else 允许
        Gateway->>Nacos: 根据服务名 order-service 获取实例列表
        Nacos-->>Gateway: [instance1 (v1), instance2 (v2)]
        Gateway->>Gateway: ReactiveLoadBalancerClientFilter + HintBasedLoadBalancer 选择实例
        Gateway->>OrderService: POST /orders + headers (X-Trace-Id, X-User-Id)
        OrderService-->>Gateway: 200 OK
        Gateway-->>Client: 200 OK
    end

10.2.5 关键配置与调优

Gateway 核心配置：

spring:
  cloud:
    gateway:
      httpclient:
        connect-timeout: 2000
        response-timeout: 5s
        pool:
          max-connections: 1000
          acquire-timeout: 5000
      discovery:
        locator:
          enabled: false # 禁用自动生成路由，完全使用动态路由
  redis:
    host: redis-cluster
    port: 6379
  security:
    oauth2: ... # 若使用OAuth2
reactor:
  netty:
    ioWorkerCount: 4
resilience4j:
  circuitbreaker:
    instances:
      orderCB: ...

调优参数建议：

ioWorkerCount：设置为 CPU 核数，避免上下文切换。
max-connections：每节点 1000，假设后端实例 10，每实例允许 100 连接。
JVM 参数：-Xms2g -Xmx2g -XX:+UseG1GC，保证 GC 停顿低。
监控：集成 Micrometer + Prometheus 暴露指标，重点关注 gateway.requests、resilience4j.circuitbreaker 等指标。

10.2.6 扩展性考虑

网关层可进一步集成 Sentinel 做更细粒度流控。
灰度策略可升级为基于用户画像的动态路由。
路由存储可改为数据库 + Redis 缓存，提供管理界面。

加分回答： 此设计保证了网关无状态化，所有状态（限流、路由）外移至 Redis 和 Nacos，配合 K8s HPA 可根据 CPU 或 QPS 自动扩缩容，完美适配云原生环境。

Demo 代码与延伸阅读

电商网关完整配置示例（application.yml）： 已在前文各部分给出。

延伸阅读：

《Spring Cloud Gateway 官方文档》
《Reactive Spring》第 6-9 章
《Cloud Native Patterns》第 4 章
《Netty in Action》第 12-15 章（Netty 连接池与性能）

全文完。