微服务系统中熔断限流环节,对保护系统的稳定性起到了很大的作用,作为网关,Spring Cloud Gateway也提供了很好的支持。先来理解下熔断限流概念:
熔断降级
:在分布式系统中,网关作为流量的入口,大量请求进入网关,向后端远程系统或服务发起调用,后端服务不可避免的会产生调用失败(超时或者异常),失败时不能让请求堆积在网关上,需要快速失败并返回回去,这就需要在网关上做熔断、降级操作。限流
:网关上有大量请求,对指定服务进行限流,可以很大程度上提高服务的可用性与稳定性,限流的目的是通过对并发访问/请求进行限速,或对一个时间窗口内的请求进行限速来保护系统。一旦达到限制速率则可以拒绝服务、排队或等待、降级。
下文就网关如何进行超时熔断、异常熔断和访问限流进行示例说明。示例包含两个模块项目,一个为网关项目gateway
,一个为下游业务项目downstream
。
超时异常熔断
构建网关目:
pom.xml
<dependencyManagement>
<dependencies>
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-dependencies</artifactId>
<version>${spring.boot.version}</version>
<type>pom</type>
<scope>import</scope>
</dependency>
<dependency>
<groupId>org.springframework.cloud</groupId>
<artifactId>spring-cloud-dependencies</artifactId>
<version>${spring.cloud.version}</version>
<type>pom</type>
<scope>import</scope>
</dependency>
<dependency>
<groupId>io.spring.platform</groupId>
<artifactId>platform-bom</artifactId>
<version>${spring.platform.version}</version>
<type>pom</type>
<scope>import</scope>
</dependency>
</dependencies>
</dependencyManagement>
<dependencies>
<dependency>
<groupId>org.springframework.cloud</groupId>
<artifactId>spring-cloud-starter-gateway</artifactId>
</dependency>
<dependency>
<groupId>org.springframework.cloud</groupId>
<artifactId>spring-cloud-starter-netflix-hystrix</artifactId>
</dependency>
</dependencies>
application.yml
server:
port: 8089
spring:
application:
name: spring-cloud-gateway
cloud:
gateway:
routes:
- id: service_customer
#下游服务地址
uri: http://127.0.0.1:8083/
order: 0
#网关断言匹配
predicates:
- Path=/gateway/**
filters:
#熔断过滤器
- name: Hystrix
args:
name: fallbackcmd
fallbackUri: forward:/defaultfallback
- StripPrefix=1
#熔断器配置
hystrix:
command:
default:
execution:
isolation:
strategy: SEMAPHORE
thread:
timeoutInMilliseconds: 3000
shareSecurityContext: true
#网关日志输出
logging:
level:
org.springframework.cloud.gateway: TRACE
org.springframework.http.server.reactive: DEBUG
org.springframework.web.reactive: DEBUG
reactor.ipc.netty: DEBUG
以上配置的意思是:
- 网关服务以端口8089暴露
- 访问
http://127.0.0.1:8089/gateway/
开头的请求,将都被路由到下游http://127.0.0.1:8083/
下,且gateway
部分将被移除(StripPrefix=1
)。比如http://127.0.0.1:8089/gateway/test ----> http://127.0.0.1:8083/test - 超时异常熔断采用hystrix的SEMAPHORE策略,超时时间为3秒,如果下游服务不可达(异常),将由fallbackcmd处理,路由到本地http://127.0.0.1:8089/defaultfallback 处理。
构建defaultfallback处理器
@RestController
public class SelfHystrixController {
@RequestMapping("/defaultfallback")
public Map<String,String> defaultfallback(){
System.out.println("请求被熔断.");
Map<String,String> map = new HashMap<>();
map.put("Code","fail");
map.put("Message","服务异常");
map.put("result","");
return map;
}
}
先不构建下游服务,直接运行网关,访问地址http://127.0.0.1:8089/gateway/test
,出现如下情况:
构建下游服务项目,该项目为简单的spring boot web项目,具体配置不详述,添加服务类:
@RestController
public class TestController {
@RequestMapping("/timeout")
public String timeout(String name) {
try {
Thread.sleep(5000);
} catch (Exception e) {
e.printStackTrace();
}
return "timeout params:" + name;
}
}
可以发现,网关熔断策略是超时3秒就熔断,而下游服务需要用时5秒+。运行下游服务,继续在浏览器内访问地址http://127.0.0.1:8089/gateway/timeout
,如果正确配置,3秒后,仍将显示以上结果:
--------------------------------------小总结------------------------------------------------
可见,通过简单配置,在服务不可达和下游服务超时的情况下,Spring Cloud Gateway成功进行了熔断。
限流
扩充网关项目
pom.xml
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-data-redis-reactive</artifactId>
</dependency>
添加基于redis令牌桶机制的限流支持
当然网关还需要配置redis地址,以本地redis为例:
server:
redis:
host: localhost
添加限流键参数
通过该键来判断服务用户身份,比如一个客户端IP为一个用户,一个usrid为一个用户,添加配置类:
@Configuration
public class RateLimiterConfig {
@Bean(value = "remoteAddKeyResolver")
public KeyResolver remoteAddKeyResolver() {
return exchange -> Mono.just(exchange.getRequest().getRemoteAddress().getAddress().getHostAddress());
}
}
添加限流策略
spring:
application:
name: spring-cloud-gateway
cloud:
gateway:
routes:
- id: service_customer
#下游服务地址
uri: http://127.0.0.1:8083/
order: 0
#网关断言匹配
predicates:
- Path=/gateway/**
filters:
#熔断过滤器
- name: Hystrix
args:
name: fallbackcmd
fallbackUri: forward:/defaultfallback
- StripPrefix=1
#限流过滤器
- name: RequestRateLimiter
args:
key-resolver: '#{@remoteAddKeyResolver}'
# 每秒最大访问次数(放令牌桶的速率)
redis-rate-limiter.replenishRate: 10
# 令牌桶最大容量(令牌桶的大小)
redis-rate-limiter.burstCapacity: 10
主要是两个参数redis-rate-limiter.replenishRate: 10
、redis-rate-limiter.burstCapacity: 10
,前者控制往令牌桶丢令牌的速率,后者标识令牌桶的最大容量。
具体令牌桶算法可以参考下图:
算法描述
假如用户配置的平均发送速率为r,则每隔1/r秒一个令牌被加入到桶中
假设桶中最多可以存放b个令牌。如果令牌到达时令牌桶已经满了,那么这个令牌会被丢弃
当流量以速率v进入,从桶中以速率v取令牌,拿到令牌的流量通过,拿不到令牌流量不通过,执行熔断逻辑
当然这个只是概念,具体可以参考令牌桶算法
添加下游正常方法
@RequestMapping("/hello")
public String hello(String name) {
return "hi " + name;
}
Jmeter压测
修改限流参数:
# 每秒最大访问次数(放令牌桶的速率)
redis-rate-limiter.replenishRate: 2
# 令牌桶最大容量(令牌桶的大小)
redis-rate-limiter.burstCapacity: 10
配置Jmeter参数:
测试结果
200次请求,成功返回的大概有14次,异常请求的返回值为:
HTTP/1.1 429 Too Many Requests
X-RateLimit-Remaining: 0
X-RateLimit-Burst-Capacity: 10
X-RateLimit-Replenish-Rate: 2
content-length: 0
修改限流参数,重新测试
# 每秒最大访问次数(放令牌桶的速率)
redis-rate-limiter.replenishRate: 20
# 令牌桶最大容量(令牌桶的大小)
redis-rate-limiter.burstCapacity: 20
查看汇总结果,发现正常返回结果的数量明显变多(100%-26.5%=84%
)
限流功能正常!
-------------------------------------------惯例给源码---------------------------------------------
https://gitee.com/BeautifulHao/Spring-Cloud-Gateway-Demo.git