刚开始做微服务拆分那阵子我对网关层的理解相当肤浅觉得它就是个转发请求的入口顶多再做点路由配置。直到有一次线上出事故某个业务服务为了排查问题临时把登录接口的鉴权逻辑给注释掉了结果该服务所有接口直接裸奔了大半天下游其他两个服务因为信任上游传递的用户信息也跟着出了数据越权问题。那会儿我才真正意识到把鉴权、限流这类横切逻辑散落在各个业务服务里本质上就是在埋雷。后来我把 Spring Cloud Gateway 作为统一入口把所有服务的路由、限流、JWT 校验全部上收才总算把这道防线补上了。这篇就把我在实际项目里的踩坑和落地过程完整梳理一遍。1. 网关一层到底拦了什么从服务路由到流量治理Spring Cloud Gateway 本身是基于 Spring WebFlux 和 Reactor Netty 的响应式网关底层不走传统的 Servlet 线程模型而是事件驱动。这意味着它的线程开销比 Zuul 1.x 那种同步阻塞模型小得多在同样的硬件条件下能扛住的并发量级明显更高。做限流和鉴权这种横切逻辑放在网关层最大的好处是所有流量都从这里过你不用在每个业务服务里重复实现同一套逻辑而且将来要调整策略只改网关一个地方就行。网关层的核心职责可以拆成三块。第一是路由转发根据路径、Host、Header 等断言条件把请求分发到对应的下游服务第二是横切逻辑注入通过过滤器链在请求到达业务服务之前统一处理鉴权、限流、日志、跨域等第三是流量治理包括熔断、重试、限流这一块在微服务架构里尤其重要因为某一个服务的抖动如果不加遏制很容易通过调用链传导到整个系统。我记得有一个项目里前后端是分离的前端静态资源部署在 CDN所有 API 请求都打到网关。当时登录态校验写在各个服务各自的拦截器里每个服务都要引入同样的 JWT 解析依赖代码重复率极高。更要命的是有一个服务因为历史原因用的是旧版 JWT 库解析逻辑和其他服务不一致同一个 Token 在这个服务能通过、在另一个服务就报签名错误。后来统一收归到网关做 JWT 鉴权业务服务从请求头里拿用户信息就行这类问题才算彻底根治。网关选型上面Spring Cloud Gateway 对比 Zuul 2.x 的优势在于它和 Spring Cloud 生态的整合更自然路由配置既支持 Java DSL 也支持配置文件而且内置了 RequestRateLimiter 过滤器工厂配合 Redis 做分布式限流非常方便。我到目前为止没有遇到必须换 Zuul 的场景如果你是从零开始做微服务网关直接选 Spring Cloud Gateway 基本不会错。2. 限流不是配个参数那么简单三种算法在网关上的真实表现限流这块最常见的误区是以为在网关配个每秒允许 100 个请求的参数就完事了。实际上限流算法的选择直接决定了流量突增时系统的表现。我在项目里对比过三种主流算法下面把它们的核心差异和适用场景讲清楚。计数器算法是最直观的把时间窗口切成固定长度每个窗口内维护一个计数器超过阈值就直接拒绝。实现起来极其简单但有一个明显的边界问题假设限制每秒 100 个请求如果在第 0.9 秒来了 100 个请求下一秒刚开始又来了 100 个请求那么实际上在 0.1 秒内就放过了 200 个请求。也就是说计数器算法允许两倍于阈值的突发流量穿透在真正的生产环境这可能直接把下游打挂。滑动窗口算法是计数器的改进版把时间窗口细分成多个小格子每个格子独立计数滑动时把过期格子的计数剔除。它解决了计数器算法的临界突变问题但代价是内存占用更高而且如果粒度划得不够细仍然存在一定的精度损失。滑动窗口在单机场景下实现很容易但跨节点要做分布式协调就麻烦一些。令牌桶算法是目前网关限流场景应用最广的它的思路是系统以恒定速率往桶里放令牌每个请求要拿到令牌才能放行。桶有容量上限意味着允许一定程度的突发流量。形象一点理解就像地铁站的闸机正常情况下每分钟放 60 个人进站但如果站台上突然聚集了一波人闸机也可以在短时间内放进比 60 更多的乘客前提是队伍后面的人得等下一批令牌。令牌桶在应对高并发突发流量时的表现比较出色既保证了平均速率又允许短时峰值。这里有一个容易忽略的点RedisRateLimiter 的补令牌行为基于 Redis 中的两个 Key一个存剩余令牌数另一个存上次补充时间戳。如果用一个不稳定的 Redis 实例来做限流存储限流本身的可用性就会成为瓶颈。我们当时把限流用的 Redis 和业务缓存用的 Redis 分开部署就是为了避免业务缓存淘汰风暴影响到限流计数。3. 令牌桶落在 Redis 上Spring Cloud Gateway 限流配置的完整拆解Spring Cloud Gateway 内置的 RequestRateLimiter 过滤器工厂默认使用 RedisRateLimiter 实现它基于令牌桶算法配合 Reactor 的限流算子把超限请求直接返回 429。使用它的前提是你已经引入了 spring-boot-starter-data-redis-reactive并且配置好了 Redis 连接。核心配置分成两部分。第一部分是定义 KeyResolver即如何区分不同的请求来源来做限流。比如按 IP 限流、按用户 ID 限流、按某个请求参数限流。我的项目里用的是组合维度优先按用户身份如果没登录则按 IP。这样既防止单个用户刷爆接口也能兜住匿名流量。下面是关键代码。Bean public KeyResolver userKeyResolver() { return exchange - { String userId exchange.getRequest().getHeaders().getFirst(X-User-Id); if (userId ! null !userId.isEmpty()) { return Mono.just(userId); } String ip exchange.getRequest().getRemoteAddress().getAddress().getHostAddress(); return Mono.just(IP: ip); }; }第二部分是配置具体的限流参数在 application.yml 里指定过滤器工厂以及对应参数。这里我用了一个自定义的限流 Key把请求路径和用户维度拼接实现针对不同接口的差异化限流策略。spring: cloud: gateway: routes: - id: order-service uri: lb://order-service predicates: - Path/api/order/** filters: - name: RequestRateLimiter args: key-resolver: #{userKeyResolver} redis-rate-limiter.replenishRate: 10 redis-rate-limiter.burstCapacity: 20 redis-rate-limiter.requestedTokens: 1这里几个参数的理解很关键。replenishRate 是令牌桶每秒补充的令牌数也就是平均允许的请求速率burstCapacity 是桶的最大容量代表突发流量下瞬间能放行的最大请求数requestedTokens 是每个请求消耗的令牌数通常保持默认的 1。如果设 burstCapacity 等于 replenishRate那就退化成严格平滑限流任何突发流量都会被拒绝。我项目里的经验是 burstCapacity 一般设为 replenishRate 的 1.5 到 2 倍比较合适具体数值要看下游服务的承受能力。这里有个很实际的坑RedisRateLimiter 在 Redis 里实际存的令牌数是一个小数而每次请求消耗的令牌数也是按 requestedTokens 计算的。如果 replenishRate 设置不当比如每秒钟补充的令牌数小于 1那么限流阈值以下也会出现间歇性拒绝。原因在于令牌补充的精度是按秒粒度计算的如果 replenishRate 是 0.5那每两秒才补一个令牌前一个请求把桶里令牌拿完后后续请求可能因为桶空而短暂被拒。遇到这种低频限流需求建议把单位换算成每秒多少令牌比如每分钟 30 个请求就配置成 replenishRate0.5但要在代码里做好容忍突发间隙的逻辑。还有一个经常被忽略的细节是RequestRateLimiter 内置的返回体是固定的只会返回一个 429 状态码加简单文本。如果你们的网关要对前端返回统一的 JSON 错误结构就必须自定义限流响应体。可以在过滤器工厂配置之外再加一个全局异常处理或者自定义过滤器捕获限流异常返回特定格式的错误信息。我这里是自定义了一个全局过滤器来处理限流拒绝场景下面是一个版本。Component public class RateLimitResponseFilter implements GlobalFilter, Ordered { Override public MonoVoid filter(ServerWebExchange exchange, GatewayFilterChain chain) { return chain.filter(exchange).then(Mono.fromRunnable(() - { // 这个回调写法不准确实际应在异常处理里做响应包装 })); } }上面这个代码块其实是我早期尝试的一个半成品后来我改成了更稳妥的方案直接写一个全局异常处理器捕获 ServerWebExchange 在过滤器链中抛出的限流相关异常把响应重置为 JSON。下面是我实际使用的方案用这种方式可以完全掌控响应结构。Component public class GatewayExceptionHandler implements ErrorWebExceptionHandler { private static final ObjectMapper MAPPER new ObjectMapper(); Override public MonoVoid handle(ServerWebExchange exchange, Throwable ex) { MapString, Object body new HashMap(); body.put(code, 429); body.put(message, 请求太频繁请稍后再试); byte[] bytes; try { bytes MAPPER.writeValueAsBytes(body); } catch (JsonProcessingException e) { bytes {\code\:429}.getBytes(StandardCharsets.UTF_8); } exchange.getResponse().setStatusCode(HttpStatus.TOO_MANY_REQUESTS); exchange.getResponse().getHeaders().setContentType(MediaType.APPLICATION_JSON); DataBuffer buffer exchange.getResponse().bufferFactory().wrap(bytes); return exchange.getResponse().writeWith(Mono.just(buffer)); } }需要注意这个处理器要生效必须在配置里注册成 Spring Bean并且优先级要低于默认的 DefaultErrorWebExceptionHandler否则会被默认异常处理器抢先接管。一个简单的做法是在启动类或配置类里显式声明这个 Bean同时关闭 Spring Boot 默认的 error 处理路径。项目里我们是直接把网关服务作为一个纯响应式服务几乎没有用到默认错误页面所以这样处理是完全可行的。关于限流参数调优我整理了不同业务场景下的参考配置见下面的表格业务场景replenishRateburstCapacity说明普通 GET 查询接口2040允许短时翻倍突发登录接口24严格限制防暴力破解订单提交接口58结合用户维度控制单个用户请求文件上传接口12大请求占资源限制必须谨慎这个表不是教条核心思路是根据接口对下游资源的消耗程度来定。对于查询类接口可以放宽一些对于写操作和认证接口则要收紧。配置修改后建议压测验证不要凭感觉调参。4. 从请求头拿 Token 到真正验签JWT 鉴权的完整链路JWT 在网关层的处理链路说白了就是请求进来网关从请求头里拿出 Token校验签名校验有效期把解析出来的用户身份放进转发给下游的请求头然后放行或拒绝。看起来简单但每一步都有容易被忽略的细节。先说 JWT 的结构。JWT 由三段组成Header、Payload、Signature。Header 里面声明了签名算法常见的有 HS256、RS256Payload 里面放了用户信息、过期时间等声明Signature 是对前两段做签名后的结果用 Base64URL 编码拼接。网关解析 JWT 时不需要访问认证中心这是它优于传统 Session 方案的核心点无状态、可水平扩展。我在项目里用的是非对称加密 RS256 的方式认证中心持有私钥签发 Token网关持有公钥做验签。这样即使网关被脱库攻击者也无法伪造 Token因为他拿不到私钥。这个设计与原来的 HS256 方案相比安全性要好很多。如果一开始就规划好建议直接上 RS256 或更新的 ES256别用对称密钥。对称方案一旦密钥泄露整个签发和校验体系就全废了。网关侧验签的整体思路可以用下面的流程来描述请求进来后先判断是否是白名单路径比如 /api/auth/login、/api/auth/refresh白名单直接放行非白名单路径必须从 Authorization 头里提取 Bearer Token取不到直接返回 401取到了先做签名校验再做过期时间校验最后把解析出来的用户 ID 和角色塞进请求头继续向后转发。下文给出一段关键过滤器代码。Component public class JwtAuthGlobalFilter implements GlobalFilter, Ordered { Autowired private JwtTokenProvider jwtTokenProvider; private static final ListString WHITE_LIST Arrays.asList(/api/auth/login, /api/auth/refresh); Override public MonoVoid filter(ServerWebExchange exchange, GatewayFilterChain chain) { String path exchange.getRequest().getURI().getPath(); if (WHITE_LIST.contains(path)) { return chain.filter(exchange); } String authHeader exchange.getRequest().getHeaders().getFirst(Authorization); if (authHeader null || !authHeader.startsWith(Bearer )) { exchange.getResponse().setStatusCode(HttpStatus.UNAUTHORIZED); return exchange.getResponse().setComplete(); } String token authHeader.substring(7); try { Claims claims jwtTokenProvider.parseToken(token); ServerHttpRequest mutatedRequest exchange.getRequest().mutate() .header(X-User-Id, claims.get(userId, String.class)) .header(X-User-Role, claims.get(role, String.class)) .build(); ServerWebExchange mutatedExchange exchange.mutate().request(mutatedRequest).build(); return chain.filter(mutatedExchange); } catch (Exception e) { exchange.getResponse().setStatusCode(HttpStatus.UNAUTHORIZED); return exchange.getResponse().setComplete(); } } Override public int getOrder() { return -100; } }这里有一个小的设计决策把 JWT 解析出来的信息放到内部请求头 X-User-Id、X-User-Role再转发给下游服务。为什么不用原始的 Authorization 头继续转发因为下游服务不应该也不需要再关心 Token 解析直接把用户身份信息明文放请求头里下游读取和校验的成本降到最低。但这里有个风险如果网关本身可以被外部直接访问那调用方也可以伪造 X-User-Id 请求头直接打网关。所以网关在转发前必须覆盖掉来自外部的这类请求头。实现的思路是在解析 Token 后 mutate 请求头时强制替换同名 Header而不是追加同时建议在全局过滤器中清理掉所有 X- 开头的用户身份 Header。第一个过滤器先把外部的 X-User-Id 等请求头全部删除经过 JWT 过滤器后再从 Token 中恢复正确的值。Override public MonoVoid filter(ServerWebExchange exchange, GatewayFilterChain chain) { ServerHttpRequest request exchange.getRequest().mutate() .headers(headers - { headers.remove(X-User-Id); headers.remove(X-User-Role); }) .build(); return chain.filter(exchange.mutate().request(request).build()); }这个清理动作我单独放在优先级更高的过滤器里确保任何外部请求携带的伪造身份头在进入 JWT 验证之前就被清除。这是我踩过真实的坑之后补上的有一次安全测试人员用 Postman 直接带了一个伪造的 X-User-Id 头请求业务接口发现业务服务其实并不校验这个头的真假正是因为网关转发时没有覆盖同名 Header导致伪造成功。这个漏洞的直接教训就是网关层做的所有身份注入必须保证外部无法绕过。5. 密钥管理才是鉴权最深的水从 HS256 到 RS256 的迁移经历JWT 鉴权写代码不难真正难在密钥管理。我一开始做网关鉴权的时候图省事直接用了 HS256 对称加密把密钥写死在网关和认证中心的配置文件里当时觉得反正两边都是内网泄露风险不高。后来安全评审的时候被指出问题使用对称密钥意味着签名和验签用同一个密钥任何持有该密钥的一方都可以签发任意身份的 Token一旦密钥泄露整个认证体系等于形同虚设。更麻烦的是密钥轮换的时候认证中心和网关必须同步更新漏了一个节点就会导致大面积验签失败。后来我把方案迁移到了 RS256 非对称加密认证中心用私钥签发网关用公钥验签。这带来的直接好处是网关侧即使被攻破攻击者拿到的公钥也无法伪造 Token因为他们没有私钥。密钥管理从必须保护好一个秘密变成了必须保管好私钥公钥随便散播。私钥放在认证中心内部可以配合密钥管理系统做定期轮换和审计。在真正的分布式场景下密钥轮换是个绕不开的问题。如果你把公钥硬编码在网关配置里那么每次轮换都要重新发布一次网关服务这在生产环境是不可接受的。我采用的方案是网关启动时从配置中心拉取一次公钥同时定时任务每隔一定时间重新拉取如果公钥内容发生了变化则更新内存中的公钥对象。实际上业界更标准的做法是 JWKSJSON Web Key Set认证中心暴露一个 /jwks 接口返回公钥集合网关通过定时轮询该接口来自动感知密钥变化。我给网关写了一个公钥刷新组件核心逻辑是本地缓存一个当前使用的 RSA PublicKey 对象后台任务每 30 秒调用一次远程 JWKS 接口获取当前公钥指纹如果指纹和本地不一致就更新本地公钥。这样就实现了不停机完成密钥轮换。这里要提醒一点引入公钥自动刷新之后一定要处理密钥轮换的时序问题。比如认证中心已经用新私钥签发 Token 了但网关还没拉到新公钥那这段时间所有新签发的 Token 都会被判定为验签失败。我当时的做法是网关内存里同时保存旧公钥和新公钥两份验签时先用新公钥试失败再用旧公钥试。这样在轮换窗口期内新旧 Token 都还能通过验证等窗口期过了再清除旧公钥。这个小机制投入产出比极高为后续的平滑轮换打下了基础。JWT 的过期时间和续期策略也值得展开说说。最常见的设计是短期 Access Token 加长期 Refresh Token。Access Token 有效期我一般设置为 15 到 30 分钟Refresh Token 可以设置到 7 天甚至更久。网关只校验 Access Token 的有效性Refresh Token 只用于调用刷新接口换取新的 Access Token。为什么要这么设计因为 JWT 一旦签发在过期之前的有效期内是无法主动作废的Token 有效期越长泄露后的风险窗口越大。短 Token 加刷新机制能把风险窗口压到 15 分钟以内。关于 Token 黑名单它解决的是主动失效的问题。比如用户修改密码或退出登录后旧 Token 虽然没过期但必须立即作废。网关在这里可以配合 Redis 做一层黑名单校验Redis 中维护一个 Set存放被注销 Token 的 jtiJWT ID网关每次验签成功后额外查一次黑名单命中则拒绝。这个方案虽然打破了一点 JWT 无状态的纯粹性但实现了精准的到期前回收能力对于安全要求较高的系统很有必要。我现在的项目中就同时保留了短有效期和黑名单机制常规接口只有 15 分钟的有效期黑名单只应对少数极端场景成本完全可控。6. 限流的坑与对策误伤、穿透、Redis 故障的应急预案限流配置上线后并不意味着一劳永逸。我把限流相关的高频故障场景列出来这些几乎都是我在实际项目中遇到的如果你也在接网关限流建议直接避坑。第一个坑是限流误伤。这个最容易发生某个活动上线前端脚本发起了大量并发请求结果不只这个接口被限流同一个用户维度的其他接口也全被牵连拒绝。原因在于 KeyResolver 太粗所有接口共用一个 key 空间。我后来调整为接口路径 用户维度组合 Key每个接口独立计量互不干扰。这个调整要讲清楚否则就会出现登录接口没超限但订单接口已经被限流这种诡异现象。第二个坑是限流穿透。单机版限流可以用 Guava RateLimiter但微服务网关一般都是多实例部署这时单机限流就失去意义因为流量会分散到多台实例上单机阈值乘以实例数才是系统真实处理能力。如果各实例独立限流一台机器被压垮之前不会被限流保护其他机器因为负载均衡算法分到的流量也参差不齐。必须把令牌桶状态放在 Redis 这类共享存储上才能实现集群级别的精确限流。这个道理我是在一次多实例压测时得到的教训单机限流 500 QPS三台实例压测发现实际总吞吐能到 1200 左右才触发边缘限流中间有一台机器已经 CPU 100% 了其他两台还没怎么过载。第三个坑是 Redis 故障。限流使用的 Redis 挂了默认情况下 Spring Cloud Gateway 的 RequestRateLimiter 会直接放行请求这在大部分业务场景里是一个合理的降级策略宁可让流量进来也不能因为限流组件故障导致整个网关不可用。但这会带来一个后果限流保护在 Redis 故障期间完全失效。如果你的系统高度依赖限流保护可以在运维侧对限流 Redis 做高可用部署或者配置降级开关——当 Redis 不可用时切换到内存限流保证基本的单机保护能力。第四个坑是响应状态码的语义不统一。Spring Cloud Gateway 默认限流返回 429但有些老的前端项目只处理 200 和 500遇到 429 直接弹出一个莫名其妙的错误页面。这时候需要前端配合改造同时也应该在网关自定义的限流响应中把 Retry-After 头带上告诉客户端多久之后可以重试。这个小细节能让前端的重试逻辑做得更友好。还有一个隐蔽的问题限流阈值看起来合理但因为请求在网关层的耗时波动导致实际下游收到的瞬时请求量远高于配置的阈值。原因是 RedisRateLimiter 的检查是令牌桶模型如果某段时间补充的令牌没被用掉桶会提前攒满后续一旦流量突然涌入可以瞬间消耗掉桶里积攒的所有令牌。这不是 bug而是令牌桶的预期行为。如果业务不能接受这种突刺可以把 burstCapacity 调小到接近 replenishRate牺牲一点突发能力换取平滑性。我在配置订单服务时甚至直接把 burstCapacity 设为和 replenishRate 一样数字上等于完全禁止突发订单接口的流量曲线会非常平滑虽然峰值低了些但下游数据库的抖动问题确实好转了。7. 网关性能余量压测数据、响应延迟和最容易被忽视的线程模型最后想把网关自身的性能边界讲透。Spring Cloud Gateway 因为是响应式模型它不像 Tomcat 那样每个请求占一个线程而是在少量线程上通过事件循环处理大量请求。这个模型的直接好处是高并发下内存占用低、上下文切换少但它有个反直觉的特点业务代码里如果出现任何阻塞方法——比如在过滤器里调用了同步的 JDBC 操作或者用了 Thread.sleep就会把整个事件循环线程堵住导致网关整体吞吐大幅下降。在压测时我亲眼见过一个案例过滤器中加了一行同步的 Redis 读取逻辑QPS 从 3000 掉到 800 左右原因就是那次同步读取把 Netty 的 event loop 线程死死卡住。所以网关过滤器里的任何操作都要写成响应式或异步的比如用 ReactiveRedisTemplate 而不是 RedisTemplate用 WebClient 而不是 RestTemplate。这条原则应该刻在脑子里。再给出一个真实参考数据。我们的网关服务部署在两台 4C8G 的容器上限流加 JWT 验签全开的情况下单实例稳定压测到 3500 QPSP99 延迟在 45ms 左右。如果不做任何过滤逻辑裸转发的单实例极限大约在 5000 QPS 上下。也就是说鉴权和限流逻辑大概吃掉三成左右的性能余量。这个数据说明网关层加横切逻辑不是没有代价的但只要控制在合理范围对整体架构带来的治理价值远大于这点性能损耗。关于是否需要在网关层对响应体做缓存或压缩我的建议是不要过度设计。网关的核心是路由、安全、流控把太多的业务逻辑塞进来会让它变得臃肿。我之前见过有人把数据脱敏规则都写在网关里结果网关成了全世界最难维护的组件任何改动都不敢动因为影响面太大了。保持网关的逻辑纯粹、简单才是它能长期稳定运行的保障。最后分享一个我在限流参数调优上的小技巧上线初期把限流阈值设置为预估峰值的 60% 到 70%先保证系统绝对安全观察一周的线上日志结合真实流量曲线再逐步放宽。很多人一上来就按理论峰值去配置上限结果被突发流量一波打穿。限流参数和数据缓冲池一样应该从小往大调而不是一次性给足。