3W字吃透：微服务网关SpringCloud gateway底层原理和实操
Posted 疯狂创客圈
tags:
篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了3W字吃透：微服务网关SpringCloud gateway底层原理和实操相关的知识，希望对你有一定的参考价值。
文章很长，且持续更新，建议收藏起来，慢慢读！疯狂创客圈总目录 博客园版 为您奉上珍贵的学习资源 ：
免费赠送 :《尼恩Java面试宝典》 持续更新+ 史上最全 + 面试必备 2000页+ 面试必备 + 大厂必备 +涨薪必备
免费赠送 :《尼恩技术圣经+高并发系列PDF》 ，帮你 实现技术自由，完成职业升级， 薪酬猛涨！加尼恩免费领
免费赠送 经典图书:《Java高并发核心编程（卷1）加强版》 面试必备 + 大厂必备 +涨薪必备 加尼恩免费领
免费赠送 经典图书:《Java高并发核心编程（卷2）加强版》 面试必备 + 大厂必备 +涨薪必备 加尼恩免费领
免费赠送 经典图书:《Java高并发核心编程（卷3）加强版》 面试必备 + 大厂必备 +涨薪必备 加尼恩免费领
免费赠送 资源宝库： Java 必备 百度网盘资源大合集 价值>10000元 加尼恩领取
40岁老架构师尼恩的掏心窝：
现在拿到offer超级难，甚至连面试电话，一个都搞不到。
尼恩的技术社群中（50+），很多小伙伴凭借 “左手云原生 + 右手大数据 + SpringCloud Alibaba 微服务“三大绝活，拿到了offer，并且是非常优质的offer，据说年终奖都足足18个月 ，非常令人羡慕。
问题是：“左手云原生 + 右手大数据 + SpringCloud Alibaba 微服务“ 内容非常多，实操的环境非常复杂，底层原理很深。
米饭要一口一口的吃，不能急。在这里，尼恩从架构师视角出发，左手云原生 + 右手大数据 + SpringCloud Alibaba 微服务 核心原理做一个宏观的介绍。
由于内容确实太多， 所以写多个pdf 电子书：
(1) 《 Docker 学习圣经 》PDF （V1已经完成）
(2) 《 SpringCloud Alibaba 微服务 学习圣经 》PDF （V4已经完成）
(3) 《 K8S 学习圣经 》PDF （V1已经完成）
(4) 《 Java 调优圣经 》PDF （coding ......）
以上学习圣经，并且后续会持续升级，从V1版本一直迭代发布。 就像咱们的《尼恩 Java 面试宝典》一样， 已经迭代到V68啦。
40岁老架构师尼恩的掏心窝： 通过一系列的学习圣经，带大家穿透“左手云原生+右手大数据 +SpringCloud Alibaba 微服务“ ，实现技术 自由 ，走向颠覆人生，让大家不迷路。
以上学习圣经的 基础知识是 尼恩的《高并发三部曲》，建议在看 学习圣经之前，一定把尼恩的 Java高并发三部曲过一遍，切记，切记。
版本升级说明
本文 为《SpringCloud Alibaba 学习圣经》 的 gateway 部分的 升级版本。
在原书的基础上，完善和修改了 3W 字左右。
最新的内容，已经合入到 《SpringCloud Alibaba 学习圣经》 V4 版本PDF。
最新的、完整的PDF，可以在公众号【技术自由圈】领取，暗号：领电子书。
本文目录
1、SpringCloud Gateway 简介
网关是微服务架构中的一个关键的角色，用来保护、增强和控制对于微服务的访问。
网关是一个处于应用程序或服务之前的系统，用来管理授权、访问控制和流量限制等，这样微服务就会被微服务网关保护起来，对所有的调用者透明。因此，隐藏在微服务网关后面的业务系统就可以更加专注于业务本身。同时，微服务网关还可以为服务提供和沉淀更多附加功能。
下面是微服务网关的主要作用：
此类API网关的示例包括：
- Spring Cloud Gateway
- Solo.io Gloo
- Netflix Zuul
- IBM-Strongloop Loopback/Microgateway
SpringCloud Gateway 是 Spring Cloud 的一个全新项目，该项目是基于 Spring 5.0，Spring Boot 2.0 和 Project Reactor 等技术开发的网关，它旨在为微服务架构提供一种简单有效的统一的 API 路由管理方式。
SpringCloud Gateway 作为 Spring Cloud 生态系统中的网关，目标是替代 Zuul，在Spring Cloud 2.0以上版本中，没有对新版本的Zuul 2.0以上最新高性能版本进行集成，仍然还是使用的Zuul 2.0之前的非Reactor模式的老版本。而为了提升网关的性能，SpringCloud Gateway是基于WebFlux框架实现的，而WebFlux框架底层则使用了高性能的Reactor模式通信框架Netty。
Spring Cloud Gateway 的目标，不仅提供统一的路由方式，并且基于 Filter 链的方式提供了网关基本的功能，例如：安全，监控/指标，和限流。
特别说明：
Spring Cloud Gateway 底层使用了高性能的通信框架Netty。
Netty 是高性能中间件的通讯底座， rocketmq 、seata、nacos 、sentinel 、redission 、dubbo 等太多、太多的的大名鼎鼎的中间件，无一例外都是基于netty。
可以毫不夸张的说： netty 是进入大厂、走向高端 的必备技能。
要想深入了解springcloud gateway ，最好是掌握netty 编程。
有关 netty学习 具体请参见机工社出版 、尼恩的畅销书: 《Java高并发核心编程 卷 1 加强版》
1.1 本文姊妹篇 《Flux 和 Mono 、reactor实战 （史上最全）》
另外，如果要掌握 springcloud gateway 的过滤器编程，或者 掌握 springcloud gateway 开发，还必须：
具备 reactor 响应式编程的实战能力
有关 reactor 响应式编程的实战， 具体请参考本文姊妹篇：
《Flux 和 Mono 、reactor实战 （史上最全）》
1.2 SpringCloud Gateway 特征
SpringCloud官方，对SpringCloud Gateway 特征介绍如下：
（1）基于 Spring Framework 5，Project Reactor 和 Spring Boot 2.0
（2）集成 Hystrix 断路器
（3）集成 Spring Cloud DiscoveryClient
（4）Predicates 和 Filters 作用于特定路由，易于编写的 Predicates 和 Filters
（5）具备一些网关的高级功能：动态路由、限流、路径重写
从以上的特征来说，和Zuul的特征差别不大。SpringCloud Gateway和Zuul主要的区别，还是在底层的通信框架上。
简单说明一下上文中的三个术语：
（1）Filter（过滤器）：
和Zuul的过滤器在概念上类似，可以使用它拦截和修改请求，并且对上游的响应，进行二次处理。过滤器为org.springframework.cloud.gateway.filter.GatewayFilter类的实例。
（2）Route（路由）：
网关配置的基本组成模块，和Zuul的路由配置模块类似。一个Route模块由一个 ID，一个目标 URI，一组断言和一组过滤器定义。如果断言为真，则路由匹配，目标URI会被访问。
（3）Predicate（断言）：
这是一个 Java 8 的 Predicate，可以使用它来匹配来自 HTTP 请求的任何内容，例如 headers 或参数。断言的输入参数类型是一个 ServerWebExchange。
1.3 SpringCloud Gateway和架构
Spring在2017年下半年迎来了Webflux，Webflux的出现填补了Spring在响应式编程上的空白，Webflux的响应式编程不仅仅是编程风格的改变，而且对于一系列的著名框架，都提供了响应式访问的开发包，比如Netty、Redis等等。
SpringCloud Gateway 使用的Webflux中的reactor-netty响应式编程组件，底层使用了Netty通讯框架。
1.3.1 SpringCloud Zuul的IO模型
Springcloud中所集成的Zuul版本，采用的是Tomcat容器，使用的是传统的Servlet IO处理模型。
大家知道，servlet由servlet container进行生命周期管理。container启动时构造servlet对象并调用servlet init()进行初始化；container关闭时调用servlet destory()销毁servlet；container运行时接受请求，并为每个请求分配一个线程（一般从线程池中获取空闲线程）然后调用service()。
弊端：servlet是一个简单的网络IO模型，当请求进入servlet container时，servlet container就会为其绑定一个线程，在并发不高的场景下这种模型是适用的，但是一旦并发上升，线程数量就会上涨，而线程资源代价是昂贵的（上线文切换，内存消耗大）严重影响请求的处理时间。在一些简单的业务场景下，不希望为每个request分配一个线程，只需要1个或几个线程就能应对极大并发的请求，这种业务场景下servlet模型没有优势。
所以Springcloud Zuul 是基于servlet之上的一个阻塞式处理模型，即spring实现了处理所有request请求的一个servlet（DispatcherServlet），并由该servlet阻塞式处理处理。所以Springcloud Zuul无法摆脱servlet模型的弊端。虽然Zuul 2.0开始，使用了Netty，并且已经有了大规模Zuul 2.0集群部署的成熟案例，但是，Springcloud官方已经没有集成改版本的计划了。
1.3.2 Webflux 服务器
Webflux模式替换了旧的Servlet线程模型。用少量的线程处理request和response io操作，这些线程称为Loop线程，而业务交给响应式编程框架处理，响应式编程是非常灵活的，用户可以将业务中阻塞的操作提交到响应式框架的work线程中执行，而不阻塞的操作依然可以在Loop线程中进行处理，大大提高了Loop线程的利用率。官方结构图：
Webflux虽然可以兼容多个底层的通信框架，但是一般情况下，底层使用的还是Netty，毕竟，Netty是目前业界认可的最高性能的通信框架。而Webflux的Loop线程，正好就是著名的Reactor 模式IO处理模型的Reactor线程，如果使用的是高性能的通信框架Netty，这就是Netty的EventLoop线程。
关于Reactor线程模型，和Netty通信框架的知识，是Java程序员的重要、必备的内功，个中的原理，具体请参见尼恩编著的《Netty、Zookeeper、Redis高并发实战》一书，这里不做过多的赘述。
1.3.3 Spring Cloud Gateway的处理流程
客户端向 Spring Cloud Gateway 发出请求。然后在 Gateway Handler Mapping 中找到与请求相匹配的路由，将其发送到 Gateway Web Handler。Handler 再通过指定的过滤器链来将请求发送到我们实际的服务执行业务逻辑，然后返回。过滤器之间用虚线分开是因为过滤器可能会在发送代理请求之前（“pre”）或之后（“post”）执行业务逻辑。
2、路由配置方式
2.1 基础URI路由配置方式
如果请求的目标地址，是单个的URI资源路径，配置文件示例如下：
server:
port: 8080
spring:
application:
name: api-gateway
cloud:
gateway:
routes:
- id: url-proxy-1
uri: https://blog.csdn.net
predicates:
- Path=/csdn
各字段含义如下：
id：我们自定义的路由 ID，保持唯一
uri：目标服务地址
predicates：路由条件，Predicate 接受一个输入参数，返回一个布尔值结果。该接口包含多种默认方法来将 Predicate 组合成其他复杂的逻辑（比如：与，或，非）。
上面这段配置的意思是，配置了一个 id 为 url-proxy-1的URI代理规则，路由的规则为：
当访问地址http://localhost:8080/csdn/1.jsp时，
会路由到上游地址https://blog.csdn.net/1.jsp。
2.2 基于代码的路由配置方式
转发功能同样可以通过代码来实现，我们可以在启动类 GateWayApplication 中添加方法 customRouteLocator() 来定制转发规则。
package com.springcloud.gateway;
import org.springframework.boot.SpringApplication;
import org.springframework.boot.autoconfigure.SpringBootApplication;
import org.springframework.cloud.gateway.route.RouteLocator;
import org.springframework.cloud.gateway.route.builder.RouteLocatorBuilder;
import org.springframework.context.annotation.Bean;
@SpringBootApplication
public class GatewayApplication
public static void main(String[] args)
SpringApplication.run(GatewayApplication.class, args);
@Bean
public RouteLocator customRouteLocator(RouteLocatorBuilder builder)
return builder.routes()
.route("path_route", r -> r.path("/csdn")
.uri("https://blog.csdn.net"))
.build();
我们在yaml配置文件中注销掉相关路由的配置，重启服务，访问链接：http://localhost:8080/ csdn， 可以看到和上面一样的页面，证明我们测试成功。
上面两个示例中 uri 都是指向了我的CSDN博客，在实际项目使用中可以将 uri 指向对外提供服务的项目地址，统一对外输出接口。
2.3 和注册中心相结合的路由配置方式
在uri的schema协议部分为自定义的lb:类型，表示从微服务注册中心（如Eureka）订阅服务，并且进行服务的路由。
一个典型的示例如下：
server:
port: 8084
spring:
cloud:
gateway:
routes:
- id: seckill-provider-route
uri: lb://seckill-provider
predicates:
- Path=/seckill-provider/**
- id: message-provider-route
uri: lb://message-provider
predicates:
- Path=/message-provider/**
application:
name: cloud-gateway
eureka:
instance:
prefer-ip-address: true
client:
service-url:
defaultZone: http://localhost:8888/eureka/
注册中心相结合的路由配置方式，与单个URI的路由配置，区别其实很小，仅仅在于URI的schema协议不同。单个URI的地址的schema协议，一般为http或者https协议。
3、路由 匹配规则
Spring Cloud Gateway 的功能很强大，我们仅仅通过 Predicates 的设计就可以看出来，前面我们只是使用了 predicates 进行了简单的条件匹配，其实 Spring Cloud Gataway 帮我们内置了很多 Predicates 功能。
Spring Cloud Gateway 是通过 Spring WebFlux 的 HandlerMapping 做为底层支持来匹配到转发路由，Spring Cloud Gateway 内置了很多 Predicates 工厂，这些 Predicates 工厂通过不同的 HTTP 请求参数来匹配，多个 Predicates 工厂可以组合使用。
gateWay的主要功能之一是转发请求，转发规则的定义主要包含三个部分
| Route（路由） | 路由是网关的基本单元，由ID、URI、一组Predicate、一组Filter组成，根据Predicate进行匹配转发。 |
| Predicate（谓语、断言） | 路由转发的判断条件，目前SpringCloud Gateway支持多种方式，常见如：Path、Query、Method、Header等，写法必须遵循 key=vlue的形式 |
| Filter（过滤器） | 过滤器是路由转发请求时所经过的过滤逻辑，可用于修改请求、响应内容 |
其中Route和Predicate必须同时申明
例子：
//通过配置文件配置
spring:
cloud:
gateway:
routes:
- id: gate_route
uri: http://localhost:9023
predicates:
## 当请求的路径为gate、rule开头的时，转发到http://localhost:9023服务器上
- Path=/gate/**,/rule/**
### 请求路径前加上/app
filters:
- PrefixPath=/app
此文的配置，大部分在demo 工程中已经验证，在 写的过程中， 可能有格式错误
如果遇到问题，可以找尼恩
3.1 Predicate 断言条件(转发规则)介绍
Predicate 来源于 Java 8，是 Java 8 中引入的一个函数，Predicate 接受一个输入参数，返回一个布尔值结果。该接口包含多种默认方法来将 Predicate 组合成其他复杂的逻辑（比如：与，或，非）。可以用于接口请求参数校验、判断新老数据是否有变化需要进行更新操作。
在 Spring Cloud Gateway 中 Spring 利用 Predicate 的特性实现了各种路由匹配规则，有通过 Header、请求参数等不同的条件来进行作为条件匹配到对应的路由。网上有一张图总结了 Spring Cloud 内置的几种 Predicate 的实现。
说白了 Predicate 就是为了实现一组匹配规则，方便让请求过来找到对应的 Route 进行处理，接下来我们接下 Spring Cloud GateWay 内置几种 Predicate 的使用。
- 转发规则（predicates），假设 转发uri都设定为
http://localhost:9023
| 规则 | 实例 | 说明 |
|---|---|---|
| Path | - Path=/gate/,/rule/ | ## 当请求的路径为gate、rule开头的时，转发到http://localhost:9023服务器上 |
| Before | - Before=2017-01-20T17:42:47.789-07:00[America/Denver] | 在某个时间之前的请求才会被转发到 http://localhost:9023服务器上 |
| After | - After=2017-01-20T17:42:47.789-07:00[America/Denver] | 在某个时间之后的请求才会被转发 |
| Between | - Between=2017-01-20T17:42:47.789-07:00[America/Denver],2017-01-21T17:42:47.789-07:00[America/Denver] | 在某个时间段之间的才会被转发 |
| Cookie | - Cookie=chocolate, ch.p | 名为chocolate的表单或者满足正则ch.p的表单才会被匹配到进行请求转发 |
| Header | - Header=X-Request-Id, \\d+ | 携带参数X-Request-Id或者满足\\d+的请求头才会匹配 |
| Host | - Host=www.hd123.com | 当主机名为www.hd123.com的时候直接转发到http://localhost:9023服务器上 |
| Method | - Method=GET | 只有GET方法才会匹配转发请求，还可以限定POST、PUT等请求方式 |
3.1.1 通过请求参数匹配
Query Route Predicate 支持传入两个参数，一个是属性名一个为属性值，属性值可以是正则表达式。
server:
port: 8080
spring:
cloud:
gateway:
routes:
- id: query_route
uri: https://example.org
predicates:
- Query=smile
这样配置，只要请求中包含 smile 属性的参数即可匹配路由。
使用 curl 测试，命令行输入:
curl localhost:8080?smile=x&id=2
经过测试发现只要请求汇总带有 smile 参数即会匹配路由，不带 smile 参数则不会匹配。
还可以将 Query 的值以键值对的方式进行配置，这样在请求过来时会对属性值和正则进行匹配，匹配上才会走路由。
server:
port: 8080
spring:
cloud:
gateway:
routes:
- id: query_route
uri: https://example.org
predicates:
- Query=keep, pu.
这样只要当请求中包含 keep 属性并且参数值是以 pu 开头的长度为三位的字符串才会进行匹配和路由。
使用 curl 测试，命令行输入:
curl localhost:8080?keep=pub
测试可以返回页面代码，将 keep 的属性值改为 pubx 再次访问就会报 404,证明路由需要匹配正则表达式才会进行路由。
3.1.2 通过 Header 属性匹配
Header Route Predicate 和 Cookie Route Predicate 一样，也是接收 2 个参数，一个 header 中属性名称和一个正则表达式，这个属性值和正则表达式匹配则执行。
server:
port: 8080
spring:
cloud:
gateway:
routes:
- id: query_route
uri: https://example.org
predicates:
- Header=X-Request-Id, \\d+
使用 curl 测试，命令行输入:
curl http://localhost:8080 -H "X-Request-Id:88"
则返回页面代码证明匹配成功。将参数-H "X-Request-Id:88"改为-H "X-Request-Id:spring"再次执行时返回404证明没有匹配。
3.1.3 通过 Cookie 匹配
Cookie Route Predicate 可以接收两个参数，一个是 Cookie name ,一个是正则表达式，路由规则会通过获取对应的 Cookie name 值和正则表达式去匹配，如果匹配上就会执行路由，如果没有匹配上则不执行。
server:
port: 8080
spring:
application:
name: api-gateway
cloud:
gateway:
routes:
-id: gateway-service
uri: https://www.baidu.com
order: 0
predicates:
- Cookie=sessionId, test
使用 curl 测试，命令行输入:
curl http://localhost:8080 --cookie "sessionId=test"
则会返回页面代码，如果去掉--cookie "sessionId=test"，后台汇报 404 错误。
3.1.4 通过 Host 匹配
Host Route Predicate 接收一组参数，一组匹配的域名列表，这个模板是一个 ant 分隔的模板，用.号作为分隔符。它通过参数中的主机地址作为匹配规则。
server:
port: 8080
spring:
cloud:
gateway:
routes:
- id: query_route
uri: https://example.org
predicates:
- Host=**.baidu.com
使用 curl 测试，命令行输入:
curl http://localhost:8080 -H "Host: www.baidu.com"
curl http://localhost:8080 -H "Host: md.baidu.com"
经测试以上两种 host 均可匹配到 host_route 路由，去掉 host 参数则会报 404 错误。
3.1.5 通过请求方式匹配
可以通过是 POST、GET、PUT、DELETE 等不同的请求方式来进行路由。
server:
port: 8080
spring:
cloud:
gateway:
routes:
- id: query_route
uri: https://example.org
predicates:
- Method=GET
使用 curl 测试，命令行输入:
# curl 默认是以 GET 的方式去请求
curl http://localhost:8080
测试返回页面代码，证明匹配到路由，我们再以 POST 的方式请求测试。
# curl 默认是以 GET 的方式去请求
curl -X POST http://localhost:8080
返回 404 没有找到，证明没有匹配上路由
3.1.6 通过请求路径匹配
Path Route Predicate 接收一个匹配路径的参数来判断是否走路由。
server:
port: 8080
spring:
cloud:
gateway:
routes:
- id: query_route
uri: https://example.org
predicates:
-Path=/foo/segment
如果请求路径符合要求，则此路由将匹配，例如：/foo/1 或者 /foo/bar。
使用 curl 测试，命令行输入:
curl http://localhost:8080/foo/1
curl http://localhost:8080/foo/xx
curl http://localhost:8080/boo/xx
经过测试第一和第二条命令可以正常获取到页面返回值，最后一个命令报404，证明路由是通过指定路由来匹配。
3.1.7 通过请求 ip 地址进行匹配
Predicate 也支持通过设置某个 ip 区间号段的请求才会路由，RemoteAddr Route Predicate 接受 cidr 符号(IPv4 或 IPv6 )字符串的列表(最小大小为1)，例如 192.168.0.1/16 (其中 192.168.0.1 是 IP 地址，16 是子网掩码)。
server:
port: 8080
spring:
cloud:
gateway:
routes:
- id: query_route
uri: https://example.org
predicates:
- RemoteAddr=192.168.1.1/24
可以将此地址设置为本机的 ip 地址进行测试。
curl localhost:8080
如果请求的远程地址是 192.168.1.10，则此路由将匹配。
3.1.8 组合使用
server:
port: 8080
spring:
application:
name: api-gateway
cloud:
gateway:
routes:
- id: gateway-service
uri: https://www.baidu.com
order: 0
predicates:
- Host=**.foo.org
- Path=/headers
- Method=GET
- Header=X-Request-Id, \\d+
- Query=foo, ba.
- Query=baz
- Cookie=chocolate, ch.p
各种 Predicates 同时存在于同一个路由时，请求必须同时满足所有的条件才被这个路由匹配。
一个请求满足多个路由的断言条件时，请求只会被首个成功匹配的路由转发
3.2 过滤器规则（Filter）
过滤器规则（Filter）
| 过滤规则 | 实例 | 说明 |
|---|---|---|
| PrefixPath | - PrefixPath=/app | 在请求路径前加上app |
| RewritePath | - RewritePath=/test, /app/test | 访问localhost:9022/test,请求会转发到localhost:8001/app/test |
| SetPath | SetPath=/app/ | 通过模板设置路径，转发的规则时会在路径前增加app，path表示原请求路径 |
| RedirectTo | 重定向 | |
| RemoveRequestHeader | 去掉某个请求头信息 |
注：当配置多个filter时，优先定义的会被调用，剩余的filter将不会生效
PrefixPath
对所有的请求路径添加前缀：
spring:
cloud:
gateway:
routes:
- id: prefixpath_route
uri: https://example.org
filters:
- PrefixPath=/mypath
访问/hello的请求被发送到https://example.org/mypath/hello。
RedirectTo
重定向，配置包含重定向的返回码和地址：
spring:
cloud:
gateway:
routes:
- id: prefixpath_route
uri: https://example.org
filters:
- RedirectTo=302, https://acme.org
RemoveRequestHeader
去掉某个请求头信息：
spring:
cloud:
gateway:
routes:
- id: removerequestheader_route
uri: https://example.org
filters:
- RemoveRequestHeader=X-Request-Foo
去掉请求头信息 X-Request-Foo
RemoveResponseHeader
去掉某个回执头信息：
spring:
cloud:
gateway:
routes:
- id: removerequestheader_route
uri: https://example.org
filters:
- RemoveResponseHeader=X-Request-Foo
RemoveRequestParameter
去掉某个请求参数信息：
spring:
cloud:
gateway:
routes:
- id: removerequestparameter_route
uri: https://example.org
filters:
- RemoveRequestParameter=red
RewritePath
改写路径：
spring:
cloud:
gateway:
routes:
- id: rewrite_filter
uri: http://localhost:8081
predicates:
- Path=/test/**
filters:
- RewritePath=/where(?<segment>/?.*), /test(?<segment>/?.*)
SetPath
设置请求路径，与RewritePath类似。
spring:
cloud:
gateway:
routes:
- id: setpath_route
uri: https://example.org
predicates:
- Path=/red/segment
filters:
- SetPath=/segment
如/red/blue的请求被转发到/blue。
SetRequestHeader
设置请求头信息。
spring:
cloud:
gateway:
routes:
- id: setrequestheader_route
uri: https://example.org
filters:
- SetRequestHeader=X-Request-Red, Blue
SetStatus
设置回执状态码。
spring:
cloud:
gateway:
routes:
- id: setstatusint_route
uri: https://example.org
filters:
- SetStatus=401
StripPrefix
跳过指定路径。
spring:
cloud:
gateway:
routes:
- id: nameRoot
uri: https://nameservice
predicates:
- Path=/name/**
filters:
- StripPrefix=2
请求/name/blue/red会转发到/red。
RequestSize
请求大小。
spring:
cloud:
gateway:
routes:
- id: request_size_route
uri: http://localhost:8080/upload
predicates:
- Path=/upload
filters:
- name: RequestSize
args:
maxSize: 5000000
超过5M的请求会返回413错误。
Default-filters
对所有请求添加过滤器。
spring:
cloud:
gateway:
default-filters:
- AddResponseHeader=X-Response-Default-Red, Default-Blue
- PrefixPath=/httpbin
3.3 通过代码进行配置
通过代码进行配置，将路由规则设置为一个Bean即可：
@Bean
public RouteLocator customRouteLocator(RouteLocatorBuilder builder)
return builder.routes()
.route("path_route", r -> r.path("/get")
.uri("http://httpbin.org"))
.route("host_route", r -> r.host("*.myhost.org")
.uri("http://httpbin.org"))
.route("rewrite_route", r -> r.host("*.rewrite.org")
.filters(f -> f.rewritePath("/foo/(?<segment>.*)", "/$segment"))
.uri("http://httpbin.org"))
.route("hystrix_route", r -> r.host("*.hystrix.org")
.filters(f -> f.hystrix(c -> c.setName("slowcmd")))
.uri("http://httpbin.org"))
.route("hystrix_fallback_route", r -> r.host("*.hystrixfallback.org")
.filters(f -> f.hystrix(c -> c.setName("slowcmd").setFallbackUri("forward:/hystrixfallback")))
.uri("http://httpbin.org"))
.route("limit_route", r -> r
.host("*.limited.org").and().path("/anything/**")
.filters(f -> f.requestRateLimiter(c -> c.setRateLimiter(redisRateLimiter())))
.uri("http://httpbin.org"))
.build();
3.4 实现熔断降级
为什么要实现熔断降级？
在分布式系统中，网关作为流量的入口，因此会有大量的请求进入网关，向其他服务发起调用，其他服务不可避免的会出现调用失败（超时、异常），失败时不能让请求堆积在网关上，需要快速失败并返回给客户端，想要实现这个要求，就必须在网关上做熔断、降级操作。
为什么在网关上请求失败需要快速返回给客户端？
因为当一个客户端请求发生故障的时候，这个请求会一直堆积在网关上，当然只有一个这种请求，网关肯定没有问题（如果一个请求就能造成整个系统瘫痪，那这个系统可以下架了），但是网关上堆积多了就会给网关乃至整个服务都造成巨大的压力，甚至整个服务宕掉。因此要对一些服务和页面进行有策略的降级，以此缓解服务器资源的的压力，以保证核心业务的正常运行，同时也保持了客户和大部分客户的得到正确的相应，所以需要网关上请求失败需要快速返回给客户端。
server.port: 8082
spring:
application:
name: gateway
redis:
host: localhost
port: 6379
password: 123456
cloud:
gateway:
routes:
- id: rateLimit_route
uri: http://localhost:8000
order: 0
predicates:
- Path=/test/**
filters:
- StripPrefix=1
- name: Hystrix
args:
name: fallbackCmdA
fallbackUri: forward:/fallbackA
hystrix.command.fallbackCmdA.execution.isolation.thread.timeoutInMilliseconds: 5000
这里的配置，使用了两个过滤器：
（1）过滤器StripPrefix，作用是去掉请求路径的最前面n个部分截取掉。
StripPrefix=1就代表截取路径的个数为1，比如前端过来请求/test/good/1/view，匹配成功后，路由到后端的请求路径就会变成http://localhost:8888/good/1/view。
（2）过滤器Hystrix，作用是通过Hystrix进行熔断降级
当上游的请求，进入了Hystrix熔断降级机制时，就会调用fallbackUri配置的降级地址。需要注意的是，还需要单独设置Hystrix的commandKey的超时时间
fallbackUri配置的降级地址的代码如下：
@RestController
public class FallbackController
@GetMapping("/fallbackA")
public Mono<Void> fallbackA(ServerWebExchange exchange)
exchange.getResponse().setStatusCode(HttpStatus.NOT_ACCEPTABLE);
ServerHttpResponse serverHttpResponse = exchange.getResponse();
serverHttpResponse.getHeaders().add("Content-Type", "application/json;charset=UTF-8");
RestOut<String> stringMasResponse = RestOut.error("服务不可用");
byte[] jsonBytes = JsonUtil.object2JsonBytes(stringMasResponse);
DataBuffer buffer = serverHttpResponse.bufferFactory().wrap(jsonBytes);
return serverHttpResponse.writeWith(Mono.just(buffer));
4、核心类详解
ServerWebExchange
先看ServerWebExchange的注释：
Contract for an HTTP request-response interaction.
Provides access to the HTTP request and response and also exposes additional server-side processing related properties and features such as request attributes.
翻译一下大概是：
ServerWebExchange是一个HTTP请求-响应交互的契约。
提供对HTTP请求和响应的访问，并公开额外的服务器端处理相关属性和特性，如请求属性。
其实，ServerWebExchange命名为服务网络交换器，存放着重要的请求-响应属性、请求实例和响应实例等等，有点像Context的角色。
ServerWebExchange接口
ServerWebExchange接口的所有方法：
public interface ServerWebExchange
// 日志前缀属性的KEY，值为org.springframework.web.server.ServerWebExchange.LOG_ID
// 可以理解为 attributes.set("org.springframework.web.server.ServerWebExchange.LOG_ID","日志前缀的具体值");
// 作用是打印日志的时候会拼接这个KEY对饮的前缀值，默认值为""
String LOG_ID_ATTRIBUTE = ServerWebExchange.class.getName() + ".LOG_ID";
String getLogPrefix();
// 获取ServerHttpRequest对象
ServerHttpRequest getRequest();
// 获取ServerHttpResponse对象
ServerHttpResponse getResponse();
// 返回当前exchange的请求属性，返回结果是一个可变的Map
Map<String, Object> getAttributes();
// 根据KEY获取请求属性
@Nullable
default <T> T getAttribute(String name)
return (T) getAttributes().get(name);
// 根据KEY获取请求属性，做了非空判断
@SuppressWarnings("unchecked")
default <T> T getRequiredAttribute(String name)
T value = getAttribute(name);
Assert.notNull(value, () -> "Required attribute \'" + name + "\' is missing");
return value;
// 根据KEY获取请求属性，需要提供默认值
@SuppressWarnings("unchecked")
default <T> T getAttributeOrDefault(String name, T defaultValue)
return (T) getAttributes().getOrDefault(name, defaultValue);
// 返回当前请求的网络会话
Mono<WebSession> getSession();
// 返回当前请求的认证用户，如果存在的话
<T extends Principal> Mono<T> getPrincipal();
// 返回请求的表单数据或者一个空的Map，只有Content-Type为application/x-www-form-urlencoded的时候这个方法才会返回一个非空的Map -- 这个一般是表单数据提交用到
Mono<MultiValueMap<String, String>> getFormData();
// 返回multipart请求的part数据或者一个空的Map，只有Content-Type为multipart/form-data的时候这个方法才会返回一个非空的Map -- 这个一般是文件上传用到
Mono<MultiValueMap<String, Part>> getMultipartData();
// 返回Spring的上下文
@Nullable
ApplicationContext getApplicationContext();
// 这几个方法和lastModified属性相关
boolean isNotModified();
boolean checkNotModified(Instant lastModified);
boolean checkNotModified(String etag);
boolean checkNotModified(@Nullable String etag, Instant lastModified);
// URL转换
String transformUrl(String url);
// URL转换映射
void addUrlTransformer(Function<String, String> transformer);
// 注意这个方法，方法名是：改变，这个是修改ServerWebExchange属性的方法，返回的是一个Builder实例，Builder是ServerWebExchange的内部类
default Builder mutate()
return new DefaultServerWebExchangeBuilder(this);
interface Builder
// 覆盖ServerHttpRequest
Builder request(Consumer<ServerHttpRequest.Builder> requestBuilderConsumer);
Builder request(ServerHttpRequest request);
// 覆盖ServerHttpResponse
Builder response(ServerHttpResponse response);
// 覆盖当前请求的认证用户
Builder principal(Mono<Principal> principalMono);
// 构建新的ServerWebExchange实例
ServerWebExchange build();
ServerWebExchange#mutate() 方法
注意到ServerWebExchange#mutate()方法，ServerWebExchange实例可以理解为不可变实例，
如果我们想要修改它，需要通过mutate()方法生成一个新的实例，例如这样：
public class CustomGlobalFilter implements GlobalFilter
@Override
public Mono<Void> filter(ServerWebExchange exchange, GatewayFilterChain chain)
ServerHttpRequest request = exchange.getRequest();
// 这里可以修改ServerHttpRequest实例
ServerHttpRequest newRequest = ...
ServerHttpResponse response = exchange.getResponse();
// 这里可以修改ServerHttpResponse实例
ServerHttpResponse newResponse = ...
// 构建新的ServerWebExchange实例
ServerWebExchange newExchange = exchange.mutate().request(newRequest).response(newResponse).build();
return chain.filter(newExchange);
ServerHttpRequest接口
ServerHttpRequest实例是用于承载请求相关的属性和请求体，
Spring Cloud Gateway中底层使用Netty处理网络请求，通过追溯源码，
可以从ReactorHttpHandlerAdapter中得知ServerWebExchange实例中持有的ServerHttpRequest实例的具体实现是ReactorServerHttpRequest。
之所以列出这些实例之间的关系，是因为这样比较容易理清一些隐含的问题，例如：
ReactorServerHttpRequest的父类AbstractServerHttpRequest中初始化内部属性headers的时候把请求的HTTP头部封装为只读的实例：
public AbstractServerHttpRequest(URI uri, @Nullable String contextPath, HttpHeaders headers)
this.uri = uri;
this.path = RequestPath.parse(uri, contextPath);
this.headers = HttpHeaders.readOnlyHttpHeaders(headers);
// HttpHeaders类中的readOnlyHttpHeaders方法，
// ReadOnlyHttpHeaders屏蔽了所有修改请求头的方法，直接抛出UnsupportedOperationException
public static HttpHeaders readOnlyHttpHeaders(HttpHeaders headers)
Assert.notNull(headers, "HttpHeaders must not be null");
if (headers instanceof ReadOnlyHttpHeaders)
return headers;
else
return new ReadOnlyHttpHeaders(headers);
所以, 不能直接从ServerHttpRequest实例中直接获取请求头HttpHeaders实例并且进行修改。
ServerHttpRequest接口如下：
public interface HttpMessage
// 获取请求头，目前的实现中返回的是ReadOnlyHttpHeaders实例，只读
HttpHeaders getHeaders();
public interface ReactiveHttpInputMessage extends HttpMessage
// 返回请求体的Flux封装
Flux<DataBuffer> getBody();
public interface HttpRequest extends HttpMessage
// 返回HTTP请求方法，解析为HttpMethod实例
@Nullable
default HttpMethod getMethod()
return HttpMethod.resolve(getMethodValue());
// 返回HTTP请求方法，字符串
String getMethodValue();
// 请求的URI
URI getURI();
public interface ServerHttpRequest extends HttpRequest, ReactiveHttpInputMessage
// 连接的唯一标识或者用于日志处理标识
String getId();
// 获取请求路径，封装为RequestPath对象
RequestPath getPath();
// 返回查询参数，是只读的MultiValueMap实例
MultiValueMap<String, String> getQueryParams();
// 返回Cookie集合，是只读的MultiValueMap实例
MultiValueMap<String, HttpCookie> getCookies();
// 远程服务器地址信息
@Nullable
default InetSocketAddress getRemoteAddress()
return null;
// SSL会话实现的相关信息
@Nullable
default SslInfo getSslInfo()
return null;
// 修改请求的方法，返回一个建造器实例Builder，Builder是内部类
default ServerHttpRequest.Builder mutate()
return new DefaultServerHttpRequestBuilder(this);
interface Builder
// 覆盖请求方法
Builder method(HttpMethod httpMethod);
// 覆盖请求的URI、请求路径或者上下文，这三者相互有制约关系，具体可以参考API注释
Builder uri(URI uri);
Builder path(String path);
Builder contextPath(String contextPath);
// 覆盖请求头
Builder header(String key, String value);
Builder headers(Consumer<HttpHeaders> headersConsumer);
// 覆盖SslInfo
Builder sslInfo(SslInfo sslInfo);
// 构建一个新的ServerHttpRequest实例
ServerHttpRequest build();
注意：
ServerHttpRequest或者说HttpMessage接口提供的获取请求头方法HttpHeaders getHeaders();
返回结果是一个只读的实例，具体是ReadOnlyHttpHeaders类型，
如果要修改ServerHttpRequest实例，那么需要这样做：
ServerHttpRequest request = exchange.getRequest();
ServerHttpRequest newRequest = request.mutate().header("key","value").path("/myPath").build();
ServerHttpResponse接口
ServerHttpResponse实例是用于承载响应相关的属性和响应体，
Spring Cloud Gateway中底层使用Netty处理网络请求，通过追溯源码，可以从ReactorHttpHandlerAdapter中得知ServerWebExchange实例中持有的ServerHttpResponse实例的具体实现是ReactorServerHttpResponse。
之所以列出这些实例之间的关系，是因为这样比较容易理清一些隐含的问题，例如：
// ReactorServerHttpResponse的父类
public AbstractServerHttpResponse(DataBufferFactory dataBufferFactory, HttpHeaders headers)
Assert.notNull(dataBufferFactory, "DataBufferFactory must not be null");
Assert.notNull(headers, "HttpHeaders must not be null");
this.dataBufferFactory = dataBufferFactory;
this.headers = headers;
this.cookies = new LinkedMultiValueMap<>();
public ReactorServerHttpResponse(HttpServerResponse response, DataBufferFactory bufferFactory)
super(bufferFactory, new HttpHeaders(new NettyHeadersAdapter(response.responseHeaders())));
Assert.notNull(response, "HttpServerResponse must not be null");
this.response = response;
可知ReactorServerHttpResponse构造函数初始化实例的时候，存放响应Header的是HttpHeaders实例，也就是响应Header是可以直接修改的。
ServerHttpResponse接口如下：
public interface HttpMessage
// 获取响应Header，目前的实现中返回的是HttpHeaders实例，可以直接修改
HttpHeaders getHeaders();
public interface ReactiveHttpOutputMessage extends HttpMessage
// 获取DataBufferFactory实例，用于包装或者生成数据缓冲区DataBuffer实例(创建响应体)
DataBufferFactory bufferFactory();
// 注册一个动作，在HttpOutputMessage提交之前此动作会进行回调
void beforeCommit(Supplier<? extends Mono<Void>> action);
// 判断HttpOutputMessage是否已经提交
boolean isCommitted();
// 写入消息体到HTTP协议层
Mono<Void> writeWith(Publisher<? extends DataBuffer> body);
// 写入消息体到HTTP协议层并且刷新缓冲区
Mono<Void> writeAndFlushWith(Publisher<? extends Publisher<? extends DataBuffer>> body);
// 指明消息处理已经结束，一般在消息处理结束自动调用此方法，多次调用不会产生副作用
Mono<Void> setComplete();
public interface ServerHttpResponse extends ReactiveHttpOutputMessage
// 设置响应状态码
boolean setStatusCode(@Nullable HttpStatus status);
// 获取响应状态码
@Nullable
HttpStatus getStatusCode();
// 获取响应Cookie，封装为MultiValueMap实例，可以修改
MultiValueMap<String, ResponseCookie> getCookies();
// 添加响应Cookie
void addCookie(ResponseCookie cookie);
这里可以看到除了响应体比较难修改之外，其他的属性都是可变的。
ServerWebExchangeUtils和上下文属性
ServerWebExchangeUtils里面存放了很多静态公有的字符串KEY值
(这些字符串KEY的实际值是org.springframework.cloud.gateway.support.ServerWebExchangeUtils. + 下面任意的静态公有KEY)，
这些字符串KEY值一般是用于ServerWebExchange的属性(Attribute，见上文的ServerWebExchange#getAttributes()方法)的KEY，这些属性值都是有特殊的含义，在使用过滤器的时候如果时机适当可以直接取出来使用，下面逐个分析。
PRESERVE_HOST_HEADER_ATTRIBUTE：是否保存Host属性，值是布尔值类型，写入位置是PreserveHostHeaderGatewayFilterFactory，使用的位置是NettyRoutingFilter，作用是如果设置为true，HTTP请求头中的Host属性会写到底层Reactor-Netty的请求Header属性中。CLIENT_RESPONSE_ATTR：保存底层Reactor-Netty的响应对象，类型是reactor.netty.http.client.HttpClientResponse。CLIENT_RESPONSE_CONN_ATTR：保存底层Reactor-Netty的连接对象，类型是reactor.netty.Connection。URI_TEMPLATE_VARIABLES_ATTRIBUTE：PathRoutePredicateFactory解析路径参数完成之后，把解析完成后的占位符KEY-路径Path映射存放在ServerWebExchange的属性中，KEY就是URI_TEMPLATE_VARIABLES_ATTRIBUTE。CLIENT_RESPONSE_HEADER_NAMES：保存底层Reactor-Netty的响应Header的名称集合。GATEWAY_ROUTE_ATTR：用于存放RoutePredicateHandlerMapping中匹配出来的具体的路由(org.springframework.cloud.gateway.route.Route)实例，通过这个路由实例可以得知当前请求会路由到下游哪个服务。GATEWAY_REQUEST_URL_ATTR：java.net.URI类型的实例，这个实例代表直接请求或者负载均衡处理之后需要请求到下游服务的真实URI。GATEWAY_ORIGINAL_REQUEST_URL_ATTR：java.net.URI类型的实例，需要重写请求URI的时候，保存原始的请求URI。GATEWAY_HANDLER_MAPPER_ATTR：保存当前使用的HandlerMapping具体实例的类型简称(一般是字符串"RoutePredicateHandlerMapping")。GATEWAY_SCHEME_PREFIX_ATTR：确定目标路由URI中如果存在schemeSpecificPart属性，则保存该URI的scheme在此属性中，路由URI会被重新构造，见RouteToRequestUrlFilter。GATEWAY_PREDICATE_ROUTE_ATTR：用于存放RoutePredicateHandlerMapping中匹配出来的具体的路由(org.springframework.cloud.gateway.route.Route)实例的ID。WEIGHT_ATTR：实验性功能(此版本还不建议在正式版本使用)存放分组权重相关属性，见WeightCalculatorWebFilter。ORIGINAL_RESPONSE_CONTENT_TYPE_ATTR：存放响应Header中的ContentType的值。HYSTRIX_EXECUTION_EXCEPTION_ATTR：Throwable的实例，存放的是Hystrix执行异常时候的异常实例，见HystrixGatewayFilterFactory。GATEWAY_ALREADY_ROUTED_ATTR：布尔值，用于判断是否已经进行了路由，见NettyRoutingFilter。GATEWAY_ALREADY_PREFIXED_ATTR：布尔值，用于判断请求路径是否被添加了前置部分，见PrefixPathGatewayFilterFactory。
ServerWebExchangeUtils提供的上下文属性用于Spring Cloud Gateway的ServerWebExchange组件处理请求和响应的时候，内部一些重要实例或者标识属性的安全传输和使用，使用它们可能存在一定的风险，
因为没有人可以确定在版本升级之后，原有的属性KEY或者VALUE是否会发生改变，如果评估过风险或者规避了风险之后，可以安心使用。
例如我们在做请求和响应日志(类似Nginx的Access Log)的时候，可以依赖到GATEWAY_ROUTE_ATTR，因为我们要打印路由的目标信息。举个简单例子
将多行文件转换为一行
一、需求：
把这些数据库文件转换成一行，然后用scp -r 一次性作拷贝。
二、实例
[[email protected] ~]# cat /tmp/1 ga_10122 ga_10589 ga_11053 ga_11238 ga_11559 ga_11944 ga_12193 ga_13542 ga_35179 ga_36013 ga_36063 ga_36575 ga_36737 ga_36926 ga_37962 ga_39596 ga_39599 ga_39603 ga_39604 ga_39605 ga_39608 ga_39609 ga_39610 ga_39614 ga_39618 ga_39619 ga_39622 ga_39625 ga_39626 ga_39630 ga_39633 ga_39636 ga_39639 ga_39640 ga_39642 ga_39645 ga_39648 ga_39652 ga_39654 ga_39657 ga_39668 ga_39675 ga_39687 ga_39690 ga_39691 ga_39693 ga_39695 ga_39697 ga_39702 ga_39703 ga_39704 ga_39708 ga_39715 ga_39717 ga_39724 ga_39725 ga_39727 ga_39728 ga_39730 ga_39732 ga_39738 ga_39741 ga_39743 ga_39753 ga_39757 ga_39761 ga_39765
三、解决有三种
1、采用awk
[[email protected] ~]# awk BEGIN{RS=EOF}‘{gsub(/\n/," ");print}‘ /tmp/1 ga_10122 ga_10589 ga_11053 ga_11238 ga_11559 ga_11944 ga_12193 ga_13542 ga_35179 ga_36013 ga_36063 ga_36575 ga_36737 ga_36926 ga_37962 ga_39596 ga_39599 ga_39603 ga_39604 ga_39605 ga_39608 ga_39609 ga_39610 ga_39614 ga_39618 ga_39619 ga_39622 ga_39625 ga_39626 ga_39630 ga_39633 ga_39636 ga_39639 ga_39640 ga_39642 ga_39645 ga_39648 ga_39652 ga_39654 ga_39657 ga_39668 ga_39675 ga_39687 ga_39690 ga_39691 ga_39693 ga_39695 ga_39697 ga_39702 ga_39703 ga_39704 ga_39708 ga_39715 ga_39717 ga_39724 ga_39725 ga_39727 ga_39728 ga_39730 ga_39732 ga_39738 ga_39741 ga_39743 ga_39753 ga_39757 ga_39761 ga_39765
awk默认将记录分隔符（record separator即RS）设置为\n，此行代码将RS设置为EOF（文件结束），也就是把文件视为一个记录，然后通过gsub函数将\n替换成空格，最后输出。
2、采用sed
[[email protected] ~]# sed ‘:a ; N;s/\n/ / ; t a ; ‘ /tmp/1 ga_10122 ga_10589 ga_11053 ga_11238 ga_11559 ga_11944 ga_12193 ga_13542 ga_35179 ga_36013 ga_36063 ga_36575 ga_36737 ga_36926 ga_37962 ga_39596 ga_39599 ga_39603 ga_39604 ga_39605 ga_39608 ga_39609 ga_39610 ga_39614 ga_39618 ga_39619 ga_39622 ga_39625 ga_39626 ga_39630 ga_39633 ga_39636 ga_39639 ga_39640 ga_39642 ga_39645 ga_39648 ga_39652 ga_39654 ga_39657 ga_39668 ga_39675 ga_39687 ga_39690 ga_39691 ga_39693 ga_39695 ga_39697 ga_39702 ga_39703 ga_39704 ga_39708 ga_39715 ga_39717 ga_39724 ga_39725 ga_39727 ga_39728 ga_39730 ga_39732 ga_39738 ga_39741 ga_39743 ga_39753 ga_39757 ga_39761 ga_39765
说明：sed默认只按行处理，N可以让其读入下一行，再对\n进行替换，这样就可以将两行并做一行。但是怎么将所有行并作一行呢？可以采用sed的跳转功能。:a 在代码开始处设置一个标记a，在代码执行到结尾处时利用跳转命令t a重新跳转到标号a处，重新执行代码，这样就可以递归的将所有行合并成一行。
3、cat file | xargs
[[email protected] ~]# cat /tmp/1 | xargs ga_10122 ga_10589 ga_11053 ga_11238 ga_11559 ga_11944 ga_12193 ga_13542 ga_35179 ga_36013 ga_36063 ga_36575 ga_36737 ga_36926 ga_37962 ga_39596 ga_39599 ga_39603 ga_39604 ga_39605 ga_39608 ga_39609 ga_39610 ga_39614 ga_39618 ga_39619 ga_39622 ga_39625 ga_39626 ga_39630 ga_39633 ga_39636 ga_39639 ga_39640 ga_39642 ga_39645 ga_39648 ga_39652 ga_39654 ga_39657 ga_39668 ga_39675 ga_39687 ga_39690 ga_39691 ga_39693 ga_39695 ga_39697 ga_39702 ga_39703 ga_39704 ga_39708 ga_39715 ga_39717 ga_39724 ga_39725 ga_39727 ga_39728 ga_39730 ga_39732 ga_39738 ga_39741 ga_39743 ga_39753 ga_39757 ga_39761 ga_39765
以上是关于3W字吃透：微服务网关SpringCloud gateway底层原理和实操的主要内容，如果未能解决你的问题，请参考以下文章
SpringCloud系列SpringCloud微服务网关概述
搭建SpringCloud微服务框架：SpringCloud-Gateway 服务网关处理
搭建SpringCloud微服务框架：SpringCloud-Gateway 服务网关处理
6个顶级SpringCloud微服务开源项目，企业开发必备！