Spring Cloud Gateway 服务网关的部署与使用详细介绍

阿里云国内75折 回扣 微信号:monov8
阿里云国际,腾讯云国际,低至75折。AWS 93折 免费开户实名账号 代冲值 优惠多多 微信号:monov8 飞机:@monov6

一、为什么需要服务网关

1、什么是服务网关

        传统的单体架构中只需要开放一个服务给客户端调用但是微服务架构中是将一个系统拆分成多个微服务如果没有网关客户端只能在本地记录每个微服务的调用地址当需要调用的微服务数量很多时它需要了解每个服务的接口这个工作量很大。那有了网关之后能够起到怎样的改善呢

        网关作为系统的唯一流量入口封装内部系统的架构所有请求都先经过网关由网关将请求路由到合适的微服务所以使用网关的好处在于

  • 1简化客户端的工作。网关将微服务封装起来后客户端只需同网关交互而不必调用各个不同服务
  • 2降低函数间的耦合度。 一旦服务接口修改只需修改网关的路由策略不必修改每个调用该函数的客户端从而减少了程序间的耦合性
  • 3解放开发人员把精力专注于业务逻辑的实现。由网关统一实现服务路由(灰度与ABTest)、负载均衡、访问控制、流控熔断降级等非业务相关功能而不需要每个服务 API 实现时都去考虑

        但是 API 网关也存在不足之处在微服务这种去中心化的架构中网关又成了一个中心点或瓶颈点它增加了一个我们必须开发、部署和维护的高可用组件。正是由于这个原因在网关设计时必须考虑即使 API 网关宕机也不要影响到服务的调用和运行所以需要对网关的响应结果有数据缓存能力通过返回缓存数据或默认数据屏蔽后端服务的失败。

        在服务的调用方式上面网关也有一定的要求API 网关最好是支持 I/O 异步、同步非阻塞的如果服务是同步阻塞调用可以理解为微服务模块之间是没有彻底解耦的即如果A依赖B提供的API如果B提供的服务不可用将直接影响到A不可用除非同步服务调用在API网关层或客户端做了相应的缓存。因此为了彻底解耦在微服务调用上更建议选择异步方式进行。而对于 API 网关需要通过底层多个细粒度的 API 组合的场景推荐采用响应式编程模型进行而不是传统的异步回调方法组合代码其原因除了采用回调方式导致的代码混乱外还有就是对于 API 组合本身可能存在并行或先后调用对于采用回调方式往往很难控制。

2、服务网关的基本功能

3、流量网关与服务网关的区别

        流量网关和服务网关在系统整体架构中所处的位置如上图所示流量网关如Nignx是指提供全局性的、与后端业务应用无关的策略例如 HTTPS证书卸载、Web防火墙、全局流量监控等。而微服务网关如Spring Cloud Gateway是指与业务紧耦合的、提供单个业务域级别的策略如服务治理、身份认证等。也就是说流量网关负责南北向流量调度及安全防护微服务网关负责东西向流量调度及服务治理。

二、服务网关的部署

1、主流网关的对比与选型

 1Kong 网关Kong 的性能非常好非常适合做流量网关但是对于复杂系统不建议业务网关用 Kong主要是工程性方面的考虑

2Zuul1.x 网关Zuul 1.0 的落地经验丰富但是性能差、基于同步阻塞IO适合中小架构不适合并发流量高的场景因为容易产生线程耗尽导致请求被拒绝的情况

3gateway 网关功能强大丰富性能好官方基准测试 RPS (每秒请求数)是Zuul的1.6倍能与 SpringCloud 生态很好兼容单从流式编程+支持异步上也足以让开发者选择它了。

4Zuul 2.x性能与 gateway 差不多基于非阻塞的支持长连接但 SpringCloud 没有集成 zuul2 的计划并且 Netflix 相关组件都宣布进入维护期前景未知。

        综上gateway 网关更加适合 SpringCloud 项目而从发展趋势上看gateway 替代 zuul 也是必然的。

2、Spring Cloud Gateway 网关的搭建

1声明依赖版本号

	<properties>
		<spring-boot.version>2.3.2.RELEASE</spring-boot.version>
		<spring-cloud.version>Hoxton.SR9</spring-cloud.version>
		<spring-cloud-alibaba.version>2.2.6.RELEASE</spring-cloud-alibaba.version>
	</properties>

	<!-- 只声明依赖不引入依赖 -->
	<dependencyManagement>
		<dependencies>
			<!-- 声明springBoot版本 -->
			<dependency>
				<groupId>org.springframework.boot</groupId>
				<artifactId>spring-boot-dependencies</artifactId>
				<version>${spring-boot.version}</version>
				<type>pom</type>
				<scope>import</scope>
			</dependency>
			<!-- 声明springCloud版本 -->
			<dependency>
				<groupId>org.springframework.cloud</groupId>
				<artifactId>spring-cloud-dependencies</artifactId>
				<version>${spring-cloud.version}</version>
				<type>pom</type>
				<scope>import</scope>
			</dependency>
			<!-- 声明 springCloud Alibaba 版本 -->
			<dependency>
				<groupId>com.alibaba.cloud</groupId>
				<artifactId>spring-cloud-alibaba-dependencies</artifactId>
				<version>${spring-cloud-alibaba.version}</version>
				<type>pom</type>
				<scope>import</scope>
			</dependency>
		</dependencies>
	</dependencyManagement>

2添加依赖

<!-- 引入gateway网关 -->
<dependency>
	<groupId>org.springframework.cloud</groupId>
	<artifactId>spring-cloud-starter-gateway</artifactId>
	<exclusions>
        <exclusion>
			<groupId>org.springframework.boot</groupId>
        	<artifactId>spring-boot-starter-web</artifactId>
        </exclusion>
    </exclusions>
</dependency>

注意一定要排除掉 spring-boot-starter-web 依赖否则启动报错

3配置项目名与端口

server:
  port: 9023
  servlet:
    context-path: /${spring.application.name}
spring:
  application:
    name: gateway

好了网关项目搭建完成其实就添加这么一个依赖关于详细的配置以及作用下文介绍。

3、Spring Cloud Gateway 配置项的说明

        在介绍 Spring Cloud Gateway 的配置项之前我们先了解几个 Spring Cloud Gateway 的核心术语

  • 断言Predicate参照 Java8 的新特性Predicate允许开发人员匹配 HTTP 请求中的任何内容比如请求头或请求参数最后根据匹配结果返回一个布尔值。
  • 路由route由ID、目标URI、断言集合和过滤器集合组成。如果聚合断言结果为真则转发到该路由。
  • 过滤器filter可以在返回请求之前或之后修改请求和响应的内容。

3.1、路由 Route

        Route 主要由 路由id、目标uri、断言集合和过滤器集合组成那我们简单看看这些属性到底有什么作用。

1id路由标识要求唯一名称任意默认值 uuid一般不用需要自定义

2uri请求最终被转发到的目标地址

3order 路由优先级数字越小优先级越高

4predicates断言数组即判断条件如果返回值是boolean则转发请求到 uri 属性指定的服务中

5filters过滤器数组在请求传递过程中对请求做一些修改

3.2、断言 Predicate

        Predicate 来自于 Java8 的接口。Predicate 接受一个输入参数返回一个布尔值结果。该接口包含多种默认方法来将 Predicate 组合成其他复杂的逻辑比如与或非。

        Predicate 可以用于接口请求参数校验、判断新老数据是否有变化需要进行更新操作。Spring Cloud Gateway 内置了许多 Predict这些 Predict 的源码在 org.springframework.cloud.gateway.handler.predicate 包中有兴趣可以阅读一下。内置的一些断言如下图

以上11种断言这里就不再介绍如何配置了官方文档写的很清楚https://docs.spring.io/spring-cloud-gateway/docs/2.2.9.RELEASE/reference/html/

下面就以最后一种权重断言为例介绍一下如何配置。配置如下

spring:
  cloud:
    gateway:
      # 路由数组指当请求满足什么样的断言时转发到哪个服务上
      routes:
        # 路由标识要求唯一名称任意
        - id: gateway-provider_1
		  # 请求最终被转发到的目标地址
          uri: http://localhost:9024
          # 设置断言
          predicates:
            # Path Route Predicate Factory 断言满足 /gateway/provider/** 路径的请求都会被路由到 http://localhost:9024 这个uri中
            - Path=/gateway/provider/**
            # Weight Route Predicate Factory 断言同一分组按照权重进行分配流量这里分配了80%
            # 第一个group1是分组名第二个参数是权重
            - Weight=group1, 8
          # 配置过滤器局部
          filters:
            # StripPrefix去除原始请求路径中的前1级路径即/gateway
            - StripPrefix=1            
            
        - id: gateway-provider_2
          uri: http://localhost:9025
          # 设置断言
          predicates:
            - Path=/gateway/provider/**
            # Weight Route Predicate Factory同一分组按照权重进行分配流量这里分配了20%
            - Weight=group1, 2
		  # 配置过滤器局部
          filters:
            # StripPrefix去除原始请求路径中的前1级路径即/gateway
            - StripPrefix=1            

        Spring Cloud Gateway 中的断言命名都是有规范的格式“xxx + RoutePredicateFactory”比如权重断言 WeightRoutePredicateFactory那么配置时直接取前面的 “Weight”。

        如果路由转发匹配到了两个或以上则是的按照配置先后顺序转发上面都配置了路径“ Path=/gateway/provider/** ”如果没有配置权重则肯定是先转发到 “http://localhost:9024”但是既然配置配置了权重并且相同的分组则按照权重比例进行分配流量。

3.3、过滤器 filter

Gateway 过滤器的生命周期

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

Gateway 过滤器从作用范围可分为两种:

  • GatewayFilter应用到单个路由或者一个分组的路由上需要在配置文件中配置
  • GlobalFilter应用到所有的路由上无需配置全局生效

1局部过滤器 GatewayFilter

        Spring Cloud Gateway 中内置了许多的局部过滤器如下图

         局部过滤器需要在指定路由配置才能生效默认是不生效的。以 “AddResponseHeaderGatewayFilterFactory” 这个过滤器为例为原始响应添加Header配置如下

spring:
  cloud:
    gateway:
      routes:
        - id: gateway-provider_1
          uri: http://localhost:9024
          predicates:
            - Path=/gateway/provider/**
          # 配置过滤器局部
          filters:
            - AddResponseHeader=X-Response-Foo, Bar
            # StripPrefix去除原始请求路径中的前1级路径即/gateway
            - StripPrefix=1   

浏览器请求发现响应头中已经有了 X-Response-Foo=Bar 这个键值对如下图

        在前面的示例中我们也使用到了另一个局部过滤器 StripPrefixGatewayFilterFactory该过滤器主要用于截断原始请求的路径当我们请求 localhost:9023/gateway/provider/test 时实际请求会被转发到 http://localhost:9024 服务上并被截断成 “http://localhost:9024/provider/test"

注意过滤器的名称只需要写前缀过滤器命名必须是 "xxx + GatewayFilterFactory“包括自定义。

更多过滤器的配置参考官方文档https://docs.spring.io/spring-cloud-gateway/docs/2.2.9.RELEASE/reference/html/#gatewayfilter-factories

2自定义局部过滤器

        虽说内置的过滤器能够解决很多场景但是难免还是有些特殊需求需要定制一个过滤器下面就来介绍一下如何自定义局部过滤器。

/**
 * 名称必须是xxxGatewayFilterFactory形式
 * todo模拟授权的验证具体逻辑根据业务完善
 */
@Component
@Slf4j
public class AuthorizeGatewayFilterFactory extends AbstractGatewayFilterFactory<AuthorizeGatewayFilterFactory.Config> {

    private static final String AUTHORIZE_TOKEN = "token";

    //构造函数加载Config
    public AuthorizeGatewayFilterFactory() {
        //固定写法
        super(AuthorizeGatewayFilterFactory.Config.class);
        log.info("Loaded GatewayFilterFactory [Authorize]");
    }

    //读取配置文件中的参数 赋值到 配置类中
    @Override
    public List<String> shortcutFieldOrder() {
        //Config.enabled
        return Arrays.asList("enabled");
    }

    @Override
    public GatewayFilter apply(AuthorizeGatewayFilterFactory.Config config) {
        return (exchange, chain) -> {
            //判断是否开启授权验证
            if (!config.isEnabled()) {
                return chain.filter(exchange);
            }

            ServerHttpRequest request = exchange.getRequest();
            HttpHeaders headers = request.getHeaders();
            //从请求头中获取token
            String token = headers.getFirst(AUTHORIZE_TOKEN);
            if (token == null) {
                //从请求头参数中获取token
                token = request.getQueryParams().getFirst(AUTHORIZE_TOKEN);
            }

            ServerHttpResponse response = exchange.getResponse();
            //如果token为空直接返回401未授权
            if (StringUtils.isEmpty(token)) {
                response.setStatusCode(HttpStatus.UNAUTHORIZED);
                //处理完成直接拦截不再进行下去
                return response.setComplete();
            }
            /**
             * todo chain.filter(exchange) 之前的都是过滤器的前置处理
             *
             * chain.filter().then(
             *  过滤器的后置处理...........
             * )
             */
            //授权正常继续下一个过滤器链的调用
            return chain.filter(exchange);
        };
    }

    @Data
    @AllArgsConstructor
    @NoArgsConstructor
    public static class Config {
        // 控制是否开启认证
        private boolean enabled;
    }
}

局部过滤器需要在路由中配置才能生效配置如下

spring:
  cloud:
    gateway:
      routes:
        - id: gateway-provider_1
          uri: http://localhost:9024
          predicates:
            - Path=/gateway/provider/**
          ## 配置过滤器局部
          filters:
            - AddResponseHeader=X-Response-Foo, Bar
            ## AuthorizeGatewayFilterFactory自定义过滤器配置值为true需要验证授权false不需要
            - Authorize=true

此时直接访问http://localhost:9023/gateway/provider/port不携带token返回如下图

请求参数带上tokenhttp://localhost:9023/gateway/provider/port?token=abcdcdecd-ddcdeicd12成功返回如下图

        上述的 AuthorizeGatewayFilterFactory 只是涉及到了过滤器的前置处理后置处理是在 chain.filter().then() 中的 then() 方法中完成的具体可以看下项目源码中的 TimeGatewayFilterFactory代码就不再贴出来了如下图

3GlobalFilter 全局过滤器

        全局过滤器应用全部路由上无需开发者配置Spring Cloud Gateway 也内置了一些全局过滤器如下图

        GlobalFilter 的功能其实和 GatewayFilter 是相同的只是 GlobalFilter 的作用域是所有的路由配置而不是绑定在指定的路由配置上。多个 GlobalFilter 可以通过 @Order 或者 getOrder() 方法指定执行顺序order值越小执行的优先级越高。

        注意由于过滤器有 pre 和 post 两种类型pre 类型过滤器如果 order 值越小那么它就应该在pre过滤器链的顶层post 类型过滤器如果 order 值越小那么它就应该在 post 过滤器链的底层。示意图如下

4自定义全局过滤器

        当然除了内置的全局过滤器实际工作中还需要定制过滤器下面来介绍一下如何自定义。我们模拟 Nginx 的 Access Log 功能记录每次请求的相关信息。代码如下

@Slf4j
@Component
@Order(value = Integer.MIN_VALUE)
public class AccessLogGlobalFilter implements GlobalFilter {

    @Override
    public Mono<Void> filter(ServerWebExchange exchange, GatewayFilterChain chain) {
        //filter的前置处理
        ServerHttpRequest request = exchange.getRequest();
        String path = request.getPath().pathWithinApplication().value();
        InetSocketAddress remoteAddress = request.getRemoteAddress();
        return chain
                //继续调用filter
                .filter(exchange)
                //filter的后置处理
                .then(Mono.fromRunnable(() -> {
            ServerHttpResponse response = exchange.getResponse();
            HttpStatus statusCode = response.getStatusCode();
            log.info("请求路径:{},远程IP地址:{},响应码:{}", path, remoteAddress, statusCode);
        }));
    }
}

好了全局过滤器不必在路由上配置注入到IOC容器中即可全局生效。

此时发出一个请求控制台打印信息如下

请求路径:/gateway/provider/port,远程IP地址:/0:0:0:0:0:0:0:1:64114,响应码:200 OK

4、Gateway 集成 nacos 注册中心实现服务发现

        上述 demo 中并没有集成注册中心每次路由配置都是指定固定的服务uri如下图

这样做有什么坏处呢

  • 网关服务需要知道所有服务的域名或IP地址另外一旦服务的域名或IP地址发生修改路由配置中的 uri 就必须修改
  • 服务集群中无法实现负载均衡

        那么此时我们可以集成的注册中心使得网关能够从注册中心自动获取uri并实现负载均衡这里我们以 nacos 注册中心为例介绍一下

1pom 文件中新增依赖

<!--nacos注册中心-->
<dependency>
	<groupId>com.alibaba.cloud</groupId>
	<artifactId>spring-cloud-starter-alibaba-nacos-discovery</artifactId>
</dependency>

2启动类添加 @EnableDiscoveryClient 注解开启注册中心功能如下图

 3配置 nacos 注册中心的地址

nacos:
  namespace: 856a40d7-6548-4494-bdb9-c44491865f63
  url: 120.76.129.106:80
spring:
  cloud:
    nacos:
      discovery:
      	server-addr: ${nacos.url}
        namespace: ${nacos.namespace}
        register-enabled: true

4服务路由配置

spring:
  cloud:
    gateway:
      routes:
        - id: gateway-provider_1
          ## 使用了lb形式从注册中心负载均衡的获取uri
          uri: lb://gateway-provider
          ## 配置断言
          predicates:
            - Path=/gateway/provider/**
          filters:
            - AddResponseHeader=X-Response-Foo, Bar

路由配置中唯一不同的就是路由的 uri格式lb://service-name这是固定写法

  • lb固定格式指的是从nacos中按照名称获取微服务并遵循负载均衡策略
  • service-namenacos注册中心的服务名称这里并不是IP地址形式的

        为什么指定了 lb 就可以开启负载均衡前面说过全局过滤器 LoadBalancerClientFilter 就是负责路由寻址和负载均衡的可以看到如下源码

5开启 gateway 自动路由配置

        随着我们的系统架构不断地发展系统中微服务的数量肯定会越来越多我们不可能每添加一个服务就在网关配置一个新的路由规则这样的维护成本很大特别在很多种情况我们在请求路径中会携带一个路由标识方便进行转发而这个路由标识一般都是服务在注册中心中的服务名因此这是我们就可以开启 spring cloud gateway 的自动路由功能网关自动根据注册中心的服务名为每个服务创建一个router将以服务名开头的请求路径转发到对应的服务配置如下

# enabled默认为false设置为true表明spring cloud gateway开启服务发现和路由的功能网关自动根据注册中心的服务名为每个服务创建一个router将以服务名开头的请求路径转发到对应的服务
spring.cloud.gateway.discovery.locator.enabled = true
# lowerCaseServiceId启动 locator.enabled=true 自动路由时路由的路径默认会使用大写ID若想要使用小写ID可将lowerCaseServiceId设置为true
spring.cloud.gateway.discovery.locator.lower-case-service-id = true

        这里需要注意的是由于我们的网关项目配置了 server.servlet.context-path 属性这会导致自动路由失败的问题因此我们需要做如下两个修改

# 重写过滤链解决项目设置了 server.servlet.context-path 导致 locator.enabled=true 默认路由策略404的问题
spring.cloud.gateway.discovery.locator.filters[0] = PreserveHostHeader
@Configuration
public class GatewayConfig
{
    @Value ("${server.servlet.context-path}")
    private String prefix;

    /**
     * 过滤 server.servlet.context-path 属性配置的项目路径防止对后续路由策略产生影响因为 gateway 网关不支持 servlet
     */
    @Bean
    @Order (-1)
    public WebFilter apiPrefixFilter()
    {
        return (exchange, chain) ->
        {
            ServerHttpRequest request = exchange.getRequest();
            String path = request.getURI().getRawPath();

            path = path.startsWith(prefix) ? path.replaceFirst(prefix, "") : path;
            ServerHttpRequest newRequest = request.mutate().path(path).build();

            return chain.filter(exchange.mutate().request(newRequest).build());
        };
    }
}

        至此我们就开启了 spring cloud gateway 的自动路由功能网关自动根据注册中心的服务名为每个服务创建一个router将以服务名开头的请求路径转发到对应的服务。假设我们的服务提供者在 nacos 注册中心的服务名为 “gateway-provider”这时我们只需要访问 “http://localhost:9023/gateway/gateway-provider/test”就可以将请求成功转发过去了

5、Gateway 整合 Apollo 实现动态路由配置

        上述例子都是将网关的一系列配置写到项目的配置文件中一旦路由策略发生改变必须要重启项目这样维护成本很高特别是服务网关作为系统的中心点一旦重启出现问题影响面将是十分巨大的因此我们将网关的配置存放到配置中心中这样由配置中心统一管理一旦路由发生改变只需要在配置中心修改即可降低风险且实时失效。本部分就以 Apollo 配置中心为例介绍下如下实现动态路由配置

1添加 apollo 配置中心依赖

<!-- Apollo 统一配置中心 -->
<dependency>
    <groupId>com.ctrip.framework.apollo</groupId>
    <artifactId>apollo-client</artifactId>
    <version>1.7.0</version>
</dependency>

2添加 Apollo 路由更改监听刷新类

import com.ctrip.framework.apollo.enums.PropertyChangeType;
import com.ctrip.framework.apollo.model.ConfigChange;
import com.ctrip.framework.apollo.model.ConfigChangeEvent;
import com.ctrip.framework.apollo.spring.annotation.ApolloConfigChangeListener;
import org.slf4j.Logger;
import org.slf4j.LoggerFactory;
import org.springframework.beans.BeansException;
import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.cloud.context.environment.EnvironmentChangeEvent;
import org.springframework.cloud.gateway.config.GatewayProperties;
import org.springframework.cloud.gateway.event.RefreshRoutesEvent;
import org.springframework.cloud.gateway.route.RouteDefinitionWriter;
import org.springframework.context.ApplicationContext;
import org.springframework.context.ApplicationContextAware;
import org.springframework.context.ApplicationEventPublisher;
import org.springframework.context.ApplicationEventPublisherAware;
import org.springframework.context.annotation.Configuration;

import java.util.ArrayList;

/**
 * Apollo路由更改监听刷新
 */
@Configuration
public class GatewayPropertRefresher implements ApplicationContextAware, ApplicationEventPublisherAware
{
    private static final Logger logger = LoggerFactory.getLogger(GatewayPropertRefresher.class);

    private static final String ID_PATTERN = "spring\\.cloud\\.gateway\\.routes\\[\\d+\\]\\.id";

    private static final String DEFAULT_FILTER_PATTERN = "spring\\.cloud\\.gateway\\.default-filters\\[\\d+\\]\\.name";


    private ApplicationContext applicationContext;

    private ApplicationEventPublisher publisher;

    @Autowired
    private  GatewayProperties gatewayProperties;

    @Autowired
    private RouteDefinitionWriter routeDefinitionWriter;


    @Override
    public void setApplicationContext(ApplicationContext applicationContext) throws BeansException {
        this.applicationContext = applicationContext;
    }

    @Override
    public void setApplicationEventPublisher(ApplicationEventPublisher applicationEventPublisher) {
        this.publisher = applicationEventPublisher;
    }


    /**
     * 监听路由修改
     */
    @ApolloConfigChangeListener(interestedKeyPrefixes = "spring.cloud.gateway.")
    public void onChange(ConfigChangeEvent changeEvent)
    {
        refreshGatewayProperties(changeEvent);
    }

    /**
     * 刷新路由信息
     */
    private void refreshGatewayProperties(ConfigChangeEvent changeEvent)
    {
        logger.info("gateway网关配置 刷新开始");

        preDestroyGatewayProperties(changeEvent);
        //更新配置
        this.applicationContext.publishEvent(new EnvironmentChangeEvent(changeEvent.changedKeys()));
        //更新路由
        refreshGatewayRouteDefinition();

        logger.info("gateway网关配置 刷新完成");
    }

    /***
     * GatewayProperties没有@PreDestroy和destroy方法
     * org.springframework.cloud.context.properties.ConfigurationPropertiesRebinder#rebind(java.lang.String)中destroyBean时不会销毁当前对象
     * 如果把spring.cloud.gateway.前缀的配置项全部删除例如需要动态删除最后一个路由的场景initializeBean时也无法创建新的bean则return当前bean
     * 若仍保留有spring.cloud.gateway.routes[n]或spring.cloud.gateway.default-filters[n]等配置initializeBean时会注入新的属性替换已有的bean
     * 这个方法提供了类似@PreDestroy的操作根据配置文件的实际情况把org.springframework.cloud.gateway.config.GatewayProperties#routes
     * 和org.springframework.cloud.gateway.config.GatewayProperties#defaultFilters两个集合清空
     */
    private synchronized void preDestroyGatewayProperties(ConfigChangeEvent changeEvent)
    {
        logger.info("Pre Destroy GatewayProperties 操作开始!");

        final boolean needClearRoutes = this.checkNeedClear(changeEvent, ID_PATTERN, this.gatewayProperties.getRoutes().size());
        if (needClearRoutes)
        {
            this.gatewayProperties.setRoutes(new ArrayList());
        }

        final boolean needClearDefaultFilters = this.checkNeedClear(changeEvent, DEFAULT_FILTER_PATTERN, this.gatewayProperties.getDefaultFilters().size());
        if (needClearDefaultFilters)
        {
            this.gatewayProperties.setRoutes(new ArrayList());
        }

        logger.info("Pre Destroy GatewayProperties 操作完成!");
    }


    private void refreshGatewayRouteDefinition()
    {
        logger.info("Refreshing Gateway RouteDefinition 操作开始!");

        this.publisher.publishEvent(new RefreshRoutesEvent(this));

        logger.info("Gateway RouteDefinition refreshed 操作完成!");
    }

    /***
     * 根据changeEvent和定义的pattern匹配key如果所有对应PropertyChangeType为DELETED则需要清空GatewayProperties里相关集合
     */
    private boolean checkNeedClear(ConfigChangeEvent changeEvent, String pattern, int existSize) {

        return changeEvent.changedKeys().stream().filter(key -> key.matches(pattern)).filter(key ->
        {
            ConfigChange change = changeEvent.getChange(key);
            return PropertyChangeType.DELETED.equals(change.getChangeType());
        }).count() == existSize;
    }
}

3暴露endpoint端点

# 暴露endpoint端点暴露路由信息有获取所有路由、刷新路由、查看单个路由、删除路由等方法
management.endpoints.web.exposure.include = *
management.endpoint.health.show-details = always

        至此我们就完成了 Gateway 网关整合 Apollo 配置中心实现动态路由配置一旦路由发生改变只需要在配置中心修改即可被监听到并实时失效

如果有整合 Nacos 或 MySQL 进行动态路由配置的读者可以参考以下两篇文章

1整合 Nacos 进行动态路由配置https://www.cnblogs.com/jian0110/p/12862569.html

2整合 MySQL 进行动态路由配置https://blog.csdn.net/qq_42714869/article/details/92794911

6、自定义全局异常处理器

        通过前面的测试可以看到一个现象一旦路由的微服务下线或者失联了Spring Cloud Gateway直接返回了一个错误页面如下图

        显然这种异常信息不友好前后端分离架构中必须定制返回的异常信息。传统的Spring Boot 服务中都是使用 @ControllerAdvice 来包装全局异常处理的但是由于服务下线请求并没有到达。因此必须在网关中也要定制一层全局异常处理这样才能更加友好的和客户端交互。

        Spring Cloud Gateway提供了多种全局处理的方式今天只介绍其中一种方式实现还算比较优雅

        直接创建一个类 GlobalErrorExceptionHandler实现 ErrorWebExceptionHandler重写其中的 handle 方法代码如下

/**
 * 用于网关的全局异常处理
 * @Order(-1)优先级一定要比ResponseStatusExceptionHandler低
 */
@Slf4j
@Order(-1)
@Component
@RequiredArgsConstructor
public class GlobalErrorExceptionHandler implements ErrorWebExceptionHandler {

 private final ObjectMapper objectMapper;

 @SuppressWarnings({"rawtypes", "unchecked", "NullableProblems"})
 @Override
 public Mono<Void> handle(ServerWebExchange exchange, Throwable ex) {
  ServerHttpResponse response = exchange.getResponse();
  if (response.isCommitted()) {
   return Mono.error(ex);
  }

  // JOSN格式返回
  response.getHeaders().setContentType(MediaType.APPLICATION_JSON);
  if (ex instanceof ResponseStatusException) {
   response.setStatusCode(((ResponseStatusException) ex).getStatus());
  }

  return response.writeWith(Mono.fromSupplier(() -> {
   DataBufferFactory bufferFactory = response.bufferFactory();
   try {
    //todo 返回响应结果根据业务需求自己定制
    CommonResponse resultMsg = new CommonResponse("500",ex.getMessage(),null);
    return bufferFactory.wrap(objectMapper.writeValueAsBytes(resultMsg));
   }
   catch (JsonProcessingException e) {
    log.error("Error writing response", ex);
    return bufferFactory.wrap(new byte[0]);
   }
  }));
 }
}

        好了全局异常处理已经定制完成了在测试一下此时正常返回JSON数据了JSON的样式根据架构需要自己定制如下图


相关阅读

常见的服务器架构入门从单体架构、EAI 到 SOA 再到微服务和 ServiceMesh

常见分布式理论CAP、BASE和一致性协议Gosssip协议、Raft一致性算法

一致性哈希算法原理详解

Nacos注册中心的部署与用法详细介绍

Nacos配置中心用法详细介绍

SpringCloud OpenFeign 远程HTTP服务调用用法与原理

什么是RPCRPC框架dubbo的核心流程

服务容错设计流量控制、服务熔断、服务降级

sentinel 限流熔断神器详细介绍

Sentinel 规则持久化到 apollo 配置中心

Sentinel-Dashboard 与 apollo 规则的相互同步

Spring Cloud Gateway 服务网关的部署与使用详细介绍

Spring Cloud Gateway 整合 sentinel 实现流控熔断

Spring Cloud Gateway 整合 knife4j 聚合接口文档

常见分布式事务详解2PC、3PC、TCC、Saga、本地事务表、MQ事务消息、最大努力通知

分布式事务Seata原理

RocketMQ事务消息原理


参考文章Spring Cloud Gateway夺命连环10问

阿里云国内75折 回扣 微信号:monov8
阿里云国际,腾讯云国际,低至75折。AWS 93折 免费开户实名账号 代冲值 优惠多多 微信号:monov8 飞机:@monov6
标签: Spring