Spring Cloud Gateway基础复习

诞生背景

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

        为了解决微服务架构的痛点（客户端代码负责/每个服务要重复鉴权，限流，日志等），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 {@Overridepublic Mono<Void> filter(ServerWebExchange exchange, GatewayFilterChain chain) {// 获取 tokenString 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 {@Overridepublic 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 头