Spring Cloud Gateway 的面试题在 Java 微服务方向基本属于必考内容。不管是校招还是社招只要简历上写了微服务项目面试官大概率会从“网关怎么用”“网关原理是什么”“网关出问题了怎么排查”这三个角度切进来。我整理这 20 个高频题的时候刻意没有按“背答案”的思路来而是按照一个真实项目的落地顺序来排先搞清楚网关是干嘛的再搞明白路由、断言、过滤器这三件套怎么配合然后进入动态路由、限流、跨域、排障这些生产环境绕不开的实战点最后再补几个二面三面喜欢追问的源码级问题。这篇文章既是面试复习提纲也是一份可以直接照着做的小型网关实战笔记。1. 第一个问题Spring Cloud Gateway 在微服务里到底扮演什么角色1.1 为什么微服务架构里必须有一个网关很多刚接触微服务的同学会把网关理解成“一个转发请求的玩意儿”这个理解没错但太浅了。网关最核心的价值是把“横切关注点”从业务服务里抽离出来。比如鉴权、限流、日志、灰度、跨域、参数校验这些逻辑如果每个服务都写一遍那就是灾难。有了网关之后请求先打到网关网关统一把这些事情做掉再路由到下游服务业务服务只需要关心自己的业务逻辑。从架构位置上看Spring Cloud Gateway 处在客户端和微服务集群之间是南北向流量的唯一入口。它基于 Spring WebFlux 和 Reactor 构建底层是 Netty天然支持高并发、异步非阻塞。这也是它在面试里被反复问的原因之一——选型本身就是架构能力的体现。你在回答“为什么用 Spring Cloud Gateway 而不是 Zuul”的时候其实就是在向面试官展示你对微服务基础设施的理解深度。1.2 核心概念先扫盲Route、Predicate、Filter 三兄弟Spring Cloud Gateway 的所有功能都围绕三个核心概念展开Route路由、Predicate断言、Filter过滤器。Route网关的基础单元由 ID、目标 URI、一组 Predicate 和一组 Filter 组成。Predicate匹配条件决定“请求满足什么条件时走这条路由”。Filter请求处理逻辑可以在转发前修改请求也可以在转发后修改响应。用大白话讲路由是一张“规则表”Predicate 是规则里的 if 条件Filter 是条件命中后要执行的逻辑。比如下面这段配置spring: cloud: gateway: routes: - id: user-service uri: lb://user-service predicates: - Path/api/user/** filters: - StripPrefix1它表达的是当请求路径以/api/user/开头时把前缀剥掉一层然后负载均衡转发到名为user-service的服务。面试里让你“解释一下 Spring Cloud Gateway 的工作流程”其实就是让你把这三者的协作关系讲清楚客户端请求进来 → DispatcherHandler 交给 RoutePredicateHandlerMapping → 遍历所有路由的 Predicate 判断是否匹配 → 匹配成功则组装过滤器链 → 执行过滤器链并转发到目标服务。1.3 面试必问对比题Spring Cloud Gateway 和 Zuul 怎么选这道题几乎是网关面试的开胃菜。你不需要贬低 Zuul但要能准确说出两者的本质区别。对比维度Spring Cloud GatewayZuul 1.x底层框架Spring WebFlux NettyServlet TomcatIO 模型异步非阻塞同步阻塞性能表现高并发下表现更好线程池耗尽后吞吐骤降内置限流RequestRateLimiter需要自己集成长连接支持支持 WebSocket支持但配置复杂配置风格YAML Java DSL类似 Spring MVC 注解Zuul 1.x 的问题在于每个请求占用一个线程IO 密集型场景下线程很容易成为瓶颈。Spring Cloud Gateway 则是事件驱动模型少量线程就能支撑大量并发连接。如果面试官追问“网关性能调优怎么做”你就可以顺着这个方向往下说核心不在调参而在选对 IO 模型Netty 的 boss/worker 线程模型能更好地利用多核 CPU。2. Predicate 面试题怎么把“if 条件”玩明白2.1 高频考点内置 Predicate 有哪些分别在什么场景用Predicate 这块面试最喜欢考的是“Spring Cloud Gateway 内置了哪些断言工厂”“Path 断言怎么写”“自定义断言怎么做”。内置的主要有这些Path按请求路径匹配比如Path/api/order/**Method按 HTTP 方法匹配比如MethodGET,POSTQuery按查询参数匹配比如Queryfoo,bar表示必须包含名为 foo 且值为 bar 的参数Header按请求头匹配比如HeaderX-Request-Id, \dCookie按 Cookie 匹配Host按 Host 匹配比如Host**.example.comRemoteAddr按来源 IP 匹配After / Before / Between按时间匹配常用于灰度发布、定时开放接口Weight权重路由按比例分发流量实际开发中 Path 和 Method 用得最多Weight 是灰度发布的利器After/Before 在活动接口定时上线下时很实用。有一个容易忽略的点是多个 Predicate 之间是AND 关系全部满足才走这条路由。如果你想实现“或者”的效果要配置多条路由或者用自定义 Predicate。2.2 手写一个自定义 Predicate面试官当场加分自定义 Predicate 的思路说白了就三步继承AbstractRoutePredicateFactory写一个配置类绑定参数把它注册成 Bean。比如我们要做一个“指定时间段才放行”的断言Component public class TimeRangeRoutePredicateFactory extends AbstractRoutePredicateFactoryTimeRangeRoutePredicateFactory.Config { public TimeRangeRoutePredicateFactory() { super(Config.class); } Override public PredicateServerWebExchange apply(Config config) { return exchange - { LocalTime now LocalTime.now(); return !now.isBefore(config.getStart()) !now.isAfter(config.getEnd()); }; } Validated public static class Config { private LocalTime start; private LocalTime end; // getter/setter } }然后在配置里启用spring: cloud: gateway: routes: - id: time-route uri: lb://order-service predicates: - TimeRangestart09:00,end18:00这里有几个细节配置项的绑定依赖shortcutFieldOrder或配置类上的字段名如果字段名对不上会绑定失败自定义 Predicate 的类名必须叫XxxRoutePredicateFactory配置里用的名字是去掉RoutePredicateFactory前缀后的驼峰转短横线形式。很多人在这一步踩坑按记忆写配置名结果启动报错。2.3 Path 断言的坑为什么配了 /api/** 还是 404搜“springcloud网关 path/api 开头”的热度一直很高说明这个问题大家普遍遇到过。Path 断言本身不难难的是和其他配置的配合。看这个例子客户端请求GET http://gateway/api/user/listpredicates: - Path/api/user/** filters: - StripPrefix1StripPrefix1的意思是去掉第一段路径所以转发到下游服务的实际路径是/user/list。如果你的下游服务接口定义是/api/user/list那就会 404。反过来说如果下游服务接口本来就接收/api/user/list那这条路由根本不需要 StripPrefix。我见过很多次生产事故就是有人把 StripPrefix 拍脑袋加上去导致转发路径和服务接口对不上。排查方法也很简单打开网关日志看转发的实际 URI或者临时去掉 StripPrefix 做对照测试。面试里如果聊到这个场景你可以顺带提一下/api/**这种 Ant 风格匹配和 Spring 5 新路径匹配器 PathPattern 的差异会让回答显得更有深度。3. Filter 面试题GlobalFilter 和 GatewayFilter 到底怎么分3.1 过滤器分类与执行顺序90% 的人第一个回答就错Spring Cloud Gateway 的过滤器分两类GatewayFilter针对某个路由单独配置的过滤器比如StripPrefix、AddRequestHeader、RetryGlobalFilter全局过滤器所有路由都会生效比如鉴权、日志、限流但关键是网关本身不区分“全局执行”和“局部执行”所有过滤器最终都会被包装成 GatewayFilter 放进过滤器链里。GlobalFilter 通过GatewayFilterAdapter适配成 GatewayFilter。执行顺序由Ordered接口决定order 值越小越先执行。比如自定义一个鉴权 GlobalFilterComponent public class AuthGlobalFilter implements GlobalFilter, Ordered { Override public MonoVoid filter(ServerWebExchange exchange, GatewayFilterChain chain) { String token exchange.getRequest().getHeaders().getFirst(token); if (StringUtils.isBlank(token)) { exchange.getResponse().setStatusCode(HttpStatus.UNAUTHORIZED); return exchange.getResponse().setComplete(); } // 校验 token 逻辑... return chain.filter(exchange); } Override public int getOrder() { return -100; } }这里要留意一个高频追问自定义过滤器的返回值为什么是MonoVoid因为整个网关是响应式编程模型chain.filter(exchange)返回的是响应式流后面的过滤器是在“流”上串起来的。你如果在这里卡住了面试官很快会确认你对 WebFlux 的理解停留在 API 层面。3.2 用 GlobalFilter 做统一鉴权和请求日志我建议你在项目里把鉴权和日志拆成两个 GlobalFilter不要混在一个里。鉴权过滤器 order 设为 -100日志过滤器 order 设为 -99。这样鉴权失败的请求不会进入日志过滤器日志里不会混入一堆未授权请求。日志过滤器里有一个容易踩的坑打印请求体。在 WebFlux 里请求体是流式的读取一次之后如果没有缓存下游就再也读不到了。所以要做缓存的话得用ServerHttpRequestDecorator包装请求把 body 缓存到内存里。这个代码量不小如果只是为了排查问题我一般先打请求头和查询参数body 留到确有必要再打。另外写统一异常响应时要注意编码问题。直接response.writeWith(Mono.just(buffer))很容易出现中文乱码因为响应头里没有设置 Content-Type。正确做法是exchange.getResponse().getHeaders().setContentType(MediaType.APPLICATION_JSON); byte[] bytes {\code\:401,\msg\:\未登录\}.getBytes(StandardCharsets.UTF_8); DataBuffer buffer exchange.getResponse().bufferFactory().wrap(bytes); return exchange.getResponse().writeWith(Mono.just(buffer));3.3 跨域配置allowedOrigins 和 allowedOriginPatterns 的经典坑网关层做跨域是标配但配置不对会让前端白白多一次 OPTIONS 预检请求甚至直接报跨域错误。Spring Cloud Gateway 支持两种配置方式一种是代码里加CorsWebFilter一种是在配置文件里配spring.cloud.gateway.globalcorsspring: cloud: gateway: globalcors: cors-configurations: [/**]: allowedOriginPatterns: * allowedMethods: * allowedHeaders: * allowCredentials: true maxAge: 3600注意这里新版推荐用allowedOriginPatterns而不是allowedOrigins。原因是当allowCredentialstrue时allowedOrigins不能设置为*否则浏览器会拒绝响应。而allowedOriginPatterns支持通配符匹配和allowCredentials可以共存。如果你看到“localhost 和 127.0.0.1 跨域不一致”的奇怪问题多半就是在这个细节上卡住了。3.4 限流面试题RequestRateLimiter 和令牌桶网关限流是生产环境的刚需也是面试高频题。Spring Cloud Gateway 内置的限流过滤器是RequestRateLimiter它依赖 Redis 和RedisRateLimiter底层用的是令牌桶算法。核心配置spring: cloud: gateway: routes: - id: order-service uri: lb://order-service predicates: - Path/api/order/** filters: - name: RequestRateLimiter args: redis-rate-limiter.replenishRate: 10 redis-rate-limiter.burstCapacity: 20 redis-rate-limiter.requestedTokens: 1 key-resolver: #{userKeyResolver}参数含义replenishRate每秒往桶里放入的令牌数也就是稳态速率burstCapacity桶容量允许的突发流量峰值requestedTokens每次请求消耗的令牌数key-resolver限流维度比如按用户、按 IP配套的 KeyResolver 代码Bean public KeyResolver userKeyResolver() { return exchange - { String userId exchange.getRequest().getHeaders().getFirst(userId); if (userId null) { return Mono.just(anonymous); } return Mono.just(userId); }; }面试里如果面试官问“限流和熔断有什么区别”你要分清限流是保护网关自身和下游不被打垮熔断是当下游故障时快速失败避免请求继续堆积。网关层做限流服务层做熔断两者是配合关系而非二选一。4. 动态路由网关配置不能写死在代码里的原因4.1 动态路由的本质路由数据从配置文件挪到注册中心如果你在面试时说“路由配置在 application.yml 里”面试官大概率会追问一句“那我要新增一个微服务是不是得重启网关”这就是动态路由的考点。动态路由的核心思路是把路由配置外置到 Nacos、Apollo 等配置中心网关启动时和配置变更时从配置中心拉取路由信息。Spring Cloud Gateway 提供了一个扩展点RouteDefinitionRepository。默认实现是InMemoryRouteDefinitionRepository它把路由信息存在内存里。你可以自己实现这个接口从数据库、Nacos、Redis 加载路由然后通过发布事件触发路由刷新。4.2 基于 Nacos 实现动态路由的完整思路一个简单的做法是网关引入 Nacos Config把路由配置放到 Nacos 的配置里然后监听配置变更事件手动发布RefreshRoutesEvent。核心代码Component public class NacosDynamicRouteService implements ApplicationEventPublisherAware { Autowired private RouteDefinitionWriter routeDefinitionWriter; private ApplicationEventPublisher publisher; public void updateRoutes(ListRouteDefinition routes) { for (RouteDefinition route : routes) { try { routeDefinitionWriter.save(Mono.just(route)).subscribe(); publisher.publishEvent(new RefreshRoutesEvent(this)); } catch (Exception e) { log.error(动态更新路由失败, e); } } } Override public void setApplicationEventPublisher(ApplicationEventPublisher publisher) { this.publisher publisher; } }原理层面你要能说清这一条链路RouteDefinitionWriter负责写入路由定义 →RefreshRoutesEvent事件触发 →RouteRefreshListener监听事件 → 清空RouteDefinitionLocator的缓存 → 重建Route列表。为什么有缓存因为路由匹配频繁每次都重新解析性能太差Spring Cloud Gateway 默认会对路由定义做缓存所以动态修改路由后必须触发刷新事件否则不生效。4.3 高可用进阶服务下线、超时和负载均衡动态路由和高可用经常放在一起问。网关一般会配合注册中心使用lb://service-name这种写法就是让网关通过 LoadBalancer 从注册中心拉取服务实例列表。但这里有一个经典问题服务下线了网关还是会把请求转发过去。原因通常是注册中心有服务列表缓存、客户端负载均衡有自己的缓存或者下线是优雅下线先摘流量再停止服务没有做好。回答时可以提一下启动spring-cloud-starter-loadbalancer的饥饿加载模式配置loadbalancer.cache.ttl和loadbalancer.cache.enabled可以减少这类问题。超时配置也是必问项Spring Cloud Gateway 里有两个层面的超时路由级和全局级。spring: cloud: gateway: httpclient: connect-timeout: 1000 response-timeout: 5sconnect-timeout单位是毫秒response-timeout是 Duration。这两个值要根据下游接口的 P99 耗时来设不能拍脑袋写个很大的值否则网关线程会被慢接口拖住。5. 生产排障面试题网关 404、503、性能问题怎么查5.1 网关 404 的排查顺序我建议你背下来生产环境网关返回 404是最常见但最容易慌的问题。我自己的排查顺序是这样先确认路由有没有匹配上访问GET /actuator/gateway/routes查看当前生效的路由列表。如果配置了但列表里没有说明配置没加载成功。再确认 Predicate 是否满足用curl模拟请求带齐 Header、Query、Cookie看是否命中路由。看 StripPrefix 等过滤器是否把路径改坏了打开网关 DEBUG 日志找到RoutingFilter打印的转发 URI。确认下游服务是否有这个接口绕过网关直接请求服务地址排除网关问题。确认下游服务前缀是否和转发路径一致很多服务有 context-path网关转发时要带上。这里面 90% 的问题出在第 2 步和第 3 步。Predicate 配置了但实际不匹配最常见的坑是路径前缀没对齐比如接口在服务里是/order/list网关用Path/api/**匹配后又加了 StripPrefix导致下游收到的路径变成order/list丢了斜杠。5.2 503 Service Unavailable 到底是网关问题还是下游问题在 Spring Cloud Gateway 场景里503 的“含金量”比 404 高因为 404 多半是路由没配好503 往往是上游真的没有可用实例。看到 503按这个思路排查服务是否注册到了注册中心去 Nacos/Eureka 控制台查看实例列表。服务实例是否健康健康检查失败会被注册中心剔除导致网关拿不到可用实例。服务是否每个实例都在但网关缓存了旧的服务列表重启网关或等待缓存过期。下游服务是否处于启动中Spring Cloud 有个特性服务启动早期会拒绝流量如果 LoadBalancer 拿到的实例还没准备好也会报 503。另外还有一个小概率原因HTTP 请求被转发到了 HTTPS 端口。如果目标服务的server.port配置错了或者网关 uri 写的是https://但下游实际是 http连接建立失败也可能返回 503 或 502。别问我怎么知道的这种事排查过就知道。5.3 性能抗压题内存泄漏、连接池和线程模型网关作为流量的咽喉高并发下的稳定性极其重要。面试爱问“网关性能怎么调优”可以分三层来答第一层内存。Netty 使用堆外内存Spring Cloud Gateway 在处理大响应体时容易堆外内存暴涨。JVM 参数建议显式设置-Dio.netty.maxDirectMemory512m -Dio.netty.allocator.maxOrder4第二层连接池。Spring Cloud Gateway 给下游发请求用的是 Netty 连接池连接池太小会等待太大可能拖垮下游。可以根据下游 QPS 和 RT 来估算比如下游单实例 QPS 2000连接池设 500 够用且不会压垮下游。配置在spring.cloud.gateway.httpclient.pool下面。第三层线程模型。网关的线程模型是事件循环不是说线程越多越好。Netty 的 boss 线程负责 acceptworker 线程负责 IO 读写。如果你的过滤器里有阻塞操作比如同步调 Redis、同步查数据库会严重拖慢事件循环线程。正确的做法是用WebClient或响应式客户端把阻塞操作异步化。这张表里的排查思路可以直接抄作业现象可能原因排查方式404路由未匹配 / StripPrefix 配置错误actuator/gateway/routes 对比路径503上游无可用实例 / 实例不健康注册中心实例列表 健康检查502上游连接失败 / 超时看网关日志中的转发异常请求缓慢连接池耗尽 / 下游 RT 高httpclient pool 指标 下游监控内存持续增长堆外内存泄漏 / 大响应体未释放开启 Netty leak 检测 压测验证5.4 过滤器顺序引起的奇怪问题请求头丢失、跨域失效过滤器顺序排错了会出现很多看着像“玄学”的问题。比如自定义鉴权过滤器在 CORS 处理之前执行导致跨域请求的 OPTIONS 预检被鉴权逻辑拦截前端明明配置对了跨域却报“CORS policy: No Access-Control-Allow-Origin”。这种问题你查半天跨域配置都发现不了实际上就是过滤器顺序问题。排查思路供你参考OPTIONS 方法的请求一般不携带业务凭证要在鉴权过滤器里直接放行CORS 相关的全局配置要保证在大多数业务过滤器之前生效自定义过滤器的 order 别全设成同一个值否则执行顺序不稳定同一个 order 值执行顺序不保证这是一个隐形的坑6. 源码级追问与架构演进别只停留在会用的层面6.1 面试官问“你能讲讲路由刷新的原理吗”动态路由的代码大家都会写但“为什么这么写”就没几个人说清楚了。路由刷新的核心链路是RouteDefinitionWriter修改路由定义保存、删除调用ApplicationEventPublisher.publishEvent(new RefreshRoutesEvent(this))RouteRefreshListener收到事件后清空CachingRouteLocator缓存下一次请求进来时RoutePredicateHandlerMapping重新从RouteDefinitionLocator构建路由Spring Cloud Gateway 里路由定义和路由是两个概念定义是配置层面的路由是运行时层面的。RouteDefinitionLocator加载定义RouteLocator根据定义生成路由。CachingRouteLocator在中间做了一层缓存所以更新定义后必须清缓存。这个链路能答出来说明你不是单纯调 API而是看过源码或至少研究过实现机制这在一个竞争激烈的岗位面试里是很重要的加分项。6.2 网关和高频组件 OpenFeign 的区别东西向和南北向面试官有时候会冷不丁问一句“网关和 OpenFeign 有什么区别”很多候选人会愣住因为这两个东西确实都管“服务调用”。其实关键在于流量的方向外部流量进入系统 → 经过 Spring Cloud Gateway → 这是南北向流量服务 A 调用服务 B → 通过 OpenFeign → 这是东西向流量网关管的是入口Feign 管的是内部服务间调用。网关可以做鉴权、限流、跨域Feign 做不了这些它更多是简化内部服务调用结合 Ribbon 或 LoadBalancer 做客户端负载均衡。一句话总结就是一个在“城外”守门一个在“城内”指路。6.3 从 Spring Cloud Gateway 到模型网关/AI 网关最近“模型网关”“AI 网关”热度很高如果面试官问你对网关发展趋势的理解可以从这个角度展开。传统 Spring Cloud Gateway 主要做 HTTP 转发、路由、鉴权、限流而新一代的模型网关/AI 网关在基础能力之上还要处理大模型 API 的统一接入、协议转换比如统一成 OpenAI 兼容协议、模型实例的路由与灰度、Token 消耗的配额管控、成本核算、流式响应的聚合与缓冲等。这些能力虽然不一定用 Spring Cloud Gateway 实现但网关的定位没有变收敛复杂性、统一入口、控制风险。如果你在面试里能把这个趋势讲清楚同时落到“Spring Cloud Gateway 的 Filter 链和动态路由机制在模型网关里同样适用”这个点就比只会背面试题的候选人高出一个段位。7. 面试答题话术提醒与最后的经验总结最后聊点实际的。这些题光看懂是不够的我建议你至少亲手把网关跑起来一次配两个微服务、写一个 GlobalFilter、做一次动态路由刷新、模拟一次 503 排障。你会发现很多面试题里“背”的知识点在你实际操作之后会变成真正属于自己的“直觉”。面试答题的时候有几点经验说到任何配置尽量把参数含义讲清楚比如StripPrefix1的“1”是什么意思replenishRate和burstCapacity的关系是什么。说到原理尽量画一条链路出来不用画得多标准但要让面试官觉得你有“链路思维”。说到排障不要只讲“看日志”要把排查顺序和判断依据讲出来这才是多年经验的体现。我个人在面试候选人时最喜欢问的其实是“你线上网关遇到 503 怎么处理”和“网关动态路由为什么需要刷新事件”。这两个题能同时考出项目经验、原理理解和排障能力。如果你能把本文里“动态路由链路”和“503 排查顺序”这两块练熟基本就能稳稳接住这一类问题。