(接上章)

目录

6 过滤器

 6.1 局部过滤器

6.1.1 内置局部过滤器

6.2 全局过滤器

6.2.1 内置全局过滤器

6.2.2 自定义全局过滤器

 7 网关限流

7.1 常见的限流算法 

8 网关高可用

---

6 过滤器

三个知识点:

1 作用: 过滤器就是在请求的传递过程中,对请求和响应做一些手脚

2 生命周期: Pre Post

3 分类: 局部过滤器(作用在某一个路由上) 全局过滤器(作用全部路由上)

在Gateway中, Filter的生命周期只有两个：“pre” 和 “post”。

1. PRE： 这种过滤器在请求被路由之前调用。我们可利用这种过滤器实现身份验证、在集群中选择请求的微服务、记录调试信息等。
2. POST：这种过滤器在路由到微服务以后执行。这种过滤器可用来为响应添加标准的HTTP Header、收集统计信息和指标、将响应从微服务发送给客户端等。

   

   Gateway 的Filter从作用范围可分为两种: GatewayFilter与GlobalFilter。 GatewayFilter：应用到单个路由或者一个分组的路由上。 GlobalFilter：应用到所有的路由上。

 6.1 局部过滤器

局部过滤器是针对单个路由的过滤器。

6.1.1 内置局部过滤器

在SpringCloud Gateway中内置了很多不同类型的网关路由过滤器。

https://www.cnblogs.com/zhaoxiangjun/p/13042189.html

内置局部过滤器的使用

server:
  port: 7000
spring:
  application:
    name: api-gateway
  # 配置api
  cloud:
    nacos:
      discovery:
        server-addr: localhost:8848
    gateway:
#      discovery:
#        locator:
#          enabled: true
      routes:
        - id: product_route   # 路由的唯一标识，只要不重复都可以，如果不写默认会通过UUID产生，一般写成被路由的服务名称
          uri: lb://shop-product  # 被路由的地址
          order: 1                     #表示优先级  数字越小优先级越高
          predicates:                  #断言: 执行路由的判断条件
            - Path=/product_serv/**
            - Age=18,60
#            - Before=2020-11-28T00:00:00.000+08:00 # 表示在2020前访问
#            - Method=POST             # 请求方式必须为POST
          filters:                     # 过滤器: 可以在请求前或请求后作一些手脚
            - StripPrefix=1
            - SetStatus=2000

6.2 全局过滤器

全局过滤器作用于所有路由, 无需配置。通过全局过滤器可以实现对权限的统一校验，安全性验证等功能。

6.2.1 内置全局过滤器

SpringCloud Gateway内部也是通过一系列的内置全局过滤器对整个路由转发进行处理如下：

6.2.2 自定义全局过滤器

内置的过滤器已经可以完成大部分的功能，但是对于企业开发的一些业务功能处理，还是需要我们自己编写过滤器来实现的，那么我们一起通过代码的形式自定义一个过滤器，去完成统一的权限校验。

开发中的鉴权逻辑：

1. 当客户端第一次请求服务时，服务端对用户进行信息认证（登录）
2. 认证通过，将用户信息进行加密形成token，返回给客户端aaaa，作为登录凭证
3. 以后每次请求，客户端都携带认证的token
4. 服务端对token进行解密，判断是否有效。

如上图，对于验证用户是否已经登录鉴权的过程可以在网关统一检验。

检验的标准就是请求中是否携带token凭证以及token的正确性。

下面的我们自定义一个GlobalFilter，去校验所有请求的请求参数中是否包含“token”，如何不包含请求参数“token”则不转发路由，否则执行正常的逻辑

自定义全局过滤器 要求：必须实现GlobalFilter,Order接口

@Component
public class AuthGlobalFilter implements GlobalFilter, Ordered {
    @Override
    public Mono<Void> filter(ServerWebExchange exchange, GatewayFilterChain chain) {
        String token = exchange.getRequest().getQueryParams().getFirst("token");
        if(StringUtils.isNotEmpty(token) && StringUtils.equals(token,"admin")){
            return chain.filter(exchange);
        }
         exchange.getResponse().setStatusCode(HttpStatus.UNAUTHORIZED);
        return exchange.getResponse().setComplete();
    }
    //优先级 值越小优先级越高
    @Override
    public int getOrder() {
        return 1;
    }
}

 7 网关限流

7.1 常见的限流算法 

（1） 计数器

计数器限流算法是最简单的一种限流实现方式。其本质是通过维护一个单位时间内的计数器，每次请求计数器加1，当单位时间内计数器累加到大于设定的阈值，则之后的请求都被拒绝，直到单位时间已经过去，再将计数器重置为零。

（2） 漏桶算法

漏桶算法可以很好地限制容量池的大小，从而防止流量暴增。漏桶可以看作是一个带有常量服务时间的单服务器队列，如果漏桶（包缓存）溢出，那么数据包会被丢弃。 在网络中，漏桶算法可以控制端口的流量输出速率，平滑网络上的突发流量，实现流量整形，从而为网络提供一个稳定的流量。

（3） 令牌桶算法

令牌桶算法是对漏桶算法的一种改进，桶算法能够限制请求调用的速率，而令牌桶算法能够在限制调用的平均速率的同时还允许一定程度的突发调用。在令牌桶算法中，存在一个桶，用来存放固定数量的令牌。算法中存在一种机制，以一定的速率往桶中放令牌。每次请求调用需要先获取令牌，只有拿到令牌，才有机会继续执行，否则选择选择等待可用的令牌、或者直接拒绝。放令牌这个动作是持续不断的进行，如果桶中令牌数达到上限，就丢弃令牌，所以就存在这种情况，桶中一直有大量的可用令牌，这时进来的请求就可以直接拿到令牌执行，比如设置qps为100，那么限流器初始化完成一秒后，桶中就已经有100个令牌了，这时服务还没完全启动好，等启动完成对外提供服务时，该限流器可以抵挡瞬时的100个请求。所以，只有桶中没有令牌时，请求才会进行等待，最后相当于以一定的速率执行。

8 网关高可用

高可用HA（High Availability）是分布式系统架构设计中必须考虑的因素之一，它通常是指，通过设计减少系统不能提供服务的时间。我们都知道，单点是系统高可用的大敌，单点往往是系统高可用最大的 风险和敌人，应该尽量在系统设计的过程中避免单点。方法论上，高可用保证的原则是“集群化”，或者叫“冗余”：只有一个单点，挂了服务会受影响；如果有冗余备份，挂了还有其他backup能够顶上。 ngnix linux

我们实际使用 Spring Cloud Gateway 的方式如上图，不同的客户端使用不同的负载将请求分发到后端的 Gateway，Gateway 再通过HTTP调用后端服务，最后对外输出。因此为了保证 Gateway 的高可用性，前端可以同时启动多个 Gateway 实例进行负载，在 Gateway 的前端使用 Nginx 或者 F5 进行负载转发以达到高可用性。

（1） 准备多个GateWay工程

修改 shop_gateway_server8080 的application.yml。添加如下配置

server:
  port: 80
​
spring:
  application:
    name: shop-gateway-server
  cloud:
    gateway:
      routes:
        - id: product_service #路由的ID，没有固定规则但要求唯一，简易配合服务名
          uri: lb://shop-product-service        #匹配后提供服务的路由地址
          predicates:
            #- Path=/product/**          #断言，路径相匹配的进行路由
            - Path=/product-service/**
          filters:
            - RewritePath=/product-service/(?<segment>.*), /$\{segment}
      discovery:
        locator:
          enabled: true  # 开启微服务名称转发
          lower-case-service-id: true  #微服务名小写
​
eureka:
  client:
    service-url:
      defaultZone: http://localhost:7001/eureka/
      registry-fetch-interval-seconds: 5 # 获取服务列表的周期：5s
    instance:
      preferIpAddress: true
      ip-address: 127.0.0.1

通过不同的profifiles配置启动两个网关服务，请求端口分别为8080和8081。浏览器验证发现效果是一致的.

（2） 配置ngnix

找到ngnix添加负载均衡配置

#配置多台服务器（这里只在一台服务器上的不同端口） 
upstream gateway { 
  server 127.0.0.1:8081; 
  server 127.0.0.1:8080; 
}
#请求转向mysvr 定义的服务器列表 
location / { 
  proxy_pass http://gateway; 
}

在浏览器上通过访问http://localhost/product-service/product/2请求的效果和之前是一样的。这次关闭一台网关服务器，还是可以支持部分请求的访问。