后端服务限流配置：Nginx与Spring Cloud Gateway实战对比
引言
最近在线上排查问题时发现一个服务接口由于突发流量导致响应变慢，最终影响了整体服务可用性。这让我意识到限流配置的重要性，今天我们就来深入探讨两种常见的限流方案：Nginx和Spring Cloud Gateway的实现方式与对比选择。
一、Nginx限流配置实战
Nginx作为高性能的反向代理服务器，其限流功能是基于漏桶算法实现的，配置简单但效果显著。
```nginx
http {
limit_req_zone $binary_remote_addr zone=mylimit:10m rate=10r/s;
server {
location /api/ {
limit_req zone=mylimit burst=20 nodelay;
proxy_pass http://backend;
}
}
}
```
这里有几个关键参数：
-
`limit_req_zone` 定义限流区域，`10m`表示共享内存大小
-
`rate=10r/s` 表示每秒10个请求的限制
-
`burst=20` 允许突发20个请求
-
`nodelay` 表示不延迟处理超出的请求，直接返回503
这种配置适合入口级别的全局限流，能有效防止单IP的恶意请求。
二、Spring Cloud Gateway限流实现
Spring Cloud Gateway作为微服务API网关，内置了基于Redis的分布式限流功能。首先添加依赖：
```xml
<dependency>
<groupId>org.springframework.cloud</groupId>
<artifactId>spring-cloud-starter-gateway</artifactId>
</dependency>
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-data-redis-reactive</artifactId>
</dependency>
```
然后是配置示例：
```yaml
spring:
redis:
host: localhost
cloud:
gateway:
routes:
- id: user-service
predicates:
- Path=/api/users/**
filters:
- name: RequestRateLimiter
args:
redis-rate-limiter.replenishRate: 10
redis-rate-limiter.burstCapacity: 20
key-resolver: "{@userKeyResolver}"
```
还需要定义一个KeyResolver bean：
```java
@Bean
KeyResolver userKeyResolver() {
return exchange -> Mono.just(
exchange.getRequest().getRemoteAddress().getAddress().getHostAddress()
);
}
```
三、两种方案的对比选型
在实际项目中如何选择呢？我做了一个简单对比表：
| 特性 | Nginx | Spring Cloud Gateway |
|---------------------|--------------------------|-----------------------------|
| 算法实现 | 漏桶算法 | 令牌桶算法 |
| 分布式支持 | 单机 | 支持(需Redis) |
| 配置复杂度 | 简单 | 复杂 |
| 细粒度控制 | 较粗 | 细粒度(可按用户、API等) |
| 性能影响 | 极小 | 中等(需Redis交互) |
| 学习曲线 | 低 | 高 |
我的实践经验是：在API网关层用Nginx做入口级限流，在微服务内部用Gateway做细粒度控制，两者组合使用效果最佳。
结语
限流是保障系统稳定性的重要手段，但要注意合理的阈值设置。建议先通过日志分析历史峰值，然后设置略高于均值的限制值，并配合监控告警持续优化。你在项目中是如何配置限流的？欢迎在评论区分享你的实战经验！