目录
- 一，环境配置
- 二，自定义全局过滤器
- 三，自定义局部管理器
- 四，gateway网关限流配置
一，环境配置
<dependency>
<groupId>com.alibaba.cloud</groupId>
<artifactId>spring-cloud-starter-alibaba-nacos-discovery</artifactId>
</dependency>
<dependency>
<groupId>org.springframework.cloud</groupId>
<artifactId>spring-cloud-starter-gateway</artifactId>
<version>2.2.3.RELEASE</version>
</dependency>
启动类加注解@EnableDiscoveryClient注册到nacos注册中心。
application.properties配置
spring.application.name=digitaltwins-api
server.port=8082
spring.cloud.nacos.discovery.server-addr=192.168.1.182:8848
spring.cloud.gateway.discovery.locator.enabled=true
spring.cloud.gateway.discovery.locator.enabled=true
这个配置是动态路由开启，自动识别nacos的服务名进行路由
比如：订单服务的nacos注册的服务名是test-order，那么从网关访问订单服务的地址是http://127.0.0.1:8080/test-order/xxxx/xxxx
二，自定义全局过滤器
网关路由请求过后，如果我们希望拦截请求，做自己的业务逻辑则可以使用GlobalFilter 全局过滤器。
全局过滤器的作用也是处理一切进入网关的请求和微服务响应，与 GatewayFilter 的作用一样。区别在于 GlobalFilter 的逻辑可以写代码来自定义规则；而 GatewayFilter 通过配置定义，处理逻辑是固定的。
需求：定义全局过滤器，拦截请求，判断请求的参数是否满足下面条件
- 参数中是否有 authorization
- authorization 参数值是否为 admin
如果同时满足则放行，否则拦截
三，自定义局部管理器
需求：在过滤器（MyParamGatewayFilterFactory）中将http://localhost:10010/user/8?name=yh 中的参数name的值获取到并输出到控制台
在application.yml文件中添加gateway过滤器：
建立一个文件config，创建名为MyParamGatewayFiterFactory的类
注意！命名xxxxGatewayFiterFactory，xxxx为yml自定义的名称+GatewayFiterFactory；GatewayFiterFactory没有或者出错会出现以下错误
将MyParamGatewayFiterFactory继承父类AbstractGatewayFilterFactory<MyParamGatewayFiterFactory.Config>并添加@Component注解
创建一个Config类用来读取过滤器配置的参数，在类中创建一个String类型的参数对应配置在application.yml配置文件中的过滤器参数名，并生成get set方法
重写父类的方法：
重写父类GatewayFilter方法，由源码可看出要求返回类型为
ServerWebExchange exchange, GatewayFilterChain chain
完整代码段
package com.yh.gateway.filter;
import org.springframework.cloud.gateway.filter.GatewayFilter;
import org.springframework.cloud.gateway.filter.factory.AbstractGatewayFilterFactory;
import org.springframework.http.server.reactive.ServerHttpRequest;
import org.springframework.stereotype.Component;
import java.util.Arrays;
import java.util.List;
@Component
public class MyParamGatewayFilterFactory extends AbstractGatewayFilterFactory<MyParamGatewayFilterFactory.Config> {
public MyParamGatewayFilterFactory() {
super(Config.class);
}
@Override
public List<String> shortcutFieldOrder() {
return Arrays.asList("param");
}
@Override
public GatewayFilter apply(Config config) {
return (exchange, chain) -> {
// http://localhost:10010/user/8?name=yh config.param ==> name
//获取请求参数中param对应的参数名 的参数值
ServerHttpRequest request = exchange.getRequest();
if (request.getQueryParams().containsKey(config.param)){
request.getQueryParams().get(config.param).forEach((v) -> {
System.out.print("--局部过滤器--获得参数 "+config.param+"="+ v);
});
}
return chain.filter(exchange);//执行请求
};
}
//读取过滤器配置的参数
public static class Config{
//对应配置在application.yml配置文件中的过滤器参数名
private String param;
public String getParam() {
return param;
}
public void setParam(String param) {
this.param = param;
}
}
}
四，gateway网关限流配置
限流缘由: 部分接口在某些场景业务下某短时间并发量较高，最简单暴力的方式就是限流
熔断、降级、限流的关系
熔断：熔断强调的是服务之间的调用能实现自我恢复的状态；
限流：限流是从系统的流量入口考虑，从进入的流量上进行限制，达到保护系统的作用；
降级：降级，是从系统内部的平级服务或者业务的维度考虑，流量大了，可以干掉一些，保护其他正常使用；
熔断是降级方式的一种；
降级又是限流的一种方式；
三者都是为了通过一定的方式去保护流量过大时，保护系统的手段。
限流常用算法
窗口算法：包含固定窗口算法，滑动窗口算法
漏桶算法：包含漏桶算法、令牌漏桶算法
窗口算法存在零界点时间问题，导致某段时间可能流量过大。
普通漏桶算法效率完全均匀一样，不能处理突发流量
gateway使用的限流算法为 令牌漏桶算法
令牌漏桶算法
令牌桶算法（Token Bucket）
令牌桶算法（Token Bucket）是目前应用最广泛的一种限流算法，它的基本思想由两部分组成：生成令牌 和 消费令牌。
生成令牌：假设有一个装令牌的桶，最多能装 M 个，然后按某个固定的速度（每秒 r 个）往桶中放入令牌，桶满时不再放入；
消费令牌：我们的每次请求都需要从桶中拿一个令牌才能放行，当桶中没有令牌时即触发限流，这时可以将请求放入一个缓冲队列中排队等待，或者直接拒绝；
令牌桶算法的图示如下：（图片来源）
在上面的图中，我们将请求放在一个缓冲队列中，可以看出这一部分的逻辑和漏桶算法几乎一模一样，只不过在处理请求上，一个是以固定速率处理，一个是从桶中获取令牌后才处理。
仔细思考就会发现，令牌桶算法有一个很关键的问题，就是桶大小的设置，正是这个参数可以让令牌桶算法具备处理突发流量的能力。譬如将桶大小设置为 100，生成令牌的速度设置为每秒 10 个，那么在系统空闲一段时间的之后（桶中令牌一直没有消费，慢慢的会被装满），突然来了 50 个请求，这时系统可以直接按每秒 50 个的速度处理，随着桶中的令牌很快用完，处理速度又会慢慢降下来，和生成令牌速度趋于一致。这是令牌桶算法和漏桶算法最大的区别，漏桶算法无论来了多少请求，只会一直以每秒 10 个的速度进行处理。当然，处理突发流量虽然提高了系统性能，但也给系统带来了一定的压力，如果桶大小设置不合理，突发的大流量可能会直接压垮系统。
gateway限流配置
gateway限流是基于redis实现，保证redis可用
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-data-redis-reactive</artifactId>
</dependency>
application.yml配置
spring:
redis:
host: 117.50.172.84
port: 6380
database: 1
password: redis&seatone123
主要限流代码参考类:RequestRateLimiterGatewayFilterFactory
主要方法:RateLimiter#isAllowed
通过KeyResolver接口传入唯一标识到isAllowed方法中标记
代码配置
KeyResolver注入主要实现的是限流的标记，我们就可以根据不同的标识来达到不同的限流方式，比如ip，接口地址
理论上这个接口实现能拿到的所有的key都能作为限流的唯一key
下面我实现ip、接口限流，其中ip限流为默认（@Primary相同bean默认注入）
* 限流配置
*
* @author LiRui
* @version 1.0
*/
@Configuration
public class RedisRateLimiterConfig {
/**
* 接口限流
* 获取请求地址的uri作为限流key
*
* @return
*/
@Bean("pathResolver")
public KeyResolver apiKeyResolver() {
return exchange -> Mono.just(exchange.getRequest().getPath().value());
}
/**
* ip限流
*
* @return
*/
@Bean("ipResolver")
@Primary
public KeyResolver ipKeyResolver() {
return exchange -> Mono.just(exchange.getRequest().getRemoteAddress().getHostName());
}
}
gateway配置
gateway限流是对某个 route 进行限流。
Spring Cloud Gateway，replenishRate 不支持设置小数，也就是说往桶中填充的 token 的速度最少为每秒 1 个
key-resolver 使用 SpEL 表达式 #{@beanName}，不配置默认使用ip限流
routes:
- id: test
uri: lb://test/
predicates:
- Path=/login/login
filters:
- RouteVersion
- name: RequestRateLimiter
args:
# 每秒允许处理的请求数量 # 令牌桶每秒填充平均速率
redis-rate-limiter.replenishRate: 20
# 每秒最大处理的请求数量# 令牌桶总容量
redis-rate-limiter.burstCapacity: 50
#限流策略，对应策略的Bean
key-resolver: "#{@ipResolver}"
实际设置redis-rate-limiter.replenishRate、redis-rate-limiter.burstCapacity需要根据系统本身的压测结果进行合理设置
限流之后HTTP返回结构
前端可根据返回状态码做相关提示
返回状态码:429
详细信息查看图片:
实现断言的配置
在yaml里进行配置
去到gateway-server项目的yaml配置文件里进行配置
# 新的配置routes和discovery是平级的
# id是这个断言的唯一标识
# uri是如果匹配上所有断言，请求将转发到这里
# StripPrefix相当于把 localhost:50080/gavinrouter/sayhello替换成 FEIGN-CLIENT/sayhello
spring:
application:
name: gateway-server
cloud:
gateway:
discovery:
locator:
enabled: true
lower-case-service-id: true
routes:
- id: feignclient
uri: lb://FEIGN-CLIENT
predicates:
- Path=/gavinrouter/**
filters:
- StripPrefix=1
作者：樊同学
