gateway中的限流与熔断
目录
1. 限流的使用场景
2. gateway限流实现
2.1 前提：
2.2 导入依赖包
2.3 在项目配置文件中配置redis
2.4 开发限流需要的Bean
2.5 为服务配置限流参数
2.6 压力测试
3. 熔断
3.1 熔断的使用场景
3.2 熔断配置
1. 限流的使用场景
- 为什么限流
限流就是限制流量，因为服务器能处理的请求数有限，如果请求量特别大，我们需要做限流（要么就让请求等待，要么就把请求给扔了）， 限流可以保障我们的 API 服务对所有用户的可用性，也可以防止网络攻击。在高并发的应用中，限流是一个绕不开的话题。
2）常见限流方式
一般开发高并发系统常见的限流有：限制总并发数（比如数据库连接池、线程池）、限制瞬时并发数（如 nginx 的 limit_conn 模块，用来限制瞬时并发连接数）、限制时间窗口内的平均速率（如 Guava 的 RateLimiter、nginx 的 limit_req 模块，限制每秒的平均速率）；其他还有如限制远程接口调用速率、限制 MQ 的消费速率。另外还可以根据网络连接数、网络流量、CPU 或内存负载等来限流。
本文讨论在gateway集成的实现
3）限流算法：
-
漏桶算法(Leaky Bucket)
思路: 水(请求)先进入到漏桶里,漏桶以一定的速度出水(接口有响应速率),当水流入速度过大会直接溢出(访问频率超过接口响应速率),然后就拒绝请求,可以看出漏桶算法能强行限制数据的传输速率.示意图如下:
-
令牌桶算法(Token Bucket)
随着时间流逝，系统会按恒定 1/QPS 时间间隔（如果 QPS=100，则间隔是 10ms）往桶里加入 Token（想象和漏洞漏水相反，有个水龙头在不断的加水），如果桶已经满了就不再加了。新请求来临时，会各自拿走一个 Token，如果没有 Token 可拿了就阻塞或者拒绝服务.
2. gateway限流实现
2.1 前提：
先装好redis服务
2.2 导入依赖包
org.springframework.cloud
spring-cloud-starter-gateway
com.alibaba.cloud
spring-cloud-starter-alibaba-nacos-discovery
org.springframework.boot
spring-boot-starter-data-redis-reactive
com.alibaba.nacos
nacos-client
com.alibaba
fastjson
1.2.73
org.projectlombok
lombok
1.18.16
provided
org.springframework.boot
spring-boot-starter-test
test
org.junit.vintage
junit-vintage-engine
2.3 在项目配置文件中配置redis
---========-----
spring:
application:
name: service-gateway
cloud:
nacos:
discovery:
server-addr: 127.0.0.1:8848
gateway:
discovery:
locator:
#开启服务发现功能，从注册中心获取服务列表，（nacos->服务管理->服务列表）
#默认服务名称需要为大写，可以通过配置lower-case-service-id: true 改变这一规则
enabled: false
#配置服务名使用小写
lower-case-service-id: true
#配置redis
redis:
host: 192.168.229.128
port: 6379
database: 0
#password: 123456
redis的在gateway限流中起到存放令牌的作用
2.4 开发限流需要的Bean
具体实现：
/**
* 请求限流配置
*/
@Configuration
public class RequestRateLimiterConfig {
/**
* 按IP来限流
*/
@Bean
public KeyResolver ipAddrKeyResolver() {//JDK8的新特性——Lambda表达式
return exchange -> Mono.just(exchange.getRequest().getRemoteAddress().getAddress().getHostAddress());
}
///**
// * 按用户限流
// */
//@Bean
//KeyResolver userKeyResolver() {
// return exchange -> Mono.just(exchange.getRequest().getQueryParams().getFirst("user"));
//}
///**
// * 按URL限流,即以每秒内请求数按URL分组统计，超出限流的url请求都将返回429状态
// *
// * @return
// */
//@Bean
//@Primary
//KeyResolver apiKeyResolver() {
// return exchange -> Mono.just(exchange.getRequest().getPath().toString());
//}
}
2.5 为服务配置限流参数
修改网关中的路由配置文件，加入限流参数：
--======--
原配置：
[
{
"id": "service-consumer",
"predicates": [
{
"name": "Path",
"args": {
"_genkey_0": "/consumer/**"
}
}
],
"filters": [
{
"name": "StripPrefix",
"args": {
"_genkey_0": "1"
}
}
],
"uri": "lb://service-consumer",
"order": 0
}
]
加入限流配置（配置示例，请按自己的实际情况配置）：
[
{
"id": "service-consumer",
"predicates": [
{
"name": "Path",
"args": {
"_genkey_0": "/consumer/**"
}
}
],
"filters": [
{
"name": "StripPrefix",
"args": {
"_genkey_0": "1"
}
},
{
"name": "RequestRateLimiter",
"args": {
"key-resolver": "#{@ipAddrKeyResolver}",
"redis-rate-limiter.replenishRate": "10",
"redis-rate-limiter.burstCapacity": "20"
}
}
],
"uri": "lb://service-consumer",
"order": 0
}
]
- filter名称必须是RequestRateLimiter
- redis-rate-limiter.replenishRate：允许用户每秒处理多少个请求
- redis-rate-limiter.burstCapacity：令牌桶的容量，允许在一秒钟内完成的最大请求数
- key-resolver：使用SpEL按名称引用bean
2.6 压力测试
1）配置postman
2）运行测试
3）在没有加入限流的情况下的测试结果
4）在加入限流之后的测试情况：
3. 熔断
3.1 熔断的使用场景
网关是所有请求的入口，如果部分后端服务延时严重，则可能导致大量请求堆积在网关上，拖垮网关进而瘫痪整个系统。这就需要对响应慢的服务做超时快速失败处理，即熔断。
常用的熔断组件：Hystrix与Sentinel，本课程以Hystrix讲述。
3.2 熔断配置
1）导入依赖
org.springframework.cloud
spring-cloud-starter-netflix-hystrix
2）编写熔断时的处理类
@RestController
public class FallBackController {
@GetMapping("/fallback")
public String fallback() {
return "服务熔断 ...... ";
}
}
3）为服务配置熔断
[
{
"id": "service-consumer",
"predicates": [
{
"name": "Path",
"args": {
"_genkey_0": "/consumer/**"
}
}
],
"filters": [
{
"name": "StripPrefix",
"args": {
"_genkey_0": "1"
}
},
{
"name": "RequestRateLimiter",
"args": {
"key-resolver": "#{@ipAddrKeyResolver}",
"redis-rate-limiter.replenishRate": "10",
"redis-rate-limiter.burstCapacity": "20"
}
},
{
"name": "Hystrix",
"args": {
"name": "fallback"
"fallbackUri": "forward:/fallback"
}
}
],
"uri": "lb://service-consumer",
"order": 0
}
]
4） 启动服务，测试
-- == --
调用接口测试：
听到consumer服务，再次调用：
5）配置熔断后，第一次请求容器超时问题
Spring Cloud项目启动后，首次使用 FeignClient 请求往往会消耗大量时间，并有一定概率因此导致请求超时(java.net.SocketTimeoutException: Read timed out)，因而有可能会触发熔断，这是由于在调用其他微服务接口前，会去请求该微服务的相关信息(地址、端口等)，并做一些初始化操作，由于默认的懒加载特性，导致了在第一次调用时，出现超时的情况。
解决方法：
- 第一种办法是设置超时时间，具体设置成多少，因项目而异，配置如下
#hystrix调用方法的超时时间，默认是1000毫秒
hystrix.command.default.execution.isolation.thread.timeoutInMilliseconds=5000
不推荐，容易导致有些服务已经不可用，但不用及时有效的熔断。
- 配置ribbon立即加载
服务之间的调用顺序为：gateway->消费者->生产者
接下来分两部分解决这个问题，一是服务之间调用Ribbon的饥饿加载，对应上面的测试为消费者调用生产者；二是网关的饥饿加载
消费者服务：
ribbon:
eager-load:
enabled: true #启用立即加载
clients: service-provider #配置立即加载的服务名
网关：
ribbon:
eager-load:
enabled: true
clients: service-consumer