51工具盒子# （一）什么是微服务网关 {#一-什么是微服务网关}
后端写完所有的微服务之后，最终是要交给前端去调用。我们都知道每个微服务都有各自的端口号，如果前端直接通过IP加端口的方式去调用微服务会很麻烦。如果想对请求增加限制也会变得十分困难。这个时候微服务网关就出现了。
微服务网关又成为API网关，它是系统对外的唯一入口。APl网关封装了系统内部架构，为每个客户端提供一个定制的APl。API网关方式的核心要点是，所有的客户端和消费端都通过统一的网关接入微服务，在网关层处理所有的非业务功能。通常，网关也是提供REST/HTTP的访问API。服务端通过API-GW注册和管理服务。
听起来有些抽象，下面就做一张图给大家展示一下：前端的请求统一由微服务网关进行管理，微服务网关可以调用各个微服务，同时自身还有多种功能。
API网关的职责有身份验证、监控、负载均衡、缓存、请求分片与管理、静态响应处理，最重要的功能是和外界联系。
常见的API网关实现方式有Zuul，traefix，Spring Cloud Gateway等等。目前主流的微服务网关是Spring Cloud Gateway。
# (二)Spring Cloud Gateway网关 {#二-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的响应式开发模式。
# 2.1 核心概念： {#_2-1-核心概念}
路由（route）：路由是网关最基础的部分，路由信息由一个ID，一个目的URL，一组断言工厂和一组Filter组成。
断言（predicates）：java8中的断言函数，Spring Cloud Gateway中的断言函数允许开发者去定义匹配来自Http Request中的任何信息。当断言为真时，则匹配路由。
过滤器（filter）：对请求和响应进行过滤
下面通过实践来操作微服务网关。
# 2.2 搭建环境： {#_2-2-搭建环境}
所使用的项目依旧基于之前博客所写的项目，源码放在文末。为了方便理解，所用的模块只有三个：
创建工程导入依赖
创建api_gateway_server工程，在工程中的pom.xml中导入依赖
<dependency>
<groupId>org.springframework.cloud</groupId>
<artifactId>spring-cloud-starter-gateway</artifactId></dependency><!--eureka，之后会用到--><dependency>
<groupId>org.springframework.cloud</groupId>
<artifactId>spring-cloud-starter-netflix-eureka-client</artifactId></dependency>
配置启动类
创建GatewayApplication类
@SpringBootApplicationpublic class GatewayApplication {
public static void main(String[] args) {
SpringApplication.run(GatewayApplication.class);
}}
编写配置文件
这里对配置文件的编写使用.yml格式的配置文件，在resource文件夹下创建applicaiion.yml。这里需要注意的是gateway下routes的配置，首先用id自定义网关；接着定义uri，意思是当访问的是9090端口（即访问的是网关时），就自动把ip和端口号变成该uri；最后写断言predicates，这里的Path=/user/** 指得是自动匹配/user/**的路径。当请求地址为http://localhost:9090/user/1时，微服务网关会去访问http://127.0.0.1:9001/user/1,这就是微服务网关调用微服务的功能。
#设置端口为9090server:
port: 9090#eureka配置eureka:
client:
service-url:
defaultZone: http://localhost:9000/eureka/ instance:
prefer-ip-address: true
spring:
application:
name: api-gateway-server #配置SpringCloudGateway的路由
cloud:
gateway:
routes:
- id: user-service #id是自定义的标识
uri: http://127.0.0.1:9001 #当访问9090端口时，自动把ip和端口替换为此uri
predicates:
- Path = /user/** #自动匹配/user/**的路径
一个小错误：
springcloudgateway的内部是通过netty+webflux实现，webflux实现和springmvc存在冲突，因此修改整个项目的父类依赖
将springmvc的依赖放到需要的module上，将依赖从父依赖中删除
# 2.3 路由配置详解 {#_2-3-路由配置详解}
路由断言中有许多匹配规则，之前只介绍了Path，其实还有许多匹配规则
predicates:
- After=XXX #路由断言之后匹配
- Before=XXX #路由断言之前匹配
- Between=XXX,XXX #路由断言之间
- Cookie=XXX #路由断言Cookie匹配，匹配给定名称（如master）和正则表达式（如ma.r）
- Header=XXX #根据请求头信息匹配
- Host=**.somehost.org #根据host地址匹配
- Method=GET #根据请求方法匹配
- Path=*** #路由断言匹配
- Query=baz #路由断言Query匹配
- RemoteAddr=192.168.1.1/24 #根据远程路径匹配
定义请求路径时，我们还可以据微服务名称拉取请求路径，下面是两种不同方法定义uri，实现同样的功能。
#uri: http://127.0.0.1:9001 #当访问9090端口时，自动把ip和端口替换为此uriuri: lb://userservice #根据微服务名称拉取请求路径
在请求转发时，我们还可以使用http://localhost:9090/微服务名称/user/1的方式进行请求转发，只需要在配置文件中增加相关配置：
discovery:
locator:
enabled: true #开启根据微服务名称自动转发
lower-case-service-id: true #w微服务名称小写呈现
总体的配置如图
# 2.4 Spring Cloud Gateway过滤器 {#_2-4-spring-cloud-gateway过滤器}
Spring Cloud Gateway除了具有请求路由功能之外，也支持对请求的过滤。
生命周期：
过滤器有两种生命周期，PRE和POST：
PRE：这种过滤器在请求被路由之前调用。我们可利用这种过滤器实现身份验证、在集群中选择请求的微服务、记录调试信息等。
POST：这种过滤器在路由到微服务以后执行。这种过滤器可用来为响应添加标准的HTTP Header、收集统计信息和指标、将响应从微服务发送给客户端等。
过滤器类型：
GatewayFilter：应用到单个路由或者一个分组的路由上
GlobalFilter：应用到所有的路由上
局部过滤器可以使用Spring Cloud Gateway内置的方法，在这里不做过多解释。这里主要介绍如何自定义全局过滤器
过滤器实践：
创建一个Filter包，在包下新建GatewayFilter类，自定义全局过滤器需要继承GlobalFilter, Ordered接口，并重写接口的两个方法
@Componentpublic class GatewayFilter 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;
}}
通过访问可以看到控制台上出现了打印的信息。
模拟用户认证过程：
全局过滤器可以实现对全局的用户验证。修改gatewayFilter，编写失败的逻辑，如果获取到的request请求中第一个属性不是access-token或为空，则返回HttpStatus.UNAUTHORIZED的报错
@Componentpublic class GatewayFilter implements GlobalFilter, Ordered {
//在里面写过滤器的逻辑
@Override
public Mono<Void> filter(ServerWebExchange exchange, GatewayFilterChain chain) {
System.out.println("进入了过滤器");
String token = exchange.getRequest().getQueryParams().getFirst("access-token");
if (token==null){
//如果不存在，认证失败
System.out.println("没有登陆");
exchange.getResponse().setStatusCode(HttpStatus.UNAUTHORIZED);
return exchange.getResponse().setComplete();
}
return chain.filter(exchange);
}
//过滤器的优先级，数值越小，优先级越高
@Override
public int getOrder() {
return 0;
}}
在浏览器中输入：http://localhost:9090/user/1，出现报错，因为没有access-token
在浏览器中输入：http://localhost:9090/user/1?access-token=1，获取正确结果。
# (三) 网关限流 {#三-网关限流}
在实际环境中会遇到这样的问题，同一时间会有许多请求去调用微服务，大量请求的进入很有可能导致微服务被破环，因此限流就变得很重要。
# 3.1 常见的一些限流算法： {#_3-1-常见的一些限流算法}
计数器算法：设定一个单位时间内的计数值，如果单位时间内访问的请求大于这个设定的值，则之后的请求都拒绝。直到单位时间内的值低于这个值才继续接收。
漏桶算法：我们可以把漏桶算法想象成一个漏斗。请求进来时先到漏斗中，然后按设定好的输出速率分配到微服务上。当一下子有很多请求进来时，只能在漏斗上等着。为了控制流量，需要设置两个变量：一个是桶的大小，另一个是漏斗流出的速率。
令牌桶算法：令牌桶算法是对漏桶算法的一种改进，相比于漏桶算法，令牌桶算法能允许一定程度的突发调用。令牌桶算法的原理：在令牌桶算法中，存在一个桶，用来存放固定数量的令牌，令牌会以一定速率放到桶中，桶中的令牌满了之后就不会再放令牌。当一个请求来临时，要先在令牌桶中拿到一个令牌，才能去调用微服务，当令牌桶中没有令牌的时候，后来到的请求就需要等待。令牌桶算法除了可以限流，还允许一定程度的突发调用：比如一个令牌桶的容量是100，在没有请求的时候，令牌桶中的令牌数量是满的。此时如果突然来了100个请求，那么这100个请求都能被立刻执行。
# 3.2 基于Filter的限流实践 {#_3-2-基于filter的限流实践}
SpringCloudGateway官方就提供了基于令牌桶的限流支持，基于其内置的过滤器工厂
RequestRateLimiterGatewayFilterFactory 实现。在过滤器工厂中是通过Redis和lua脚本结合的方
式进行流量控制。所以我们可以通过配置redis，在redis中看到运行的情况。
环境搭建：
首先还是引入相关依赖：
<dependency>
<groupId>org.springframework.cloud</groupId>
<artifactId>spring-cloud-starter-gateway</artifactId></dependency><dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-data-redis-reactive</artifactId></dependency>
修改配置文件：
整段配置文件如下：
server:
port: 9090spring:
application:
name: api-gateway-server #配置redis的参数
redis:
host: localhost port: 6379
#配置SpringCloudGateway的路由
cloud:
gateway:
routes:
- id: user-service #id是自定义的标识
#uri: http://127.0.0.1:9001 #当访问9090端口时，自动把ip和端口替换为此uri
uri: lb://userservice #根据微服务名称拉取请求路径
predicates:
- Path=/user/** #自动匹配/user/**的路径
filters:
- name: RequestRateLimiter args:
#使用SpEL从Spring容器中获取对象
key-resolver: '#{@pathKeyResolver}'
#令牌桶每秒填充的平均速率
redis-rate-limiter.replenishRate: 1
#令牌桶的容量
redis-rate-limiter.burstCapacity: 3
discovery:
locator:
enabled: true #开启根据微服务名称自动转发
lower-case-service-id: true #w微服务名称小写呈现eureka:
client:
service-url:
defaultZone: http://localhost:9000/eureka/ instance:
prefer-ip-address: true
这里需要注意的是第19行开始的过滤器配置，首先要从Spring容器中获取对象，这个对象我们接下来会去创建。其次就是设置令牌桶的填充速率和容量。为了方便观察我设置的比较小。
配置KeyResolver
为了达到不同的限流效果和规则，可以通过实现 KeyResolver 接口，定义不同请求类型的限流键。新建KeyResolverConfiguration类：这里仅仅实现基于路径的限流，即同一路径请求超过令牌桶的限制就会报错。
@Componentpublic class KeyResolverConfiguration{
/*
*基于请求路径的限流
*/
@Bean
public KeyResolver pathKeyResolver(){
//lambda表达式
return exchange -> Mono.just(
exchange.getRequest().getPath().toString()
);// 普通的java写法// return new KeyResolver() {// @Override// public Mono<String> resolve(ServerWebExchange exchange) {// return Mono.just(exchange.getRequest().getPath().toString());// }// };
}}
启动需要用到的微服务后（EurekaApplication、UserApplication、GatewayApplication），在浏览器中输入http://localhost:9090/user/1，看到出现正常的调用。快速刷新页面，当请求无法拿到令牌后，就出现报错：
也可以启动redis，在redis中输入monitor，观察监测数据：
除了基于路径的限流外，还有其他的限流方式，修改KeyResolverConfiguration
@Componentpublic class KeyResolverConfiguration{
/*
*基于请求路径的限流
*/
@Bean
public KeyResolver pathKeyResolver(){
//lambda表达式
return exchange -> Mono.just(
exchange.getRequest().getPath().toString()
);
}
/**
* 基于请求ip的限流
*/
@Bean
public KeyResolver ipkeyResolver(){
return exchange -> Mono.just(
exchange.getRequest().getHeaders().getFirst("X-Forwarded-For")
);
}
/**
* 基于用户的限流
*/
@Bean
public KeyResolver userkeyResolver(){
return exchange -> Mono.just(
exchange.getRequest().getQueryParams().getFirst("user")
);
}}
