SpringCloud第四课（gateway网关详解、gateway统一鉴权、令牌桶算法、基于Filter限流、基于Sentinel限流、网关高可用）

最新推荐文章于 2024-08-28 10:17:44 发布

小吕努力变强

最新推荐文章于 2024-08-28 10:17:44 发布

阅读量1.6k

点赞数

分类专栏： java springcloud springboot 文章标签： spring java spring cloud gateway sentinel

本文链接：https://blog.csdn.net/qq_48033003/article/details/120498251

版权

java 同时被 3 个专栏收录

69 篇文章 1 订阅

订阅专栏

springboot

18 篇文章 0 订阅

订阅专栏

springcloud

7 篇文章 0 订阅

订阅专栏

SpringCloud第四课（gateway网关详解、gateway统一鉴权、令牌桶算法、基于Filter限流、基于Sentinel限流、网关高可用）

前言

上文文章（Hystrix监控平台、DashBoard、Turbine监控、熔断器的状态、微服务网关Zuul）

本文目录

文章目录

SpringCloud第四课（gateway网关详解、gateway统一鉴权、令牌桶算法、基于Filter限流、基于Sentinel限流、网关高可用）

微服务网关GateWay

Zuul网关存在的问题

在实际使用中我们会发现直接使用Zuul会存在诸多问题，包括：

性能问题

Zuul1x版本本质上就是一个同步Servlet，采用多线程阻塞模型进行请求转发。简单讲，每来
一个请求，Servlet容器要为该请求分配一个线程专门负责处理这个请求，直到响应返回客户
端这个线程才会被释放返回容器线程池。如果后台服务调用比较耗时，那么这个线程就会被
阻塞，阻塞期间线程资源被占用，不能干其它事情。我们知道Servlet容器线程池的大小是有
限制的，当前端请求量大，而后台慢服务比较多时，很容易耗尽容器线程池内的线程，造成容器无法接受新的请求。

不支持任何长连接，如websocket

Zuul网关的替换方案

SpringCloud Gateway

微服务网关GateWay简介

Zuul 1.x 是一个基于阻塞 IO 的 API Gateway 以及 Servlet；直到 2018 年 5 月，Zuul 2.x（基于
Netty，也是非阻塞的，支持长连接）才发布，但 Spring Cloud 暂时还没有整合计划。Spring Cloud
Gateway 比 Zuul 1.x 系列的性能和功能整体要好。

Spring Cloud Gateway 是 Spring 官方基于 Spring 5.0，Spring Boot 2.0 和 Project Reactor 等技术开发的网关，旨在为微服务架构提供一种简单而有效的统一的 API 路由管理方式，统一访问接口。SpringCloud Gateway 作为 Spring Cloud 生态系中的网关，目标是替代 Netflix ZUUL，其不仅提供统一的路由方式，并且基于 Filter 链的方式提供了网关基本的功能，例如：安全，监控/埋点，和限流等。它是基于Nttey的响应式开发模式。

核心概念

路由（route）路由是网关最基础的部分，路由信息由一个ID、一个目的URL、一组断言工厂和一
组Filter组成。如果断言为真，则说明请求URL和配置的路由匹配。
断言（predicates） Java8中的断言函数，Spring Cloud Gateway中的断言函数输入类型是
Spring5.0框架中的ServerWebExchange。Spring Cloud Gateway中的断言函数允许开发者去定
义匹配来自Http Request中的任何信息，比如请求头和参数等。
过滤器（filter）一个标准的Spring webFilter，Spring Cloud Gateway中的Filter分为两种类型，
分别是Gateway Filter和Global Filter。过滤器Filter可以对请求和响应进行处理。

搭建gateway项目模块

创建项目导入依赖

 		<dependency>
            <groupId>org.springframework.cloud</groupId>
            <artifactId>spring-cloud-starter-gateway</artifactId>
        </dependency>

注意：

SpringCloud Gateway使用的web框架为webflux，和SpringMVC不兼容。引入的限流组件是hystrix。redis底层不再使用jedis，而是lettuce
意思就是说不能存在web的启动器，不然会报错，如下

配置启动类

package cn.ebuy.gateway;


import org.springframework.boot.SpringApplication;
import org.springframework.boot.autoconfigure.SpringBootApplication;

@SpringBootApplication
public class GatewayServerApplication {

        public static void main(String[] args) {
        SpringApplication.run(GatewayServerApplication.class, args);
    }
}

编写配置文件

创建 application.yml 配置文件

server:
  port: 9091
spring:
  application:
    name: ebuy-gateway #服务名称
  cloud:
    gateway:
      routes:
          # 第一种 不支持负载均衡 http://localhost:9091/product/816753
      - id: ebuy-product
        uri: http://127.0.0.1:6501
        predicates:
          - Path=/product/**
logging:
  level:
    cn.ebuy: DEBUG

释义：

id：我们自定义的路由 ID，保持唯一
uri：目标服务地址
predicates：路由条件，Predicate 接受一个输入参数，返回一个布尔值结果。该接口包含多种默认方法来将 Predicate 组合成其他复杂的逻辑（比如：与，或，非）。
filters：过滤规则，暂时没用。

启动测试

服务详情信息

访问测试
上图的意思是指访问路由路径http://localhost:9091/product/会自动转发至http://localhost:6501/product/地址，所以修改Path=/**，可以实现http://localhost:9091会自动转发至http://localhost:6501地址（不再演示）

动态路由

和zuul网关类似，在SpringCloud GateWay中也支持动态路由：即自动的从注册中心中获取服务列表并
访问。

添加注册中心依赖

在工程的pom文件中添加注册中心的客户端依赖（这里以Eureka为例）

<dependency>
<groupId>org.springframework.cloud</groupId>
<artifactId>spring-cloud-starter-netflix-eureka-client</artifactId>
</dependency>

配置动态路由

修改 application.yml 配置文件，添加eureka注册中心的相关配置，并修改访问映射的URL为服务名称

server:
  port: 9091
spring:
  application:
    name: ebuy-gateway #服务名称
  cloud:
    gateway:
      routes:
          # 第一种 不支持负载均衡 http://localhost:9091/product/816753
#      - id: ebuy-product
#        uri: http://127.0.0.1:6501
#        predicates:
#          - Path=/product/**
        # 第二种 支持负载均衡，但只支持一个命令空间 http://localhost:9091/product/816753
      - id: ebuy-product
        uri: lb://ebuy-product
        predicates:
          - Path=/product/**
logging:
  level:
    cn.ebuy: DEBUG
eureka:
  client:
    service-url:
      defaultZone: http://127.0.0.1:6001/eureka/,http://127.0.0.1:6002/eureka/
  instance:
    instance-id: ${spring.cloud.client.ip-address}:${server.port} #实例id
    prefer-ip-address: true #使用ip地址注册
    lease-expiration-duration-in-seconds: 10 #eureka client发送心跳给server端后，续约到期时间（默认90秒）
    lease-renewal-interval-in-seconds: 5 #发送心跳续约时间间隔

重启服务

重启ebuy-gateway服务，并且开启第二个ebuy-product服务

访问测试

同样该配置只能访问请求连接以/product/开始的路径，我们可以修改Path=/**，这样就可以映射ebuy-product的任何服务了，配置如下：

        # 第三种 映射该服务下全部路径 http://localhost:9091/product2/816753
#      - id: ebuy-product
#        uri: lb://ebuy-product
#        predicates:
#          - Path=/**

不再演示。

添加RewritePath重写转发路径
修改 application.yml ，添加重写规则。

      # 第四种 添加RewritePath重写转发路径 http://localhost:9091/ebuy-product/product2/816753
      - id: ebuy-product
        uri: lb://ebuy-product
        predicates:
          - Path=/ebuy-product/**
        filters:
          - RewritePath=/ebuy-product/(?<segment>.*), /$\{segment}

请求服务

过滤器

Spring Cloud Gateway除了具备请求路由功能之外，也支持对请求的过滤。通过Zuul网关类似，也是通过过滤器的形式来实现的。那么接下来我们一起来研究一下Gateway中的过滤器

过滤器基础

过滤器的生命周期

Spring Cloud Gateway 的 Filter 的生命周期不像 Zuul 的那么丰富，它只有两个：“pre” 和 “post”。

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

示意图：

过滤器类型

Spring Cloud Gateway的Filter从作用范围可分为另外两种Gateway和GlobalFilter。

GatewayFilter：应用到单个路由或者一个分组的路由上。
GlobalFilter：应用到所有的路由上

局部过滤器

局部过滤器（GatewayFilter），是针对单个路由的过滤器。可以对访问的URL过滤，进行切面处理。在Spring Cloud Gateway中通过GatewayFilter的形式内置了很多不同类型的局部过滤器。这里简单将Spring Cloud Gateway内置的所有过滤器工厂整理成了一张表格，虽然不是很详细，但能作为速览使
用。

如下：

—
每个过滤器工厂都对应一个实现类，并且这些类的名称必须以 GatewayFilterFactory 结尾，这是Spring Cloud Gateway的一个约定，例如 AddRequestHeader 对应的实现类为AddRequestHeaderGatewayFilterFactory 。对于这些过滤器的使用方式可以参考官方文档

全局过滤器

全局过滤器（GlobalFilter）作用于所有路由，Spring Cloud Gateway 定义了Global Filter接口，用户
可以自定义实现自己的Global Filter。通过全局过滤器可以实现对权限的统一校验，安全性验证等功
能，并且全局过滤器也是程序员使用比较多的过滤器。
Spring Cloud Gateway内部也是通过一系列的内置全局过滤器对整个路由转发进行处理如下：

图示

统一鉴权

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

鉴权逻辑

开发中的鉴权逻辑：

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

流程图：

如上图，对于验证用户是否已经登录鉴权的过程可以在网关层统一检验，检验的标准就是请求中是否携带token凭证以及token的正确性。

代码实现

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

package cn.ebuy.gateway.filter;

import org.springframework.cloud.gateway.filter.GatewayFilterChain;
import org.springframework.cloud.gateway.filter.GlobalFilter;
import org.springframework.core.Ordered;
import org.springframework.http.HttpStatus;
import org.springframework.stereotype.Component;
import org.springframework.web.server.ServerWebExchange;
import reactor.core.publisher.Mono;

@Component
public class AuthorizeFilter implements GlobalFilter, Ordered {

    @Override
    public Mono<Void> filter(ServerWebExchange exchange, GatewayFilterChain chain) {
        String token= exchange.getRequest().getQueryParams().getFirst("token");
        if (token==null || token.equals("")){
            //当token为null 或者 token为空时

            // 设置返回状态值为 401 Unauthorized
            exchange.getResponse().setStatusCode(HttpStatus.UNAUTHORIZED);
            return exchange.getResponse().setComplete();
        }
        //如果有token认证，则放行
        return chain.filter(exchange);
    }

    //过滤级别 值越低，越优先执行
    @Override
    public int getOrder() {
        return 0;
    }
}

自定义全局过滤器需要实现GlobalFilter和Ordered接口。
在filter方法中完成过滤器的逻辑判断处理
在getOrder方法指定此过滤器的优先级，返回值越大级别越低
ServerWebExchange 就相当于当前请求和响应的上下文，存放着重要的请求-响应属性、请求实
例和响应实例等等。一个请求中的request，response都可以通过 ServerWebExchange 获取
调用 chain.filter 继续向下游执行

启动服务如下：

未携带token，经过gateway网关请求服务

携带token请求服务：

注：我就简单的写了一个token参数，并没有配置token的规则，所以token任何值都可以

网关限流

常见的限流算法

计数器

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

图解

漏桶算法

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

图解：

为了更好的控制流量，漏桶算法需要通过两个变量进行控制：一个是桶的大小，支持流量突发增多时可
以存多少的水（burst），另一个是水桶漏洞的大小（rate）。

令牌桶算法

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

基于Filter的限流

SpringCloudGateway官方就提供了基于令牌桶的限流支持。基于其内置的过滤器工厂RequestRateLimiterGatewayFilterFactory
实现。在过滤器工厂中是通过Redis和lua脚本结合的方式进行流量控制。

环境搭建

导入redis的依赖

<!--gateway网关-->
        <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>
        <!--基于令牌桶的限流-->
        <dependency>
            <groupId>org.springframework.boot</groupId>
            <artifactId>spring-boot-starter-data-redis-reactive</artifactId>
        </dependency>

启动redis

修改application.yml配置文件

在application.yml配置文件中加入限流的配置，代码如下：

server:
  port: 9091
spring:
  application:
    name: ebuy-gateway #服务名称
  cloud:
    gateway:
      routes:
          # 第一种 不支持负载均衡 http://localhost:9091/product/816753
#      - id: ebuy-product
#        uri: http://127.0.0.1:6501
#        predicates:
#          - Path=/product/**
        # 第二种 支持负载均衡，但只支持一个命令空间 http://localhost:9091/product/816753
#      - id: ebuy-product
#        uri: lb://ebuy-product
#        predicates:
#          - Path=/product/**
        # 第三种 映射该服务下全部路径 http://localhost:9091/product2/816753
#      - id: ebuy-product
#        uri: lb://ebuy-product
#        predicates:
#          - Path=/**
        # 第四种 添加RewritePath重写转发路径 http://localhost:9091/ebuy-product/product2/816753
        - id: ebuy-product
          uri: lb://ebuy-product
          predicates:
            - Path=/ebuy-product/**
          filters:
            - RewritePath=/ebuy-product/(?<segment>.*), /$\{segment}
            - name: RequestRateLimiter
              args:
#            使用SpEL从容器中获取对象
                key-resolver: '#{@pathKeyResolver}'
#            令牌桶每秒填充平均速率
                redis-rate-limiter.replenishRate: 1
#            令牌桶的总容量
                redis-rate-limiter.burstCapacity: 1
  redis:
    host: localhost
    port: 6379
    password: 123456
logging:
  level:
    cn.ebuy: DEBUG
eureka:
  client:
    service-url:
      defaultZone: http://127.0.0.1:6001/eureka/,http://127.0.0.1:6002/eureka/
  instance:
    instance-id: ${spring.cloud.client.ip-address}:${server.port} #实例id
    prefer-ip-address: true #使用ip地址注册
    lease-expiration-duration-in-seconds: 10 #eureka client发送心跳给server端后，续约到期时间（默认90秒）
    lease-renewal-interval-in-seconds: 5 #发送心跳续约时间间隔

改动标注：

注意标签的父子关系，避免出错

在 application.yml 中添加了redis的信息，并配置了RequestRateLimiter的限流过滤器：

burstCapacity，令牌桶总容量。
replenishRate，令牌桶每秒填充平均速率。
key-resolver，用于限流的键的解析器的 Bean 对象的名字。它使用 SpEL 表达式根据#{@beanName}从 Spring 容器中获取 Bean 对象。

配置KeyResolver的bean对象

为了达到不同的限流效果和规则，可以通过实现 KeyResolver 接口，定义不同请求类型的限流键。（请求键就是请求url上的参数）

package cn.ebuy.gateway;


import org.springframework.boot.SpringApplication;
import org.springframework.boot.autoconfigure.SpringBootApplication;
import org.springframework.cloud.gateway.filter.ratelimit.KeyResolver;
import org.springframework.context.annotation.Bean;
import reactor.core.publisher.Mono;

@SpringBootApplication
public class GatewayServerApplication {
    /**
     * 基于请求路径的限流
     */
    @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")
        );
    }
    /**
     * 基于用户的限流
     */
//    @Bean
    public KeyResolver userKeyResolver() {
        return exchange -> Mono.just(
                exchange.getRequest().getQueryParams().getFirst("user")
        );
    }
    //    @Bean
    public KeyResolver remoteAddressKeyResolver() {
        return exchange -> Mono.just(
                exchange.getRequest().getRemoteAddress().getHostName()
        );
    }


    public static void main(String[] args) {
        SpringApplication.run(GatewayServerApplication.class, args);
    }
}

注意：以上几种策略只能保存一种，并且beanname对应上面配置文件中的#{@beanName}。

测试

测试根据请求路径的限流

将@Bean的的注释标签去掉
然后重启服务
接着请求服务

正常请求：

然后你上面配置文件配置了限流规则，可以尝试快速刷新，可以看到如下：

即是请求地址被限流了！

测试基于用户的限流

同样打开userKeyResolver的@Bean标签,并将配置文件中的beanname修改为userKeyResolver（记得把上面的请求路径的@Bean注释）
然后重启服务

不加user参数，直接报错

添加user参数，未被限流的情况

被限流的情况（尝试多次快速刷新）

其他例子不再展示（同上）

查看redis的信息

查看redis的信息

timestamp:存储的是当前时间的秒数，也就是System.currentTimeMillis() / 1000或者
Instant.now().getEpochSecond()。
tokens:存储的是当前这秒钟的对应的可用的令牌数量

Spring Cloud Gateway目前提供的限流还是相对比较简单的，在实际中我们的限流策略会有很多种情
况，比如：

对不同接口的限流
被限流后的友好提示

这些可以通过自定义RedisRateLimiter来实现自己的限流策略，这里我们不做讨论

基于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 分组维度进行限流。

环境搭建

导入Sentinel的响应依赖（redis同样还是需要的）


        <!--sentinel限流-->
        <dependency>
            <groupId>com.alibaba.csp</groupId>
            <artifactId>sentinel-spring-cloud-gateway-adapter</artifactId>
            <version>1.6.3</version>
        </dependency>

编写配置类

package cn.ebuy.gateway.util;

import com.alibaba.csp.sentinel.adapter.gateway.common.SentinelGatewayConstants;
import com.alibaba.csp.sentinel.adapter.gateway.common.api.ApiDefinition;
import com.alibaba.csp.sentinel.adapter.gateway.common.api.ApiPathPredicateItem;
import com.alibaba.csp.sentinel.adapter.gateway.common.api.ApiPredicateItem;
import com.alibaba.csp.sentinel.adapter.gateway.common.api.GatewayApiDefinitionManager;
import com.alibaba.csp.sentinel.adapter.gateway.common.rule.GatewayFlowRule;
import com.alibaba.csp.sentinel.adapter.gateway.common.rule.GatewayRuleManager;
import com.alibaba.csp.sentinel.adapter.gateway.sc.SentinelGatewayFilter;
import com.alibaba.csp.sentinel.adapter.gateway.sc.callback.BlockRequestHandler;
import com.alibaba.csp.sentinel.adapter.gateway.sc.callback.GatewayCallbackManager;
import com.alibaba.csp.sentinel.adapter.gateway.sc.exception.SentinelGatewayBlockExceptionHandler;
import org.springframework.beans.factory.ObjectProvider;
import org.springframework.cloud.gateway.filter.GlobalFilter;
import org.springframework.context.annotation.Bean;
import org.springframework.context.annotation.Configuration;
import org.springframework.core.Ordered;
import org.springframework.core.annotation.Order;
import org.springframework.http.HttpStatus;
import org.springframework.http.MediaType;
import org.springframework.http.codec.ServerCodecConfigurer;
import org.springframework.web.reactive.function.BodyInserters;
import org.springframework.web.reactive.function.server.ServerResponse;
import org.springframework.web.reactive.result.view.ViewResolver;
import org.springframework.web.server.ServerWebExchange;
import reactor.core.publisher.Mono;

import javax.annotation.PostConstruct;
import java.util.*;

@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();
    }

    /**
     * 配置初始化的限流参数
     */
    @PostConstruct
    public void initGatewayRules() {
        Set<GatewayFlowRule> rules = new HashSet<>();
        rules.add(
                new GatewayFlowRule("ebuy-product") //资源名称 服务名
                        .setCount(1) // 限流阈值
                        .setIntervalSec(1) // 统计时间窗口，单位是秒，默认是 1 秒

        );

        GatewayRuleManager.loadRules(rules);
    }
    
}

注：配置初始化的限流参数中的rules是一个set集合，也就是说你可以加入多个服务名，为多个服务进行限流。（上面的代码只给ebuy-product配置了限流，你可以给ebuy-order等配置限流，前提是你的配置文件中配置了该服务的路由转发。）

修改启动类

注释掉前面配置的基于Filter的限流的Bean

修改配置文件

在这里插入图片描述

重启服务

重启gateway网关服务之后，再次请求未限流的状态：

尝试快速多次刷新，如下：

但是这样的限流提示太过不够人性化，所以sentinel提供了一种更加友好的限流提示配置，往下看！

自定义异常提示

当触发限流后页面显示的是Blocked by Sentinel: FlowException。为了展示更加友好的限流提示，
Sentinel支持自定义异常处理。
您可以在 GatewayCallbackManager 注册回调进行定制：

setBlockHandler ：注册函数用于实现自定义的逻辑处理被限流的请求，对应接口为BlockRequestHandler 。默认实现为 DefaultBlockRequestHandler ，当被限流时会返回类似于下面的错误信息： Blocked by Sentinel: FlowException 。

在刚才的配置类中加入如下：

    @PostConstruct
    public void initBlockHandlers() {
        BlockRequestHandler blockRequestHandler = new BlockRequestHandler() {
            public Mono<ServerResponse> handleRequest(ServerWebExchange
                                                              serverWebExchange, Throwable throwable) {
                Map map = new HashMap<>();
                map.put("code", 001);
                map.put("message", "对不起,接口限流了");
                return ServerResponse.status(HttpStatus.OK).
                        contentType(MediaType.APPLICATION_JSON_UTF8).
                        body(BodyInserters.fromObject(map));
            }
        };
        GatewayCallbackManager.setBlockHandler(blockRequestHandler);
    }

在这里插入图片描述

再次重启服务测试

此时限流提示为：

参数限流

顾名思义：就是不直接给整个微服务资源限流，而是拿到请求的某个参数，对参数进行规则限流。
上面的配置是针对整个路由来限流的，如果我们只想对某个路由的参数做限流，那么可以使用参数限流
方式：
如下：

        rules.add(
                new GatewayFlowRule("ebuy-product") //资源名称 服务名
                        .setCount(1) // 限流阈值
                        .setIntervalSec(1) // 统计时间窗口，单位是秒，默认是 1 秒
                        .setParamItem(new GatewayParamFlowItem()
                                .setParseStrategy(SentinelGatewayConstants.PARAM_PARSE_STRATEGY_URL_PARAM)
                                .setFieldName("id"))
        );

通过指定PARAM_PARSE_STRATEGY_URL_PARAM表示从url中获取参数，setFieldName指定参数名称

图解：

重启服务测试

不加限流参数（id），进行请求：

不同于上面的基于Filter限流（不加限流参数直接报错），基于sentinel限流，参数配置之后不加参数不进行限流处理

— 添加限流参数（id），进行快速多次刷新：

添加参数之后，对其进行限流处理

自定义API分组

    /**
     * 自定限流组(可选)
     */
    @PostConstruct
    private void initCustomizedApis() {
        Set<ApiDefinition> definitions = new HashSet<>();

        //配置 产品服务分组
        ApiDefinition api1 = new ApiDefinition("product-api");
        api1.setPredicateItems(new HashSet<ApiPredicateItem>() {{
                    add(new ApiPathPredicateItem().setPattern("/ebuy-product/product/**").
                            setMatchStrategy(SentinelGatewayConstants.URL_MATCH_STRATEGY_PREFIX));
                }});
        definitions.add(api1);
        GatewayApiDefinitionManager.loadApiDefinitions(definitions);
    }

图解：

如需配置多个分组，可以创建多个ApiDefinition 然后配置配置初始化的限流参数，如下：

接下来说一下网关的高可用。

网关高可用

由于微服务架构中，客户端一切的请求都要经过网关转发请求，所以网关的工作压力是非常大的，所以搭建集群尤其重要。

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

实现原理图：

使用nginx反向代理我们的服务端

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

修改配置文件

直接修改application.yml中的端口，启动两个gateway服务。

如下：

然后访问测试下，如下：

配置nginx

下载解压过程不再演示，可以看之前的文章（nginx文章）

配置如下：

代码如下：


	upstream gateway{
		server 127.0.0.1:9091;
		server 127.0.0.1:9092;
	}
        location / {
			proxy_pass http://gateway;
        }

然后启动nginx，如下：

这样就启动成功了，nginx的默认端口是80

测试

访问服务，如下：

测试关闭一个gateway服务，访问测试（过程不再展示）

执行流程分析

流程图：

Spring Cloud Gateway 核心处理流程如上图所示，Gateway的客户端向 Spring Cloud Gateway 发送请求，请求首先被 HttpWebHandlerAdapter 进行提取组装成网关上下文，然后网关的上下文会传递到 DispatcherHandler 。
DispatcherHandler 是所有请求的分发处理器， DispatcherHandler 主要
负责分发请求对应的处理器。比如请求分发到对应的 RoutePredicateHandlerMapping （路由断言处
理映射器）。路由断言处理映射器主要作用用于路由查找，以及找到路由后返回对应的FilterWebHandler 。 FilterWebHandler 主要负责组装Filter链并调用Filter执行一系列的Filter处理，然后再把请求转到后端对应的代理服务处理，处理完毕之后将Response返回到Gateway客户端。