Java学习笔记 - 微服务网关SpringCloudGateway
Java学习笔记 - 微服务网关SpringCloudGateway
- 1、微服务网关简介
-
- 1.1 什么是微服务网关
- 1.2 作用和应用场景
- 1.3 核心概念
- 1.4 常见的API网关实现方式
- 2、Spring Cloud Gateway简介
- 3、Spring Cloud Gateway案例
- 4、路由规则
- 5、动态路由
- 6、重写转发路径
- 7、微服务名称转发路径
- 8、过滤器
-
- 8.1 过滤器基础
- 8.2 局部过滤器
- 8.3 全局过滤器
- 9、统一鉴权
-
- 9.1 鉴权逻辑
- 9.2 代码实现
- 10、网关限流
-
- 10.1 常见的限流算法
- 10.2 基于Filter的限流
- 10.3 基于Sentinel的限流
- 11、 网关高可用
1、微服务网关简介
1.1 什么是微服务网关
API网关是一个服务器，是系统对外的唯一入口。API网关封装了系统内部架构，为每个客户端提供一个定制的API。API网关方式的核心要点是，所有的客户端和消费端都通过统一的网关接入微服务，在网关层处理所有的非业务功能。通常，网关也是提供REST/HTTP的访问API。服务端通过API-GW注册和管理服务。
1.2 作用和应用场景
网关具有的职责，如身份验证、监控、负载均衡、缓存、请求分片与管理、静态响应处理。当然，最主要的职责还是与外界联系。
1.3 核心概念
（1）路由（route）：路由是网关最基础的部分，路由信息由一个ID、一个目的URL、一组断言工厂和一组Filter组成。如果断言为真，则说明请求URL和配置的路由匹配。
（2）断言（predicates）：Java8中的断言函数，Spring Cloud Gateway中的断言函数输入类型是Spring5.0框架中的ServerWebExchange。Spring Cloud Gateway中的断言函数允许开发者去定义匹配来自Http Request中的任何信息，比如请求头和参数等。
（3）过滤器（filter）：一个标准的Spring webFilter，Spring Cloud Gateway中的Filter分为两种类型，分别是Gateway Filter和Global Filter。过滤器Filter可以对请求和响应进行处理。
1.4 常见的API网关实现方式
- Kong：基于Nginx+Lua开发，性能高，稳定，有多个可用的插件(限流、鉴权等等)可以开箱即用。
问题：只支持Http协议；二次开发，自由扩展困难；提供管理API，缺乏更易用的管控、配置方式。
- Zuul：Netflix开源，功能丰富，使用JAVA开发，易于二次开发；需要运行在web容器中，如Tomcat。
问题：缺乏管控，无法动态配置；依赖组件较多；处理Http请求依赖的是Web容器，性能不如Nginx。
- Traefik：Go语言开发；轻量易用；提供大多数的功能：服务路由，负载均衡等等；提供WebUI。
问题：二进制文件部署，二次开发难度大；UI更多的是监控，缺乏配置、管理能力。
- Nginx+lua实现：使用Nginx的反向代理和负载均衡可实现对api服务器的负载均衡及高可用。
问题：自注册的问题和网关本身的扩展性。
- Spring Cloud Gateway：SpringCloud提供的网关服务。
2、Spring Cloud Gateway简介
Spring Cloud Gateway 是 Spring 官方基于 Spring 5.0，Spring Boot 2.0 和 Project Reactor 等技术开发的网关，旨在为微服务架构提供一种简单而有效的统一的 API 路由管理方式，统一访问接口。Spring Cloud Gateway 作为 Spring Cloud 生态系中的网关，目标是替代 Netflix ZUUL，其不仅提供统一的路由方式，并且基于 Filter 链的方式提供了网关基本的功能，例如：安全，监控/埋点，和限流等。它是基于Nttey的响应式开发模式。
3、Spring Cloud Gateway案例
（1） 创建工程导入依赖
在项目中添加新的模块api_gateway_server ，并导入依赖。
<dependency>
<groupId>org.springframework.cloudgroupId>
<artifactId>spring-cloud-starter-gatewayartifactId>
dependency>
- 注意：Spring Cloud Gateway使用的web框架为webflux，和SpringMVC不兼容。引入的限流组件是hystrix。redis底层不再使用jedis，而是lettuce。
（2） 配置启动类
@SpringBootApplication
public class ApiGatewayServerApplication {
public static void main(String[] args) {
SpringApplication.run(ApiGatewayServerApplication.class, args);
}
}
（3） 编写配置文件
创建application.yml 配置文件
server:
port: 8080 #服务端口
spring:
application:
name: api-gateway #指定服务名
cloud:
gateway:
routes:
- id: goods-service
uri: http://127.0.0.1:7892
predicates:
- Path=/goods/**
- id：我们自定义的路由 ID，保持唯一。
- uri：目标服务地址。
- predicates：路由条件，Predicate 接受一个输入参数，返回一个布尔值结果。该接口包含多种默认方法来将 Predicate 组合成其他复杂的逻辑（比如：与，或，非）。
- filters：过滤规则，暂时没用。
上面这段配置的意思是，配置了一个 id 为 goods-service 的路由规则，当访问网关请求地址以product 开头时，会自动转发到地址： http://127.0.0.1:7892/ 。配置完成启动项目即可在浏览器访问进行测试，当我们访问地址http://localhost:8080/goods/restuser/1 时会展示页面展示如下：
4、路由规则
Spring Cloud Gateway 的功能很强大，前面我们只是使用了 predicates 进行了简单的条件匹配，其实Spring Cloud Gataway 帮我们内置了很多 Predicates 功能。在 Spring Cloud Gateway 中 Spring 利用Predicate 的特性实现了各种路由匹配规则，有通过 Header、请求参数等不同的条件来进行作为条件匹配到对应的路由。
示例：
#路由断言之后匹配
spring:
cloud:
gateway:
routes:
- id: after_route
uri: https://xxxx.com
predicates:
- After=xxxxx
#路由断言之前匹配
spring:
cloud:
gateway:
routes:
- id: before_route
uri: https://xxxxxx.com
predicates:
- Before=xxxxxxx
#路由断言之间
spring:
cloud:
gateway:
routes:
- id: between_route
uri: https://xxxx.com
predicates:
- Between=xxxx,xxxx
#路由断言Cookie匹配,此predicate匹配给定名称(chocolate)和正则表达式(ch.p)
spring:
cloud:
gateway:
routes:
- id: cookie_route
uri: https://xxxx.com
predicates:
- Cookie=chocolate, ch.p
#路由断言Header匹配，header名称匹配X-Request-Id,且正则表达式匹配\d+
spring:
cloud:
gateway:
routes:
- id: header_route
uri: https://xxxx.com
predicates:
- Header=X-Request-Id, \d+
#路由断言匹配Host匹配，匹配下面Host主机列表,**代表可变参数
spring:
cloud:
gateway:
routes:
- id: host_route
uri: https://xxxx.com
predicates:
- Host=**.somehost.org,**.anotherhost.org
#路由断言Method匹配，匹配的是请求的HTTP方法
spring:
cloud:
gateway:
routes:
- id: method_route
uri: https://xxxx.com
predicates:
- Method=GET
#路由断言匹配，{segment}为可变参数
spring:
cloud:
gateway:
routes:
- id: host_route
uri: https://xxxx.com
predicates:
- Path=/foo/{segment},/bar/{segment}
#路由断言Query匹配，将请求的参数param(baz)进行匹配，也可以进行regexp正则表达式匹配 (参数包含foo,并且foo的值匹配ba.)
spring:
cloud:
gateway:
routes:
- id: query_route
uri: https://xxxx.com
predicates:
- Query=baz 或 Query=foo,ba.
#路由断言RemoteAddr匹配，将匹配192.168.1.1~192.168.1.254之间的ip地址，其中24为子网掩码位数即255.255.255.0
spring:
cloud:
gateway:
routes:
-id: remoteaddr_route
uri: https://example.org
predicates:
- RemoteAddr=192.168.1.1/24
5、动态路由
和zuul网关类似，在Spring Cloud GateWay中也支持动态路由：即自动的从注册中心中获取服务列表并访问。
（1）添加注册中心依赖
在工程的pom文件中添加注册中心的客户端依赖（这里以Eureka为例）。
<dependency>
<groupId>org.springframework.cloudgroupId>
<artifactId>spring-cloud-starter-netflix-eureka-clientartifactId>
dependency>
（2）配置动态路由
修改application.yml 配置文件，添加eureka注册中心的相关配置，并修改访问映射的URL为服务名称。
server:
port: 8080 #服务端口
spring:
application:
name: api-gateway #指定服务名
cloud:
gateway:
routes:
- id: goods-service
uri: lb://eureka-microservice-goods # lb:// 代表根据服务名称从注册中心获取服务
predicates:
- Path=/goods/**
eureka:
client:
serviceUrl:
defaultZone: http://127.0.0.1:7890/eureka/
registry-fetch-interval-seconds: 5 # 获取服务列表的周期：5s
instance:
preferIpAddress: true
ip-address: 127.0.0.1
- uri ： uri以lb: //开头（lb代表从注册中心获取服务），后面接的就是需要转发到的服务名称。
6、重写转发路径
在Spring Cloud Gateway中，路由转发是将匹配的路由path直接拼接到映射路径（URI）之后，那么在微服务开发中往往没有那么便利，这里就可以通过RewritePath机制来进行路径重写。
案例：将匹配路径 http://localhost:8080/goods-service/goods/restuser/1 转发到路径 http://localhost:8080/goods/restuser/1 。
（1）添加RewritePath重写转发路径
修改application.yml ，添加重写规则，配置路由过滤器。
server:
port: 8080 #服务端口
spring:
application:
name: api-gateway #指定服务名
cloud:
gateway:
routes:
- id: goods-service
uri: lb://eureka-microservice-goods
predicates:
- Path=/goods-service/**
filters: # 配置路由过滤器（ 在yml文档中 $ 要写成 $\ ）
- RewritePath=/goods-service/(?>.*), /$\{segment}
eureka:
client:
serviceUrl:
defaultZone: http://127.0.0.1:7890/eureka/
registry-fetch-interval-seconds: 5 # 获取服务列表的周期：5s
instance:
preferIpAddress: true
ip-address: 127.0.0.1
通过RewritePath配置重写转发的url，将/goods-service/(?.*)重写为{segment}，然后转发到产品微服务。比如在网页上请求 http://localhost:8080/goods-service/goods/restuser/1，此时会将请求转发到 http://localhost:8080/goods/restuser/1。
7、微服务名称转发路径
配置自动根据微服务名称进行路由转发，比如在网页上请求 http://localhost:8080/eureka-microservice-goods/goods/restuser/1，此时会将请求转发到产品微服务eureka-microservice-goods中。
server:
port: 8080 #服务端口
spring:
application:
name: api-gateway #指定服务名
cloud:
gateway:
discovery: #配置自动的根据微服务名称进行路由转发 http://localhost:8080/eureka-microservice-goods
locator:
enabled: true #开启根据服务名称自动转发
lower-case-service-id: true #微服务名称已小写形式呈现(默认微服务名称是大写的)
8、过滤器
Spring Cloud Gateway除了具备请求路由功能之外，也支持对请求的过滤。通过Zuul网关类似，也是通过过滤器的形式来实现的。那么接下来我们一起来研究一下Gateway中的过滤器。
8.1 过滤器基础
（1） 过滤器的生命周期
Spring Cloud Gateway 的 Filter 的生命周期不像 Zuul 的那么丰富，它只有两个：“pre” 和 “post”。
- PRE： 这种过滤器在请求被路由之前调用。我们可利用这种过滤器实现身份验证、在集群中选择请求的微服务、记录调试信息等。
- POST：这种过滤器在路由到微服务以后执行。这种过滤器可用来为响应添加标准的 HTTPHeader、收集统计信息和指标、将响应从微服务发送给客户端等。
（2） 过滤器类型
Spring Cloud Gateway 的 Filter 从作用范围可分为另外两种GatewayFilter 与GlobalFilter。
- GatewayFilter：应用到单个路由或者一个分组的路由上。
- GlobalFilter：应用到所有的路由上。
8.2 局部过滤器
局部过滤器（GatewayFilter），是针对单个路由的过滤器。可以对访问的URL过滤，进行切面处理。在Spring Cloud Gateway中通过GatewayFilter的形式内置了很多不同类型的局部过滤器。这里简单将Spring Cloud Gateway内置的所有过滤器工厂整理成了一张表格，虽然不是很详细，但能作为速览使用。如下：
| 过滤器工厂 | 作用 | 参数 |
|---|---|---|
| AddRequestHeader | 为原始请求添加Header | Header的名称及值 |
| AddRequestParameter | 为原始请求添加请求参数 | 参数名称及值 |
| AddResponseHeader | 为原始响应添加Header | Header的名称及值 |
| DedupeResponseHeader | 剔除响应头中重复的值 | 需要去重的Header名称及去重策略 |
| Hystrix | 为路由引入Hystrix的断路器保护 | HystrixCommand 的名称 |
| FallbackHeaders | 为fallbackUri的请求头中添加具体的异常信息 | Header的名称 |
| PrefixPath | 为原始请求路径添加前缀 | 前缀路径 |
| PreserveHostHeader | 为请求添加一个preserveHostHeader=true的属性，路由过滤器会检查该属性以决定是否要发送原始的Host | 无 |
| RequestRateLimiter | 用于对请求限流，限流算法为令牌桶 | keyResolver、rateLimiter、statusCode、denyEmptyKey、emptyKeyStatus |
| RedirectTo | 将原始请求重定向到指定的URL | http状态码及重定向的url |
| RemoveHopByHopHeadersFilter | 为原始请求删除IETF组织规定的一系列Header | 默认就会启用，可以通过配置指定仅删除哪些Header |
| RemoveRequestHeader | 为原始请求删除某个Header | Header名称 |
| RemoveResponseHeader | 为原始响应删除某个Header | Header名称 |
| RewritePath | 重写原始的请求路径 | 原始路径正则表达式以及重写后路径的正则表达式 |
| RewriteResponseHeader | 重写原始响应中的某个Header | Header名称，值的正则表达式，重写后的值 |
| SaveSession | 在转发请求之前，强制执行WebSession::save 操作 | 无 |
| secureHeaders | 为原始响应添加一系列起安全作用的响应头 | 无，支持修改这些安全响应头的值 |
| SetPath | 修改原始的请求路径 | 修改后的路径 |
| SetResponseHeader | 修改原始响应中某个Header的值 | Header名称，修改后的值 |
| SetStatus | 修改原始响应的状态码 | HTTP 状态码，可以是数字，也可以是字符串 |
| StripPrefix | 用于截断原始请求的路径 | 使用数字表示要截断的路径的数量 |
| Retry | 针对不同的响应进行重试 | retries、statuses、methods、series |
| RequestSize | RequestSize设置允许接收最大请求包的大小。如果请求包大小超过设置的值，则返回 413 Payload TooLarge | 请求包大小，单位为字节，默认值为5M |
| ModifyRequestBody | 在转发请求之前修改原始请求体内容 | 修改后的请求体内容 |
| ModifyResponseBody | 修改原始响应体的内容 | 修改后的响应体内 |
每个过滤器工厂都对应一个实现类，并且这些类的名称必须以GatewayFilterFactory 结尾，这是Spring Cloud Gateway的一个约定，例如AddRequestHeader 对应的实现类为AddRequestHeaderGatewayFilterFactory 。对于这些过滤器的使用方式可以参考官方文档。
8.3 全局过滤器
全局过滤器（GlobalFilter）作用于所有路由，Spring Cloud Gateway 定义了Global Filter接口，用户可以自定义实现自己的Global Filter。通过全局过滤器可以实现对权限的统一校验，安全性验证等功能，并且全局过滤器也是程序员使用比较多的过滤器。
Spring Cloud Gateway内部也是通过一系列的内置全局过滤器对整个路由转发进行处理如下：
- LoginFilter.java
/**
* 自定义一个全局过滤器(实现GlobalFilter和Ordered接口)
*/
@Component
public class LoginFilter implements GlobalFilter, Ordered {
/**
* 执行过滤器中的业务逻辑
*/
@Override
public Mono<Void> filter(ServerWebExchange exchange, GatewayFilterChain chain) {
System.out.println("执行了自定义的全局过滤器");
return chain.filter(exchange);
}
/**
* 指定过滤器的执行顺序,返回值越小,执行优先级越高。
*/
@Override
public int getOrder() {
return 0;
}
}
9、统一鉴权
内置的过滤器已经可以完成大部分的功能，但是对于企业开发的一些业务功能处理，还是需要我们自己编写过滤器来实现的，那么我们一起通过代码的形式自定义一个过滤器，去完成统一的权限校验。
9.1 鉴权逻辑
开发中的鉴权逻辑：当客户端第一次请求服务时，服务端对用户进行信息认证（登录），认证通过，将用户信息进行加密形成token，返回给客户端，作为登录凭证，以后每次请求，客户端都携带认证的token，服务端对token进行解密，判断是否有效。
如上图，对于验证用户是否已经登录鉴权的过程可以在网关层统一检验。检验的标准就是请求中是否携带token凭证以及token的正确性。
9.2 代码实现
下面自定义一个认证过滤器（是一个全局过滤器），去校验所有请求的请求参数中是否包含token，如何不包含请求参数token则不转发路由，否则执行正常的逻辑。
/**
* 认证过滤器(是一个全局过滤器，需要实现GlobalFilter和Ordered接口)
*/
@Component
public class LoginFilter implements GlobalFilter, Ordered {
/**
* 执行过滤器中的业务逻辑
* 对请求参数中的access-token进行判断
* 1.如果存在此参数:代表认证成功
* 2.如果不存在此参数:代表认证失败
* ServerWebExchange : 相当于请求和响应的上下文(zuul中的RequestContext)
*/
@Override
public Mono<Void> filter(ServerWebExchange exchange, GatewayFilterChain chain) {
System.out.println("执行了自定义的全局过滤器");
// 1.获取请求参数access-token
String token = exchange.getRequest().getQueryParams().getFirst("access-token");
// 2.判断请求参数access-token是否存在
if(token == null) {
// 3.如果请求参数access-token不存在，则认证失败
System.out.println("没有登录");
exchange.getResponse().setStatusCode(HttpStatus.UNAUTHORIZED);
return exchange.getResponse().setComplete(); // 请求结束
}
//3.如果请求参数access-token存在,继续向下执行
return chain.filter(exchange); //继续向下执行
}
/**
* 指定过滤器的执行顺序,返回值越小,执行优先级越高。
*/
@Override
public int getOrder() {
return 0;
}
}
- 自定义全局过滤器需要实现GlobalFilter和Ordered接口。
- 在filter方法中完成过滤器的逻辑判断处理。
- 在getOrder方法指定此过滤器的优先级，返回值越大，级别越低。
- ServerWebExchange 就相当于当前请求和响应的上下文，存放着重要的请求-响应属性、请求实例和响应实例等等。一个请求中的request，response都可以通过ServerWebExchange 获取调用chain.filter 继续向下游执行。
10、网关限流
10.1 常见的限流算法
（1） 计数器限流算法
计数器限流算法是最简单的一种限流实现方式。其本质是通过维护一个单位时间内的计数器，每次请求计数器加1，当单位时间内计数器累加到大于设定的阈值，则之后的请求都被拒绝，直到单位时间已经过去，再将计数器重置为零。
（2） 漏桶算法
漏桶算法可以很好地限制容量池的大小，从而防止流量暴增。漏桶可以看作是一个带有常量服务时间的单服务器队列，如果漏桶（包缓存）溢出，那么数据包会被丢弃。 在网络中，漏桶算法可以控制端口的流量输出速率，平滑网络上的突发流量，实现流量整形，从而为网络提供一个稳定的流量。
为了更好的控制流量，漏桶算法需要通过两个变量进行控制：一个是桶的大小，支持流量突发增多时可以存多少的水（burst），另一个是水桶漏洞的大小（rate）。
（3） 令牌桶算法
令牌桶算法是对漏桶算法的一种改进，漏桶算法能够限制请求调用的速率，而令牌桶算法能够在限制调用的平均速率的同时还允许一定程度的突发调用。在令牌桶算法中，存在一个桶，用来存放固定数量的令牌。算法中存在一种机制，以一定的速率往桶中放令牌。每次请求调用需要先获取令牌，只有拿到令牌，才有机会继续执行，否则选择选择等待可用的令牌、或者直接拒绝。放令牌这个动作是持续不断的进行，如果桶中令牌数达到上限，就丢弃令牌，所以就存在这种情况，桶中一直有大量的可用令牌，这时进来的请求就可以直接拿到令牌执行，比如设置qps为100，那么限流器初始化完成一秒后，桶中就已经有100个令牌了，这时服务还没完全启动好，等启动完成对外提供服务时，该限流器可以抵挡瞬时的100个请求。所以，只有桶中没有令牌时，请求才会进行等待，最后相当于以一定的速率执行。
10.2 基于Filter的限流
Spring Cloud Gateway官方提供了基于令牌桶的限流支持。基于其内置的过滤器工厂RequestRateLimiterGatewayFilterFactory 实现。在过滤器工厂中是通过Redis和lua脚本结合的方式进行流量控制。
（1） 环境搭建
- 导入Redis的依赖
在工程的pom.xml文件中增加gateway的监控依赖和redis的reactive依赖。
<dependency>
<groupId>org.springframework.bootgroupId>
<artifactId>spring-boot-starter-actuatorartifactId>
dependency>
<dependency>
<groupId>org.springframework.bootgroupId>
<artifactId>spring-boot-starter-data-redis-reactiveartifactId>
dependency>
- 开启Redis数据库，启动Redis的服务端和客户端，并在客户端输入命令：monitor，来监听Redis的执行过程。
（2） 修改application.yml配置文件
在application.yml配置文件中加入限流的配置。
server:
port: 8080 #服务端口
spring:
application:
name: api-gateway #指定服务名
redis:
host: localhost
port: 6379
cloud:
gateway:
routes:
- id: goods-service
uri: lb://eureka-microservice-goods
predicates:
- Path=/goods-service/**
filters:
- RewritePath=/goods-service/(?>.*), /$\{segment}
- name: RequestRateLimiter
args:
# 使用SpEL从容器中获取对象
key-resolver: '#{@pathKeyResolver}'
# 令牌桶每秒填充平均速率
redis-rate-limiter.replenishRate: 1
# 令牌桶的总容量
redis-rate-limiter.burstCapacity: 3
eureka:
client:
serviceUrl:
defaultZone: http://127.0.0.1:7890/eureka/
registry-fetch-interval-seconds: 5 # 获取服务列表的周期：5s
instance:
preferIpAddress: true
ip-address: 127.0.0.1
在 application.yml 中添加了Redis的信息，并配置了RequestRateLimiter的限流过滤器：
- burstCapacity：令牌桶总容量。
- replenishRate：令牌桶每秒填充平均速率。
- key-resolver：用于限流的键的解析器的 Bean 对象的名字。它使用 SpEL 表达式根据#{@beanName}从 Spring 容器中获取 Bean 对象。
（3） 配置KeyResolver
为了达到不同的限流效果和规则，可以通过实现 KeyResolver 接口，定义不同请求类型的限流键。
@Configuration
public class KeyResolverConfiguration {
/**
* 编写基于请求路径的限流规则:
* 1.基于请求路径
* 2.基于请求ip
* 3.基于请求参数
*/
// // 基于请求路径的限流-写法1
// @Bean
// public KeyResolver pathKeyResolver() {
// //自定义的KeyResolver
// return new KeyResolver() {
// *//**
// * ServerWebExchange:上下文参数
// *//*
// public Mono resolve(ServerWebExchange exchange) {
// return Mono.just( exchange.getRequest().getPath().toString());
// }
// };
// }
/**
* 基于请求路径的限流-写法2（lamda表达式）
* 访问 请求路径
*/
@Bean
public KeyResolver pathKeyResolver() {
return exchange -> Mono.just(
exchange.getRequest().getPath().toString()
);
}
/**
* 基于请求ip地址的限流
*/
//@Bean
public KeyResolver ipKeyResolver() {
return exchange -> Mono.just(
exchange.getRequest().getHeaders().getFirst("X-Forwarded-For")
);
}
/**
* 基于参数的限流
* 访问 请求路径?userId=1
*/
//@Bean
public KeyResolver paramKeyResolver() {
return exchange -> Mono.just(
exchange.getRequest().getQueryParams().getFirst("userId")
);
}
}
在限流键pathKeyResolver、ipKeyResolver和paramKeyResolver中只能使用一个，多余的bean要注释掉。使用pathKeyResolver时，在application.yml配置中的key-resolver的值要改成'#{@pathKeyResolver}'，访问请求路径 http://localhost:8080/goods-service/goods/restuser/1?access-token=123，当达到令牌桶的总容量时，其他的请求会返回429错误。
通过Redis客户端的monitor命令可以监听redis的执行过程，这时候Redis客户端中会有对应的数据：
-
大括号中是限流Key。
-
timestamp：存储的是当前时间的秒数，也就是System.currentTimeMillis() / 1000或者Instant.now().getEpochSecond()。
-
tokens：存储的是当前这秒钟的对应的可用令牌数量。
Spring Cloud Gateway目前提供的限流还是相对比较简单的，在实际中我们的限流策略会有很多种情况，比如：对不同接口的限流、被限流后的友好提示，这些可以通过自定义RedisRateLimiter来实现限流策略。
10.3 基于Sentinel的限流
Sentinel 支持对 Spring Cloud Gateway、Zuul 等主流的 API Gateway 进行限流。
从 1.6.0 版本开始，Sentinel 提供了 Spring Cloud Gateway 的适配模块，可以提供两种资源维度的限流：
- route 维度：即在 Spring 配置文件中配置的路由条目，资源名为对应的 routeId
- 自定义 API 维度：用户可以利用 Sentinel 提供的 API 来自定义一些 API 分组
Sentinel 1.6.0 引入了 Sentinel API Gateway Adapter Common 模块，此模块中包含网关限流的规则和自定义 API 的实体和管理逻辑：
- GatewayFlowRule ：网关限流规则，针对 API Gateway 的场景定制的限流规则，可以针对不同route 或自定义的 API 分组进行限流，支持针对请求中的参数、Header、来源 IP 等进行定制化的限流。
- ApiDefinition ：用户自定义的 API 定义分组，可以看做是一些 URL 匹配的组合。比如我们可以定义一个 API 叫 my_api ，请求 path 模式为 /foo/** 和 /baz/** 的都归到 my_api 这个 API分组下面。限流的时候可以针对这个自定义的 API 分组维度进行限流。
（1）环境搭建
导入Sentinel 的响应依赖
<dependency>
<groupId>com.alibaba.cspgroupId>
<artifactId>sentinel-spring-cloud-gateway-adapterartifactId>
<version>1.6.3version>
dependency>
（2） 编写配置类
- GatewayConfiguration.java
/**
* sentinel限流的配置
*/
@Configuration
public class GatewayConfiguration {
private final List<ViewResolver> viewResolvers;
private final ServerCodecConfigurer serverCodecConfigurer;
public GatewayConfiguration(ObjectProvider<List<ViewResolver>> viewResolversProvider,ServerCodecConfigurer serverCodecConfigurer) {
this.viewResolvers = viewResolversProvider.getIfAvailable(Collections::emptyList);
this.serverCodecConfigurer = serverCodecConfigurer;
}
/**
* 配置限流的异常处理器:SentinelGatewayBlockExceptionHandler
*/
@Bean
@Order(Ordered.HIGHEST_PRECEDENCE)
public SentinelGatewayBlockExceptionHandler sentinelGatewayBlockExceptionHandler() {
return new SentinelGatewayBlockExceptionHandler(viewResolvers, serverCodecConfigurer);
}
/**
* 配置限流过滤器
*/
@Bean
@Order(Ordered.HIGHEST_PRECEDENCE)
public GlobalFilter sentinelGatewayFilter() {
return new SentinelGatewayFilter();
}
/**
* 配置初始化的限流参数
* 用于指定资源的限流规则.
* 1.资源名称 (路由id)
* 2.配置统计时间
* 3.配置限流阈值
*/
@PostConstruct
public void initGatewayRules() {
Set<GatewayFlowRule> rules = new HashSet<>();
rules.add(new GatewayFlowRule("goods-service") //资源名称
.setCount(1) // 限流阈值
.setIntervalSec(1) // 统计时间窗口，单位是秒，默认是1秒
);
GatewayRuleManager.loadRules(rules);
}
}
- 基于Sentinel 的Gateway限流是通过其提供的Filter来完成的，使用时只需注入对应的SentinelGatewayFilter 实例以及 SentinelGatewayBlockExceptionHandler 实例即可。
- @PostConstruct定义初始化的加载方法，用于指定资源的限流规则。这里资源的名称为goods-service，统计时间是1秒内，限流阈值是1，表示每秒只能访问一个请求，否则则报ParamFlowException异常。
（3）网关配置
- application.yml
server:
port: 8080 #服务端口
spring:
application:
name: api-gateway #指定服务名
redis:
host: localhost
port: 6379
cloud:
gateway:
routes:
- id: goods-service
uri: lb://eureka-microservice-goods
predicates:
- Path=/goods-service/**
filters:
- RewritePath=/goods-service/(?>.*), /$\{segment}
eureka:
client:
serviceUrl:
defaultZone: http://127.0.0.1:7890/eureka/
registry-fetch-interval-seconds: 5 # 获取服务列表的周期：5s
instance:
preferIpAddress: true
ip-address: 127.0.0.1
在一秒钟内多次访问http://localhost:8080/goods-service/goods/restuser/1?access-token=123&userId=11就可以看到限流启作用了。
（4）自定义异常提示
当触发限流后页面显示的是Blocked by Sentinel: FlowException。为了展示更加友好的限流提示，Sentinel支持自定义异常处理。可以在 GatewayCallbackManager 注册回调进行定制：
- setBlockHandler ：注册函数用于实现自定义的逻辑来处理被限流的请求，对应接口为BlockRequestHandler 。默认实现为 DefaultBlockRequestHandler，当被限流时会返回类似于以下的错误信息： Blocked by Sentinel: FlowException 。
/**
* 自定义限流处理器
*/
@PostConstruct
public void initBlockHandlers() {
BlockRequestHandler blockHandler = new BlockRequestHandler() {
public Mono<ServerResponse> handleRequest(ServerWebExchange serverWebExchange, Throwable throwable) {
Map map = new HashMap();
map.put("code",200);
map.put("message","不好意思,限流了");
return ServerResponse.status(HttpStatus.OK)
.contentType(MediaType.APPLICATION_JSON_UTF8)
.body(BodyInserters.fromObject(map));
}
};
GatewayCallbackManager.setBlockHandler(blockHandler);
}
（5） 参数限流
上面的配置是针对整个路由来限流的，如果我们只想对某个路由的参数做限流，那么可以使用参数限流方式。
/**
* 配置初始化的限流参数
* 用于指定资源的限流规则.
* 1.资源名称 (路由id)
* 2.配置统计时间
* 3.配置限流阈值
*/
@PostConstruct
public void initGatewayRules() {
Set<GatewayFlowRule> rules = new HashSet<>();
rules.add(new GatewayFlowRule("goods_api")
.setCount(1)
.setIntervalSec(1)
);
GatewayRuleManager.loadRules(rules);
}
通过指定PARAM_PARSE_STRATEGY_URL_PARAM表示从url中获取参数，setFieldName指定参数名称。
（6） 自定义API分组
/**
* 配置初始化的限流参数
* 用于指定资源的限流规则.
* 1.资源名称 (路由id)
* 2.配置统计时间
* 3.配置限流阈值
*/
@PostConstruct
public void initGatewayRules() {
Set<GatewayFlowRule> rules = new HashSet<>();
rules.add(new GatewayFlowRule("goods_api")
.setCount(1)
.setIntervalSec(1)
);
GatewayRuleManager.loadRules(rules);
}
/**
* 自定义API限流分组
* 1.定义分组
* 2.对小组配置限流规则
*/
@PostConstruct
private void initCustomizedApis() {
Set<ApiDefinition> definitions = new HashSet<>();
// 例子1：组名为goods_api
ApiDefinition api1 = new ApiDefinition("goods_api")
.setPredicateItems(new HashSet<ApiPredicateItem>() {{
add(new ApiPathPredicateItem().setPattern("/goods-service/goods/**"). // 以/goods-service/goods/开头的所有url
setMatchStrategy(SentinelGatewayConstants.URL_MATCH_STRATEGY_PREFIX));
}});
// 例子2：组名为user_api
ApiDefinition api2 = new ApiDefinition("user_api")
.setPredicateItems(new HashSet<ApiPredicateItem>() {{
add(new ApiPathPredicateItem().setPattern("/user-service/user")); // 完全匹配/user-service/user的url
}});
definitions.add(api1);
definitions.add(api2);
GatewayApiDefinitionManager.loadApiDefinitions(definitions);
}
11、 网关高可用
高可用 HA（High Availability）是分布式系统架构设计中必须考虑的因素之一，它通常是指通过设计减少系统不能提供服务的时间。单点是系统高可用的大敌，单点往往是系统高可用最大的风险和敌人，应该尽量在系统设计的过程中避免单点。方法论上，高可用保证的原则是集群化，或者说冗余。
我们实际使用 Spring Cloud Gateway 的方式如上图，不同的客户端使用不同的负载将请求分发到后端的 Gateway，Gateway 再通过HTTP调用后端服务，最后对外输出。因此为了保证 Gateway 的高可用性，前端可以同时启动多个 Gateway 实例进行负载，在Gateway 的前端使用 Nginx 或者 F5 进行负载转发以达到高可用性。
（1） 准备多个GateWay工程
先通过以下第一个application.yml配置文件来启动第一个网关服务，然后修改其配置文件中的服务端口和指定服务名来启动第二个网关服务，请求端口分别为8080和8081，浏览器验证发现两个网关的效果是一致的（如果有开启限流，为了避免限流影响，可以注释配置文件GatewayConfiguration.java的@Configuration来关闭限流）。
server:
port: 8080 #服务端口
spring:
application:
name: api-gateway #指定服务名
redis:
host: localhost
port: 6379
cloud:
gateway:
routes:
- id: goods-service
uri: lb://eureka-microservice-goods
predicates:
- Path=/goods-service/**
filters:
- RewritePath=/goods-service/(?>.*), /$\{segment}
eureka:
client:
serviceUrl:
defaultZone: http://127.0.0.1:7890/eureka/
registry-fetch-interval-seconds: 5 # 获取服务列表的周期：5s
instance:
preferIpAddress: true
ip-address: 127.0.0.1
server:
port: 8081 #服务端口
spring:
application:
name: api-gateway02 #指定服务名
redis:
host: localhost
port: 6379
cloud:
gateway:
routes:
- id: goods-service
uri: lb://eureka-microservice-goods
predicates:
- Path=/goods-service/**
filters:
- RewritePath=/goods-service/(?>.*), /$\{segment}
eureka:
client:
serviceUrl:
defaultZone: http://127.0.0.1:7890/eureka/
registry-fetch-interval-seconds: 5 # 获取服务列表的周期：5s
instance:
preferIpAddress: true
ip-address: 127.0.0.1
（2） 配置ngnix
下载解压nginx-1.8.0压缩包（解压的路径中不能包含中文），在 nginx-1.8.0\conf\nginx.conf 配置文件 中添加负载均衡配置。
- 在http {…}中添加以下配置
#配置多台服务器（这里只在一台服务器上的不同端口）
upstream gateway {
server 127.0.0.1:8081;
server 127.0.0.1:8080;
}
- 在http {…}的server{…}中添加以下配置
#请求转向mysvr 定义的服务器列表
location / {
proxy_pass http://gateway;
}
# 添加以上配置的同时，需要注释以下配置，否则nginx启动会失败
#location / {
# root html;
# index index.html index.htm;
#}
（3）找到nginx.exe双击运行即可，在浏览器上通过访问 http://127.0.0.1/goods-service/goods/restuser/1?access-token=123&userId=11 请求的效果和上面是一样的。这次关闭其中一台网关服务器（Gateway），还是可以支持部分请求的访问。