当前位置:   article > 正文

微服务--Gateway--服务网关_网关转发请求到服务做了些什么

网关转发请求到服务做了些什么

5.1 网关简介

大家都都知道在微服务架构中,一个系统会被拆分为很多个微服务。那么作为客户端(pc androud ios 平板)要如何去调用这么多的微服务呢?如果没有网关的存在,我们只能在客户端记录每个微服务的地址,然后分别去调用。 axios.get(ip:port/url)   axios.get(ip:port/url)

这样的架构,会存在着诸多的问题:

  1. 客户端多次请求不同的微服务,增加客户端代码或配置编写的复杂性
  2. 认证复杂,每个服务都需要独立认证。
  3. 存在跨域请求,在一定场景下处理相对复杂。

(跨域: 浏览器的ajax从一个地址访问另一个地址:

   协议://ip:port  如果三则有一个不同,则会出现跨域问题

    http://192.168.10.11:8080 ----->https://192.168.10.11:8080

    http://127.0.0.1:8080--->http://localhost:8080  跨域

上面的这些问题可以借助API网关来解决。

所谓的API网关,就是指系统的统一入口,它封装了应用程序的内部结构,为客户端提供统一服 务,一些与业务本身功能无关的公共逻辑可以在这里实现,诸如认证、鉴权、监控(黑白名单)、路由转发等等。 添加上API网关之后,系统的架构图变成了如下所示:

在业界比较流行的网关,有下面这些:

  1. Ngnix+lua

使用nginx的反向代理和负载均衡可实现对api服务器的负载均衡及高可用

lua是一种脚本语言,可以来编写一些简单的逻辑, nginx支持lua脚本

  1. Kong

基于Nginx+Lua开发,性能高,稳定,有多个可用的插件(限流、鉴权等等)可以开箱即用。 问题:

只支持Http协议;二次开发,自由扩展困难;提供管理API,缺乏更易用的管控、配置方式。

  1. Zuul 1.0(慢 servlet 2.0 ) zuul2.0 没出来。

Netflix开源的网关,功能丰富,使用JAVA开发,易于二次开发 问题:缺乏管控,无法动态配

置;依赖组件较多;处理Http请求依赖的是Web容器,性能不如Nginx

  1. Spring Cloud Gateway

Spring公司为了替换Zuul而开发的网关服务,将在下面具体介绍。

注意:SpringCloud alibaba技术栈中并没有提供自己的网关,我们可以采用Spring Cloud Gateway来做网关

5.2 Gateway简介

Spring Cloud GatewaySpring公司基于Spring 5.0Spring Boot 2.0  Project Reactor 等术开发的网关,它旨在为微服务架构提供一种简单有效的统一的 API 路由管理方式。它的目标是替代 Netflix Zuul,其不仅提供统一的路由方式,并且基于 Filter 的方式提供了网关基本的功能,例如:安全,监控和限流。

优点:

  1. 性能强劲:是第一代网关Zuul1.6
  2. 功能强大:内置了很多实用的功能,例如转发、监控、限流等
  3. 设计优雅,容易扩展.

缺点:  

  1. 其实现依赖NettyWebFlux,不是传统的Servlet编程模型,学习成本高
  2. 不能将其部署在TomcatJettyServlet容器里,只能打成jar包执行 web.Jar
  3. 需要Spring Boot 2.0及以上的版本,才支持

gateway内置了服务器 netty服务器。

5.3 Gateway快速入门

要求: 通过浏览器访问api网关,然后通过网关将请求转发到商品微服。

5.3.1 创建一个api-gateway的工程并加入依赖

  1. <!--加入gateway的依赖-->
  2. <dependency>
  3. <groupId>org.springframework.cloud</groupId>
  4. <artifactId>spring-cloud-starter-gateway</artifactId>
  5. </dependency>

 5.3.2 创建启动类

  1. import org.springframework.boot.SpringApplication;
  2. import org.springframework.boot.autoconfigure.SpringBootApplication;
  3. @SpringBootApplication
  4. public class GetaweyApp {
  5. public static void main(String[] args) {
  6. SpringApplication.run(GetaweyApp.class,args);
  7. }
  8. }

 5.3.3 修改配置文件

  1. server:
  2. port: 7000
  3. spring:
  4. application:
  5. name: api-gateway
  6. # 配置api
  7. cloud:
  8. gateway:
  9. routes:
  10. - id: product_route # 路由的唯一标识,只要不重复都可以,如果不写默认会通过UUID产生,一般写成被路由的服务名称
  11. uri: http://localhost:8081/ # 被路由的地址
  12. order: 1 #表示优先级 数字越小优先级越高
  13. predicates: #断言: 执行路由的判断条件
  14. - Path= /product_serv/**
  15. filters: # 过滤器: 可以在请求前或请求后作一些手脚
  16. - StripPrefix=1

5.3.4启动项目, 并通过网关去访问微服务 

5.3.2 增强版

现在在配置文件中写死了转发路径的地址, 前面我们已经分析过地址写死带来的问题, 接下来我们从注册中心获取此地址

第1步:加入nacos依赖

  1. <dependency>
  2. <groupId>com.alibaba.cloud</groupId>
  3. <artifactId>spring-cloud-alibaba-nacos-discovery</artifactId>
  4. </dependency>

 第2步:在主启动类上加入服务发现的注解

  1. @SpringBootApplication
  2. @EnableDiscoveryClient
  3. public class ApiGatewayApplication {
  4. public static void main(String[] args) {
  5. SpringApplication.run(ApiGatewayApplication.class,args);
  6. }
  7. }

第3步:修改application.yml的配置文件

  1. server:
  2. port: 7000
  3. spring:
  4. application:
  5. name: api-gateway
  6. # 配置api
  7. cloud:
  8. gateway:
  9. routes:
  10. - id: product_route # 路由的唯一标识,只要不重复都可以,如果不写默认会通过UUID产生,一般写成被路由的服务名称
  11. uri: lb://shop-product # 被路由的地址
  12. order: 1 #表示优先级 数字越小优先级越高
  13. predicates: #断言: 执行路由的判断条件
  14. - Path=/product_serv/**
  15. filters: # 过滤器: 可以在请求前或请求后作一些手脚
  16. - StripPrefix=1
  17. nacos:
  18. discovery:
  19. server-addr: localhost:8848

5.3.3 简写版

1: 去掉关于路由的配置

  1. server:
  2. port: 7000
  3. spring:
  4. application:
  5. name: api-gateway
  6. # 配置api
  7. cloud:
  8. nacos:
  9. discovery:
  10. server-addr: localhost:8848
  11. gateway:
  12. discovery:
  13. locator:
  14. enabled: true

2: 启动项目,并通过网关去访问微服务

这时候,就发现只要按照网关地址/微服务/接口的格式去访问,就可以得到成功响应

5.4 Gateway核心架构

5.4.1 基本概念

路由(Route)  gateway 中最基本的组件之一,表示一个具体的路由信息载体。主要定义了下面的几个信息:

  1. id,路由标识符,区别于其他 Route。默认生成一个
  2. uri,路由指向的目的地 uri,即客户端请求最终被转发到的微服务。
  3. order,用于多个 Route 之间的排序,数值越小排序越靠前,匹配优先级越高。
  4. predicate,断言的作用是进行条件判断,只有断言都返回真,才会真正的执行路由。 
  5. filter,过滤器用于修改请求响应信息

5.4.2 执行流程

执行流程大体如下:

1. Gateway ClientGateway Server发送请求

2. 请求首先会被HttpWebHandlerAdapter进行提取组装成网关上下文

3. 然后网关的上下文会传递到DispatcherHandler,它负责将请求分发给 RoutePredicateHandlerMapping

4. RoutePredicateHandlerMapping负责路由查找,并根据路由断言判断路由是否可用

5. 如果过断言成功,由FilteringWebHandler创建过滤器链并调用

6. 请求会一次经过PreFilter--微服务--PostFilter的方法,最终返回响应

5.5 断言 

Predicate(断言, 谓词) 用于进行条件判断,只有断言都返回真,才会真正的执行路由。

断言就是说: 什么条件下 才能进行路由转发

5.5.1 内置路由断言工厂

SpringCloud Gateway包括许多内置的断言工厂,所有这些断言都与HTTP请求的不同属性匹配体如下:

1.基于Datetime类型的断言工厂

此类型的断言根据时间做判断,主要有三个:

AfterRoutePredicateFactory: 接收一个日期参数,判断请求日期是否晚于指定日期

BeforeRoutePredicateFactory: 接收一个日期参数,判断请求日期是否早于指定日期

BetweenRoutePredicateFactory: 接收两个日期参数,判断请求日期是否在指定时间段内

-After=2019-12-31T23:59:59.789+08:00[Asia/Shanghai]

2.基于远程地址的断言工厂 RemoteAddrRoutePredicateFactory

接收一个IP地址段,判断请求主机地址是否在地址段中

-RemoteAddr=192.168.1.1/24

3.基于Cookie的断言工厂

CookieRoutePredicateFactory:接收两个参数,cookie 名字和一个正则表达式。 判断请求

cookie是否具有给定名称且值与正则表达式匹配。

-Cookie=chocolate, ch.

4.基于Header的断言工厂

HeaderRoutePredicateFactory:接收两个参数,标题名称和正则表达式。 判断请求Header是否

具有给定名称且值与正则表达式匹配。 key value

-Header=X-Request-Id, \d+

5.基于Host的断言工厂

HostRoutePredicateFactory:接收一个参数,主机名模式。判断请求的Host是否满足匹配规则。

-Host=**.testhost.org  

6.基于Method请求方法的断言工厂

MethodRoutePredicateFactory:接收一个参数,判断请求类型是否跟指定的类型匹配。

-Method=GET

7.基于Path请求路径的断言工厂

PathRoutePredicateFactory:接收一个参数,判断请求的URI部分是否满足路径规则。

-Path=/foo/{segment}基于Query请求参数的断言工厂

QueryRoutePredicateFactory :接收两个参数,请求param和正则表达式, 判断请求参数是否具

给定名称且值与正则表达式匹配

-Query=baz, ba.   

8.基于路由权重的断言工厂

WeightRoutePredicateFactory:接收一个[组名,权重], 然后对于同一个组内的路由按照权重转发

routes:

-id: weight_route1 uri: host1 predicates:

-Path=/product/**

-Weight=group3, 1

-id: weight_route2 uri: host2 predicates:

-Path=/product/**

-Weight= group3, 9

内置路由断言工厂的使用

接下来我们验证几个内置断言的使用:

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

 5.5.2 自定义路由断言工厂

我们来设定一个场景: 假设我们的应用仅仅让age(min,max)之间的人来访问。

第1步:在配置文件中,添加一个Age的断言配置

  1. routes:
  2. - id: product_route # 路由的唯一标识,只要不重复都可以,如果不写默认会通过UUID产生,一般写成被路由的服务名称
  3. uri: lb://shop-product # 被路由的地址
  4. order: 1 #表示优先级 数字越小优先级越高
  5. predicates: #断言: 执行路由的判断条件
  6. - Path=/product_serv/**
  7. - Age=18,60

第2步:自定义一个断言工厂, 实现断言方法

  1. //泛型为自定义的一个配置类,该配置类用来存放配置文件中的值
  2. @Component
  3. public class AgeRoutePredicateFactory extends AbstractRoutePredicateFactory<AgeRoutePredicateFactory.Config> {
  4. public AgeRoutePredicateFactory() {
  5. super(AgeRoutePredicateFactory.Config.class);
  6. }
  7. //读取配置文件中的内容并配置给配置类中的属性
  8. public List<String> shortcutFieldOrder() {
  9. return Arrays.asList("minAge","maxAge");
  10. }
  11. public Predicate<ServerWebExchange> apply(AgeRoutePredicateFactory.Config config) {
  12. return (exchange) -> {
  13. String age = exchange.getRequest().getQueryParams().getFirst("age");
  14. if(StringUtils.isNotEmpty(age)){
  15. int a = Integer.parseInt(age);
  16. return a>=config.minAge && a<=config.maxAge;
  17. }
  18. return true;
  19. };
  20. }
  21. @Data
  22. @NoArgsConstructor
  23. public static class Config{
  24. private Integer minAge;
  25. private Integer maxAge;
  26. }
  27. }

 
第3步:启动测试 
#测试发现当age在(18,60)可以访问,其它范围不能访问 

  1. http://localhost:7000/product-serv/product/1?age=30 
  2. http://localhost:7000/product-serv/product/1?age=10

5.6 过滤器

三个知识点:

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

2 生命周期: Pre Post

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

Gateway, Filter的生命周期只有两个:“pre”  “post”

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

Gateway Filter从作用范围可分为两种: GatewayFilterGlobalFilter

  1. GatewayFilter:应用到单个路由或者一个分组的路由上。
  2. GlobalFilter:应用到所有的路由上。

 5.6.1 局部过滤器

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

5.6.1.1 内置局部过滤器

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

Spring Cloud Gateway 内置的过滤器工厂 - 小菜鸟攻城狮 - 博客园

 

 

内置局部过滤器的使用

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

5.6.1.2 自定义局部过滤器 (省略)

第1步:在配置文件中,添加一个Log的过滤器配置

 

  1. filters: # 过滤器: 可以在请求前或请求后作一些手脚
  2. - StripPrefix=1
  3. - SetStatus=2000
  4. - Log=true,false

第2步:自定义一个过滤器工厂,实现方法

  1. import lombok.Data;
  2. import org.springframework.cloud.gateway.filter.GatewayFilter;
  3. import org.springframework.cloud.gateway.filter.GatewayFilterChain;
  4. import org.springframework.cloud.gateway.filter.factory.AbstractGatewayFilterFactory;
  5. import org.springframework.cloud.gateway.filter.factory.SetStatusGatewayFilterFactory;
  6. import org.springframework.cloud.gateway.support.HttpStatusHolder;
  7. import org.springframework.cloud.gateway.support.ServerWebExchangeUtils;
  8. import org.springframework.stereotype.Component;
  9. import org.springframework.web.server.ServerWebExchange;
  10. import reactor.core.publisher.Mono;
  11. import java.util.Arrays;
  12. import java.util.List;
  13. @Component
  14. public class LogGatewayFilterFactory extends AbstractGatewayFilterFactory<LogGatewayFilterFactory.Config> {
  15. public LogGatewayFilterFactory() {
  16. super(LogGatewayFilterFactory.Config.class);
  17. }
  18. public List<String> shortcutFieldOrder() {
  19. return Arrays.asList("consoleLog","cacheLog");
  20. }
  21. @Override
  22. public GatewayFilter apply(Config config) {
  23. return new GatewayFilter() {
  24. @Override
  25. public Mono<Void> filter(ServerWebExchange exchange, GatewayFilterChain chain) {
  26. if(config.cacheLog){
  27. System.out.println("开启缓存日志");
  28. }
  29. if(config.consoleLog){
  30. System.out.println("开启控制台日志");
  31. }
  32. return chain.filter(exchange);
  33. }
  34. };
  35. }
  36. @Data
  37. public static class Config {
  38. private Boolean consoleLog;
  39. private Boolean cacheLog;
  40. public Config() {
  41. }
  42. }
  43. }

第3步:启动测试

5.6.2 全局过滤器

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

5.6.2.1 内置全局过滤器

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

 

5.6.2.2 自定义全局过滤器

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

开发中的鉴权逻辑:

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

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

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

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

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

https://blog.csdn.net/weixin_33701617/article/details/91974422

  1. import org.apache.commons.lang.StringUtils;
  2. import org.springframework.cloud.gateway.filter.GatewayFilterChain;
  3. import org.springframework.cloud.gateway.filter.GlobalFilter;
  4. import org.springframework.core.Ordered;
  5. import org.springframework.http.HttpStatus;
  6. import org.springframework.stereotype.Component;
  7. import org.springframework.web.server.ServerWebExchange;
  8. import reactor.core.publisher.Mono;
  9. @Component
  10. public class AuthGlobalFilter implements GlobalFilter, Ordered {
  11. @Override
  12. public Mono<Void> filter(ServerWebExchange exchange, GatewayFilterChain chain) {
  13. String token = exchange.getRequest().getQueryParams().getFirst("token");
  14. if(StringUtils.isNotEmpty(token) && StringUtils.equals(token,"admin")){
  15. return chain.filter(exchange);
  16. }
  17. exchange.getResponse().setStatusCode(HttpStatus.UNAUTHORIZED);
  18. return exchange.getResponse().setComplete();
  19. }
  20. //优先级 值越小优先级越高
  21. @Override
  22. public int getOrder() {
  23. return 1;
  24. }
  25. }

上面查询解决全局跨域的代码

 Gateway挂了。

5.7 网关限流

5.7.1 常见的限流算法 

(1) 计数器

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

(2) 漏桶算法

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

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

(3) 令牌桶算法

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

 

5.7.2基于Sentinel的限流 

从 1.6.0 版本开始,Sentinel 提供了 Spring Cloud Gateway 的适配模块,可以提供两种资源维度的限流:

  1. route 维度:即在 Spring 配置文件中配置的路由条目,资源名为对应的 routeId
  2. 自定义 API 维度:用户可以利用 Sentinel 提供的 API 来自定义一些 API 分组

Sentinel 1.6.0 引入了 Sentinel API Gateway Adapter Common 模块,此模块中包含网关限流的规则和自定义 API 的实体和管理逻辑:

  1. GatewayFlowRule :网关限流规则,针对 API Gateway 的场景定制的限流规则,可以针对不同route 或自定义的 API 分组进行限流,支持针对请求中的参数、Header、来源 IP 等进行定制化的限流。
  2. ApiDefinition :用户自定义的 API 定义分组,可以看做是一些 URL 匹配的组合。比如我们可以定义一个 API 叫 my_api ,请求 path 模式为 /foo/** 和 /baz/** 的都归到 my_api 这个 API分组下面。限流的时候可以针对这个自定义的 API 分组维度进行限流。

(1)环境搭建

导入Sentinel 的响应依赖

  1. <!--引入spring-cloud-gateway和sentinel整合的jar-->
  2. <dependency>
  3. <groupId>com.alibaba.csp</groupId>
  4. <artifactId>sentinel-spring-cloud-gateway-adapter</artifactId>
  5. </dependency>

(2) 编写配置类

  1. @Configuration
  2. public class GatewayConfiguration {
  3. private final List<ViewResolver> viewResolvers;
  4. private final ServerCodecConfigurer serverCodecConfigurer;
  5. public GatewayConfiguration(ObjectProvider<List<ViewResolver>> viewResolversProvider,
  6. ServerCodecConfigurer serverCodecConfigurer) {
  7. this.viewResolvers = viewResolversProvider.getIfAvailable(Collections::emptyList);
  8. this.serverCodecConfigurer = serverCodecConfigurer;
  9. }
  10. /**
  11. * 配置限流的异常处理器:SentinelGatewayBlockExceptionHandler
  12. */
  13. @Bean
  14. @Order(Ordered.HIGHEST_PRECEDENCE)
  15. public SentinelGatewayBlockExceptionHandler sentinelGatewayBlockExceptionHandler() {
  16. return new SentinelGatewayBlockExceptionHandler(viewResolvers, serverCodecConfigurer);
  17. }
  18. /**
  19. * 配置限流过滤器
  20. */
  21. @Bean
  22. @Order(Ordered.HIGHEST_PRECEDENCE)
  23. public GlobalFilter sentinelGatewayFilter() {
  24. return new SentinelGatewayFilter();
  25. }
  26. /**
  27. * 配置初始化的限流参数
  28. */
  29. @PostConstruct
  30. public void initGatewayRules() {
  31. Set<GatewayFlowRule> rules = new HashSet<>();
  32. rules.add(new GatewayFlowRule("product_service") //资源名称
  33. .setCount(1) // 限流阈值
  34. .setIntervalSec(1) // 统计时间窗口,单位是秒,默认是 1 秒
  35. );
  36. GatewayRuleManager.loadRules(rules);
  37. }
  38. }
  1. 基于Sentinel 的Gateway限流是通过其提供的Filter来完成的,使用时只需注入对应的SentinelGatewayFilter 实例以及 SentinelGatewayBlockExceptionHandler 实例即可。
  2. @PostConstruct定义初始化的加载方法,用于指定资源的限流规则。这里资源的名称为 order-service ,统计时间是1秒内,限流阈值是1。表示每秒只能访问一个请求。

(3)网关配置

 

  1. spring:
  2. application:
  3. name: shop-gateway-server
  4. cloud:
  5. gateway:
  6. routes:
  7. - id: product_service #路由的ID,没有固定规则但要求唯一,简易配合服务名
  8. uri: lb://shop-product-service #匹配后提供服务的路由地址
  9. predicates:
  10. #- Path=/product/** #断言,路径相匹配的进行路由
  11. - Path=/product-service/**
  12. filters:
  13. - StripPrefix=1

在一秒钟内多次访问  就可以看到限流启作用了。

(4)自定义异常提示

当触发限流后页面显示的是Blocked by Sentinel: FlowException。为了展示更加友好的限流提示,Sentinel支持自定义异常处理。

您可以在 GatewayCallbackManager 注册回调进行定制:

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

  1. @PostConstruct
  2. public void initBlockHandlers() {
  3. BlockRequestHandler blockRequestHandler = new BlockRequestHandler() {
  4. public Mono<ServerResponse> handleRequest(ServerWebExchange serverWebExchange, Throwable throwable) {
  5. Map map = new HashMap<>();
  6. map.put("code", 001);
  7. map.put("message", "对不起,接口限流了");
  8. return ServerResponse.status(HttpStatus.OK).
  9. contentType(MediaType.APPLICATION_JSON_UTF8).
  10. body(BodyInserters.fromObject(map));
  11. }
  12. };
  13. GatewayCallbackManager.setBlockHandler(blockRequestHandler);
  14. }

 

(5)自定义API分组

  1. /**
  2. * 配置初始化的限流参数
  3. */
  4. @PostConstruct
  5. public void initGatewayRules() {
  6. Set<GatewayFlowRule> rules = new HashSet<>();
  7. rules.add(new
  8. GatewayFlowRule("product_api1").setCount(1).setIntervalSec(1));
  9. rules.add(new
  10. GatewayFlowRule("product_api2").setCount(1).setIntervalSec(1));
  11. GatewayRuleManager.loadRules(rules);
  12. }
  1. //自定义API分组
  2. @PostConstruct
  3. private void initCustomizedApis() {
  4. Set<ApiDefinition> definitions = new HashSet<>();
  5. ApiDefinition api1 = new ApiDefinition("product_api1")
  6. .setPredicateItems(new HashSet<ApiPredicateItem>() {{
  7. // 以/product-serv/product/api1 开头的请求
  8. add(new ApiPathPredicateItem().setPattern("/product-
  9. serv/product/api1/**").
  10. setMatchStrategy(SentinelGatewayConstants.URL_MATCH_STRATEGY_PREFIX));
  11. }});
  12. ApiDefinition api2 = new ApiDefinition("product_api2")
  13. .setPredicateItems(new HashSet<ApiPredicateItem>() {{
  14. // 以/product-serv/product/api2/demo1 完成的url路径匹配
  15. add(new ApiPathPredicateItem().setPattern("/product-
  16. serv/product/api2/demo1"));
  17. }});
  18. definitions.add(api1);
  19. definitions.add(api2);
  20. GatewayApiDefinitionManager.loadApiDefinitions(definitions);
  21. }
  22. }

5.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。添加如下配置

  1. server:
  2. port: 80
  3. spring:
  4. application:
  5.   name: shop-gateway-server
  6. cloud:
  7.   gateway:
  8.     routes:
  9.       - id: product_service #路由的ID,没有固定规则但要求唯一,简易配合服务名
  10.         uri: lb://shop-product-service        #匹配后提供服务的路由地址
  11.         predicates:
  12.            #- Path=/product/**         #断言,路径相匹配的进行路由
  13.           - Path=/product-service/**
  14.         filters:
  15.           - RewritePath=/product-service/(?<segment>.*), /$\{segment}
  16.     discovery:
  17.       locator:
  18.         enabled: true  # 开启微服务名称转发
  19.         lower-case-service-id: true  #微服务名小写
  20. eureka:
  21. client:
  22.   service-url:
  23.     defaultZone: http://localhost:7001/eureka/
  24.     registry-fetch-interval-seconds: 5 # 获取服务列表的周期:5s
  25.   instance:
  26.     preferIpAddress: true
  27.     ip-address: 127.0.0.1

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

(2) 配置ngnix

找到ngnix添加负载均衡配置

  1. #配置多台服务器(这里只在一台服务器上的不同端口)
  2. upstream gateway {
  3. server 127.0.0.1:8081;
  4. server 127.0.0.1:8080;
  5. }
  6. #请求转向mysvr 定义的服务器列表
  7. location / {
  8. proxy_pass http://gateway;
  9. }

在浏览器上访问发现 请求的效果和之前是一样的。这次关闭一台网关服务器,还是可以支持部分请求的访问。

声明:本文内容由网友自发贡献,不代表【wpsshop博客】立场,版权归原作者所有,本站不承担相应法律责任。如您发现有侵权的内容,请联系我们。转载请注明出处:https://www.wpsshop.cn/w/羊村懒王/article/detail/428748
推荐阅读
相关标签
  

闽ICP备14008679号