微服务API网关设计：限流熔断与统一鉴权的实战方案

微服务为什么需要API网关

微服务架构将单体应用拆分为多个独立服务后，客户端面临服务地址分散、认证逻辑重复、流量管控缺失等问题。API网关作为所有外部请求的统一入口，承担请求路由、认证鉴权、限流熔断、协议转换等横切关注点。后端开发中引入API网关，可以将业务服务从非功能性需求中解耦，让服务治理的规则集中在网关层统一执行。

API网关的核心功能模块

一个完整的API网关设计包含以下功能模块：

请求路由：根据URL路径、HTTP方法、请求头等条件将请求转发到后端服务。路由配置支持路径参数和正则匹配，实现灵活的请求分发。

认证鉴权：统一处理JWT验证、OAuth2 Token校验、API Key认证等鉴权逻辑，验证通过的请求携带用户上下文转发到后端服务，避免每个服务重复实现认证代码。

限流控制：基于令牌桶或滑动窗口算法，对API接口按用户、IP、服务维度进行速率限制，防止突发流量击穿后端服务。

熔断降级：当后端服务错误率或延迟超过阈值时，自动切断请求链路，返回降级响应，避免级联故障扩散。

协议转换：外部HTTP请求转换为内部gRPC调用，或将RESTful API映射到GraphQL接口，屏蔽内部协议差异。

基于Spring Cloud Gateway的实现

Spring Cloud Gateway是Java微服务生态中使用最广泛的API网关实现。以下是一个包含限流和鉴权的配置示例：

“`yaml
# application.yml
spring:
cloud:
gateway:
routes:
– id: user-service
uri: lb://user-service
predicates:
– Path=/api/users/**
filters:
– name: RequestRateLimiter
args:
redis-rate-limiter.replenishRate: 100
redis-rate-limiter.burstCapacity: 200
key-resolver: “#{@userKeyResolver}”
– name: JwtAuth
args:
secret: ${JWT_SECRET}
excludedPaths: /api/users/login,/api/users/register

globalcors:
cors-configurations:
‘[/**]’:
allowedOrigins: “https://app.example.com”
allowedMethods: “*”
maxAge: 3600
“`

限流配置使用Redis令牌桶算法，replenishRate为每秒补充的令牌数，burstCapacity为桶容量。key-resolver定义限流维度，@userKeyResolver按用户ID限流。

自定义JWT鉴权过滤器：

“`java
@Component
public class JwtAuthFilter implements GlobalFilter, Ordered {

@Value(“${jwt.secret}”)
private String secret;

@Override
public Mono filter(ServerWebExchange exchange, GatewayFilterChain chain) {
String path = exchange.getRequest().getPath().value();

// 白名单路径跳过鉴权
if (isExcluded(path)) {
return chain.filter(exchange);
}

String token = extractToken(exchange.getRequest());
if (token == null || !validateToken(token)) {
exchange.getResponse().setStatusCode(HttpStatus.UNAUTHORIZED);
return exchange.getResponse().setComplete();
}

// 将用户信息注入请求头，传递给下游服务
Claims claims = parseToken(token);
ServerHttpRequest request = exchange.getRequest().mutate()
.header(“X-User-Id”, claims.getSubject())
.header(“X-User-Role”, claims.get(“role”, String.class))
.build();
return chain.filter(exchange.mutate().request(request).build());
}

@Override
public int getOrder() { return -1; }
}
“`

限流算法的选择与实现

微服务API网关常用的限流算法有三种：

固定窗口：简单但存在窗口边界处的流量突刺问题。适合精度要求不高的场景。

滑动窗口：将时间窗口细分为多个小格，平滑了边界效应。Redis的INCR+EXPIRE组合可以实现滑动窗口限流。

令牌桶：允许短时突发流量，同时保证长期平均速率。Spring Cloud Gateway默认使用Redis令牌桶实现。对于不依赖Redis的场景，可用Guava RateLimiter实现单机令牌桶。

高并发设计中的限流配置需要根据业务场景区分等级：核心交易接口限流阈值设置宽松，确保正常交易不误杀；查询类接口限流阈值设置严格，防止批量查询拖垮数据库。

熔断降级与Sentinel集成

熔断器的状态机包含三个状态：Closed（正常放行）、Open（熔断拒绝）、Half-Open（试探放行）。当错误率超过阈值时从Closed切换到Open，经过冷却期后进入Half-Open试探恢复。

“`java
// Sentinel熔断规则配置
DegradeRule rule = new DegradeRule();
rule.setResource(“order-service”);
rule.setGrade(CircuitBreakerStrategy.ERROR_RATIO.getType());
rule.setCount(0.5); // 错误率阈值50%
rule.setTimeWindow(30); // 熔断时长30秒
rule.setMinRequestAmount(10); // 最小请求数
rule.setStatIntervalMs(10000); // 统计时间窗口10秒

DegradeRuleManager.loadRules(Collections.singletonList(rule));
“`

熔断降级需要配套降级逻辑：返回缓存数据、返回兜底默认值、返回排队提示。降级策略根据业务场景选择，交易类服务不能返回脏数据，查询类服务可以接受短时的缓存过期。

API网关的性能与高可用

API网关作为单点入口，其自身的高可用至关重要。部署层面至少两个实例，前端用Nginx或云负载均衡做四层/七层分发。消息中间件可以做异步解耦：网关将请求写入消息队列，后端服务消费处理，适合耗时操作。API接口规范要求网关统一返回格式，包含code、message、data三个字段，便于客户端统一处理错误。服务治理层面，网关与服务注册中心（Nacos/Consul）集成，实时感知服务实例的上下线变化，避免将请求路由到不可用的实例。微服务架构中API网关的性能基线：单实例QPS应达到5000以上（简单路由+鉴权场景），P99延迟低于10ms。