Spring Cloud Gateway基础复习

发布于:2025-09-14 ⋅ 阅读:(17) ⋅ 点赞:(0)

诞生背景

        随着微服务架构的兴起,传统单体应用被拆分为多个小型、独立部署的微服务,每个服务专注于特定功能。这虽然提高了灵活性和可扩展性,但也带来了服务间通信、安全、监控等挑战。

        为了解决微服务架构的痛点(客户端代码负责/每个服务要重复鉴权,限流,日志等),API网关应运而生。


API网关的作用

  • 请求代理和路由转发
  • 访问认证与鉴权
  • 运维检测,数据加密与安全管控
  • 日志记录与应用审计
  • 限流与熔断
  • 协议转换与格式标准化
  • 支持灰度发布与A/B测试
  • 缓存加速

通过上述功能,API 网关成为微服务架构中不可或缺的流量中枢,平衡了性能、安全与可维护性


常见的API网关对比

场景 推荐方案 理由
传统单体/简单微服务 Nginx 高性能、轻量级,满足基础需求。
Spring Cloud微服务 Spring Cloud Gateway 生态融合性好,性能优异,支持动态路由和安全集成。
企业级多API管理 Kong 高可用、插件丰富,适合复杂安全策略和可视化管理。
云原生动态流量管理 APISIX 动态配置、多语言支持,与Kubernetes和Service Mesh无缝集成。

GateWay核心概念

Route路由:是一个包含了请求的匹配规则和路由的目标等相关信息的集合

由以下四部分组成:

  • ID:唯一标识
  • URI:目标服务地址
  • Predicates(断言):匹配条件
  • Filters(过滤器)

断言:定义在某一个路由下,代表了请求是否匹配当前路由的判断规则,且gateway内置了多种断言规则。基于Java 8 的Predicate接口,支持以下内置匹配规则:

  • Path:路径匹配(例如 /api/**)
  • Method:HTTP 方法匹配(如 GET /POST)
  • Header:请求头匹配(如 X-Token = 123)
  • Query:查询参数匹配(如 name = xxx)
  • Cookie:Cookie匹配(如 JSEESIONID = xxx)

过滤器:请求成功匹配某路由之后,在被发送到目标对象取之前响应回到gateway之后可以执行一些列过滤器。(对请求和响应进行拦截),分为两类:

  • GatewayFilter:局部过滤器,作用于单个路由
  • GlobalFilter:全局过滤器,作用于所有请求

工作流程:
请求到达网关 → 匹配断言 → 执行前置过滤器→ 路由转发 → 执行后置过滤器→ 返回响应


断言的配置与使用

路径匹配断言

spring:

        cloud:

                gateway:

                        routes:

                              - id: user_service

                                uri: lb://user-service

                                predicates:

                                        - Path=/api/user/**  #匹配所有以/api/user开头的请求  

方法匹配断言

predicates:

        - Method=POST #匹配 POST 请求

查询参数断言

predicates:

        - Query=name,John.*  #匹配参数name以John开头 支持正则表达式

Header断言

predicates:

        -Header=X-Token,Bearer\s\w+ # 匹配请求头X-Token 符合Bearer令牌格式

Cookie断言

predicates:

        - Cookie=sessionId,\d+ # Cookie sessionId为数字

时间范围断言

匹配请求时间在指定区间内

predicates:
  - Between=2025-01-01T00:00:00+08:00,2025-12-31T23:59:59+08:00

IP地址断言

predicates:
  - RemoteAddr=192.168.1.0/24  # 仅允许内网 IP

权重路由断言

可以实现灰度发布功能

routes:
  - id: service_v1
    uri: lb://service-v1
    predicates:
      - Weight=group1,80  # 80% 流量到 v1
  - id: service_v2
    uri: lb://service-v2
    predicates:
      - Weight=group1,20  # 20% 流量到 v2

断言之间可以互相组合

过滤器的配置与使用

局部过滤器

需要在路由里面显示配置,仅对当前路由生效

(1)添加请求头 AddRequestHeader

filters:

        - AddRequestHeader=X-Request-Id,12345 #添加请求头

(2)移除路径前缀 StripPrefix

filters:

        - StripPrefix=1 (如 /api/user → /user)

(3)限流过滤器 RequestRateLimiter

基于 Redis 实现令牌桶限流

filters:
  - name: RequestRateLimiter
    args:
      redis-rate-limiter.replenishRate: 10  # 每秒令牌数
      redis-rate-limiter.burstCapacity: 20  # 桶容量
      key-resolver: "#{@apiKeyResolver}"    # 自定义 Key 解析器

@Bean
public KeyResolver apiKeyResolver() {
    return exchange -> {
        String path = exchange.getRequest().getPath().toString();
        return Mono.just(path); // 按路径限流
    };
}

(4)重写路径 RewritePath

filters:
  - RewritePath=/api/v1/(?<segment>.*), /api/${segment}  # 重写路径格式

(5)添加响应头 AddResponseHeader

filters:
  - AddResponseHeader=X-Response-Time,200ms  # 添加响应头

全局过滤器 GlobalFilter

一般用于实现鉴权和日志功能,无需在配置文件中配置

(1)实现鉴权

@Component
@Order(-1) // 优先级最高 越小越高
public class AuthFilter implements GlobalFilter {
    @Override
    public Mono<Void> filter(ServerWebExchange exchange, GatewayFilterChain chain) {
        // 获取 token
        String token = exchange.getRequest().getHeaders().getFirst("Authorization");
        // token验证通过就放行
        if ("Bearer valid-token".equals(token)) {
            return chain.filter(exchange);
        }
        // 否则设置响应码后立即返回响应
        exchange.getResponse().setStatusCode(HttpStatus.UNAUTHORIZED);
        return exchange.getResponse().setComplete();
    }
}

(2)日志过滤器

@Component
@Order(0)
public class LoggingFilter implements GlobalFilter {
    @Override
    public Mono<Void> filter(ServerWebExchange exchange, GatewayFilterChain chain) {
        log.info("Request Path: {}", exchange.getRequest().getPath());
        return chain.filter(exchange);
    }
}

路由配置案例

spring:
  cloud:
    gateway:
      routes:
        # 路由1:用户服务路由
        - id: user_service  # 路由唯一标识
          uri: lb://user-service  # 负载均衡到 user-service 服务
          predicates:  # 断言条件(必须全部满足)
            - Path=/api/user/**  # 匹配路径以 /api/user 开头的请求(PRE阶段)
            - Method=GET  # 仅匹配 GET 请求(PRE阶段)
            - Header=X-Token,Bearer\s\w+  # 请求头必须包含 X-Token 且值为 Bearer 开头的字符串(PRE阶段)
          filters:  # 过滤器链(按顺序执行)
            - StripPrefix=1  # 移除路径的第一级前缀(PRE阶段)
              # 示例:/api/user/info → /user/info
            - AddRequestHeader=X-Request-Id,${random.uuid}  # 添加请求头(PRE阶段)
              # 生成随机 UUID 作为请求 ID
            - name: RequestRateLimiter  # 限流过滤器(PRE阶段)
              args:
                redis-rate-limiter.replenishRate: 5  # 每秒补充5个令牌
                redis-rate-limiter.burstCapacity: 10  # 令牌桶容量为10
                key-resolver: "#{@userKeyResolver}"  # 使用自定义的 Key 解析器(如按用户ID限流)

        # 路由2:订单服务路由
        - id: order_service  # 路由唯一标识
          uri: lb://order-service  # 负载均衡到 order-service 服务
          predicates:  # 断言条件
            - Path=/api/order/**  # 匹配路径以 /api/order 开头的请求(PRE阶段)
            - Between=2025-01-01T00:00:00+08:00,2025-12-31T23:59:59+08:00  # 仅在2025年期间生效(PRE阶段)
          filters:  # 过滤器链
            - RewritePath=/api/order/(?<segment>.*), /api/${segment}  # 路径重写(PRE阶段)
              # 示例:/api/order/123 → /api/123
            - AddResponseHeader=X-Cache,HIT  # 添加响应头(POST阶段)
              # 在响应中添加 X-Cache: HIT 头