目录
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 导入依赖包
<dependencies>
<!-- gateway网关 -->
<dependency>
<groupId>org.springframework.cloud</groupId>
<artifactId>spring-cloud-starter-gateway</artifactId>
</dependency>
<!-- 从注册中心进行服务发现 -->
<dependency>
<groupId>com.alibaba.cloud</groupId>
<artifactId>spring-cloud-starter-alibaba-nacos-discovery</artifactId>
</dependency>
<!-- 限流需要的redis依赖 -->
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-data-redis-reactive</artifactId>
</dependency>
<!-- 向注册中心进行服务注册 -->
<dependency>
<groupId>com.alibaba.nacos</groupId>
<artifactId>nacos-client</artifactId>
</dependency>
<!--处理json的工具包-->
<dependency>
<groupId>com.alibaba</groupId>
<artifactId>fastjson</artifactId>
<version>1.2.73</version>
</dependency>
<!-- https://mvnrepository.com/artifact/org.projectlombok/lombok -->
<dependency>
<groupId>org.projectlombok</groupId>
<artifactId>lombok</artifactId>
<version>1.18.16</version>
<scope>provided</scope>
</dependency>
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-test</artifactId>
<scope>test</scope>
<exclusions>
<exclusion>
<groupId>org.junit.vintage</groupId>
<artifactId>junit-vintage-engine</artifactId>
</exclusion>
</exclusions>
</dependency>
</dependencies>
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)导入依赖
<dependency>
<groupId>org.springframework.cloud</groupId>
<artifactId>spring-cloud-starter-netflix-hystrix</artifactId>
</dependency>
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