关于后端:吃透微服务-服务网关之Gateway

大家好，我是小菜。

一个心愿可能成为 吹着牛 X 谈架构 的男人！如果你也想成为我想成为的人，不然点个关注做个伴，让小菜不再孤独！

本文次要介绍 SpringCloud 之服务网关 Gateway

如有须要，能够参考

如有帮忙，不忘 点赞 ❥

微信公众号已开启，小菜良记，没关注的同学们记得关注哦！

前段时间与小伙伴闲聊时说到他们公司的现状，近来与未来，公司将全面把单体服务向微服务架构过渡。这外面咱们听到了关键词 — 微服务。乍听之下，感觉也很正当。互联网在一直的倒退，这里不只是行业的倒退，更是零碎架构的倒退。当初市面上架构大抵也经验了这几个阶段：

这是坏事吗？是坏事，毋庸置疑。因为不跟上时代的浪潮，总会被拍死在沙滩上。但齐全是坏事吗？那也不见得。

咱们先要明确微服务解决了什么问题？大方面上应该就是利用层面和人层面的问题

• 利用层面： 单体服务的架构很简略，我的项目开发和保护成本低是它无争议的长处。然而臃肿耦合又会给基础设施带来了过重的累赘。如果某个利用解决资源占用了大量的 CPU，就会导致其余解决资源饿死的景象，零碎提早增高，间接影响零碎的可用性。
• 人层面： 独立 、 多语言生态 也是微服务的标签。在单体服务中，投入的人力资源越多不见得越高效，反而越容易出错。但微服务不同，每个服务都是独立进去的，团队能够更加容易的合作开发，甚至一套零碎，多个服务，多种语言，毫无抵触。

然而咱们凡事不能被益处蒙蔽。微服务的毛病也是始终存在的：

• 须要思考各个服务之间的容错性问题
• 须要思考数据一致性问题
• 须要思考分布式事务问题
• …

很多人认为微服务的外围就是在于 微 。服务分的越细越好，就如同平时写代码的时候丝毫不思考的繁多准则，反而在服务拆分上用到酣畅淋漓。这里就须要明确一个外围概念： 微服务的要害不在微，而是在于适合的大小

这句话如同很简略的样子，然而多大才算适合的大小？这可能据不同团队，不同我的项目而定。适合的大小可能取决于更少的代码仓库，更少的部署队列，更少的语言 … 这里更无奈一锤定音！

如果没法做到适合的大小，而无脑的拆分服务，那么微服务可能反而成为你我的项目的累赘。因而，有时全面转型微服务反而不是坏事，你感觉呢？

话题有点跑远了，咱们致力扯回来。既然微服务曾经成为支流，那么如何设计微服务便是咱们应该做的事，而不是谈及微服务之时，想到的只是与人如何争执如何拒用微服务。那么这篇咱们要讲的是SpringCloud 之服务网关 Gateway

SpringCloud 之服务网关 Gateway

一、意识网关

什么是服务网关？不要给本人当头一棒。咱们换个问法，为什么须要服务网关？

服务网关是跨一个或多个服务节点提供单个对立的拜访入口

它的作用并不是可有可无的存在，而是至关重要。咱们能够在服务网关做 路由转发 和过滤器 的实现。长处简述如下：

• 避免外部服务关注裸露给内部客户端
• 为咱们外部多个服务增加了额定的平安层
• 减低微服务拜访的复杂性

依据图中内容，咱们能够得出以下信息：

• 用户拜访入口，对立通过网关拜访到其余微服务节点
• 服务网关的性能有 路由转发 ，API 监控、 权限管制 、 限流

而这些便是 服务网关 存在的意义！

1）Zuul 比拟

SpringCloud Gateway 是 SpringCloud 的一个全新我的项目，指标是取代 Netflix Zuul。它是基于 Spring5.0 + SpringBoot2.0 + WebFlux 等技术开发的，性能高于 Zuul，据官网提供的信息来看，性能是 Zuul 的 1.6 倍，意在为微服务架构提供一种简略无效的对立的 API 路由治理形式。

SpringCloud Gateway 不仅提供了对立的路由形式（反向代理），并且基于 Filter 链（定义过滤器对申请过滤）提供了网关根本的性能，例如：鉴权、流量管制、熔断、门路重写、日志监控等。

其实说到 Netflix Zuul，在应用或筹备应用微服务架构的小伙伴应该并不生疏，毕竟 Netflix 是一个老牌微服务开源者。新秀与老牌之间的抢夺，如果新秀没有点硬实力，如何让人安心转型！

这里咱们能够顺带理解一下 Weflux，Webflux 的呈现填补了 Spring 在响应式编程上的空白。

可能有很多小伙伴并不知道 Webflux，小菜接下来也会出一篇对于 Webflux 的解说，实则真香！

Webflux 的响应式编程不仅仅是编程格调上的扭转，而是对于一系列驰名的框架都提供了响应式拜访的开发包，比方 Netty、Redis（如果不晓得 Netty 的实力，能够想想为什么 Nginx 能够承载那么大的并发，底层就是基于 Netty）

那么说这么多，跟 Zuul 有什么关系呢？咱们能够看下 Zuul 的 IO 模型

SpringCloud 中所集成的 Zuul 版本，采纳的是 Tomcat 容器，应用的是传统的 Servlet IO 解决模型。Servlet 是由 Servlet Container 治理生命周期的。

但问题就在于 Servlet 是一个简略的网络 IO 模型，当申请进入到 ServletContainer就会为其绑定一个线程，在并发不高的场景下这种模型是没有问题的，然而一旦并发上来了，线程数量就会减少。那导致的问题就是频繁进行上下文切换，内存耗费重大，解决申请的工夫就会变长。正所谓牵一发而动全身！

而 SpriingCloud Zuul 便是基于 servlet 之上的一个阻塞式解决模型，即 Spring 实现了解决所有 request 申请的一个 servlet（DispatcherServlet），并由该 Servlet 阻塞式解决。尽管 SpringCloud Zuul 2.0 开始，也是用了 Netty 作为并发 IO 框架，然而 SpringCloud 官网曾经没有集成该版本的打算！

注：这里没有推崇 Gateway 的意思，具体应用依具体我的项目而定

三、把握网关

1. Gateway 依赖

最要害的一步便是引入网关的依赖

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

2. 我的项目构造

我这里简略的创立了一个微服务项目，我的项目里有一个 store-gateway 服务网关 和一个 store-order 订单服务。因为咱们这篇只阐明服务网关的作用，不须要太多服务提供者和消费者！

在 store-order 订单服务中只有一个控制器OrderController，外面也只有一个简略到发指的 API

@RestController
@RequestMapping("order")
public class OrderController {@GetMapping("/{id:.+}")
    public String detail(@PathVariable String id) {return StringUtils.join("获取到了 ID 为", id, "的商品");
    }
    
}

咱们别离启动两个服务，而后拜访订单服务的 API：

后果必定是合乎预期的，不至于翻车。8001 是订单服务的接口，这个时候咱们能够理解到，原来微服务架构每个服务独立启动，都是能够独立拜访的，也就相当于传统的单体服务。

咱们想想看，如果用端口来辨别每个服务，是否也能够达到微服务的成果？实践上如同是能够的，然而如果成千盈百个服务呢？端口爆炸，保护爆炸，治理爆炸 … 不说别的，心态间接爆炸了！这个时候咱们就想着如果只用对立的一个端口拜访各个服务，那该多好！端口统一，路由前缀不统一，通过路由前缀来辨别服务，这种形式将咱们带入了服务网关的场景。是的，这里就说到了服务网关的性能之一 — 路由转发。

3. 网关呈现

既然要用到网关，那咱们下面创立的服务之一 store-gateway 就派上用场了！怎么用？咱们在配置文件做个简略的批改：

spring:
  application:
    name: store-gateway
  cloud:
    gateway:
      routes: 
        - id: store-order 
          uri: http://localhost:8001 
          order: 1
          predicates:
            - Path=/store-order/** 
          filters:
            - StripPrefix=1

不多废话，咱们间接启动网关，通过拜访http://localhost:8000/store-order/order/123 看是否能获取到订单？

很顺利，咱们胜利拿到了 ID 为 123 的订单商品！

咱们看下 URL 的组成：

可能拜访到咱们的服务，阐明网关配置失效了，咱们再来看下这么配置项是怎么一回事！

spring.cloud.gateway 这个是服务网关 Gateway 的配置前缀，没什么好说的，本人须要记住就是了。

routes 以下就是咱们值得关注的了，routes 是个复数模式，那么能够必定，这个配置项是个数组的模式，因而意味着咱们能够配多个路由转发，当申请满足什么条件的时候转到哪个微服务上。

• id： 以后路由的 惟一 标识
• uri： 申请要转发到的地址
• order：路由的优先级，数字越小级别越高
• predicates： 路由须要满足的条件，也是个数组（这里是 或的关系）
• filters： 过滤器，申请在传递过程中能够通过过滤器对其进行肯定的批改

理解完必要的参数，咱们也高高兴兴去部署应用了，然而好景不长，咱们又迎来了新的问题。我订单服务原先应用的 8001 端口，因为某些起因给其余服务应用了，这个时候小脑袋又大了，这种状况必定不会呈现 上错花轿嫁对郎 的后果！

咱们想想看这种问题要怎么解决比拟适合？既然都采纳微服务了，那咱们能不能采纳服务名的形式跳转拜访，这样子无论端口怎么变，都不会影响到咱们的失常业务！那如果采纳服务的形式，就须要一个 注册核心 ，这样子咱们启动的服务能够同步到 注册核心 的 注册表 中，这样子网关就能够依据 服务名 去注册核心中寻找服务进行路由跳转了！那咱们就须要一个注册核心，这里就采纳 Nacos 作为注册核心.

对于 Nacos 的理解，能够空降 微服务新秀之 Nacos，看了就会，我说的！

咱们别离在服务网关 和 订单服务的配置文件都做了以下配置：

启动两个服务后，咱们能够在 Nacos 的控制台服务列表中看到两个服务：

这个时候能够看到 订单服务 的服务名为：store-order，那咱们就能够在网关配置文件局部做以下批改：

这里的配置与上述不同点之一 http 换成了 lb（lb 指的是从 nacos 中依照名称获取微服务，并遵循负载平衡策略），之二 端口 换成了 服务名

那咱们持续拜访上述 URL 看是否可能胜利拜访到订单服务：

后果仍然没有翻车！这样子，不论订单服务的端口如何扭转，只有咱们的服务名不变，那么始终都能够拜访到咱们的对应的服务！

日子一天一天的过来~ 服务也一点一点的减少！终于有一天小菜烦了，因为每次减少服务都得去配置文件中减少一个routes 的配置列，尽管也只是 CV 的操作，然而，哪一天小菜不小心手一抖，那么~~~ 算了算了，找找看有没有什么能够偷懒的写法，终于不负小菜心，找到了一种简化版！配置如下：

就这？是的，就这！管你服务再怎么多，我配置文件都不必批改。这样子配置的目标便是申请对立形式都是变成了 网关地址: 网关端口 / 服务名 / 接口名 的形式拜访。再次拜访页面，仍然行得通！

然而不便归不便，在不便的同时也限度了很多扩大性能，因而应用需三思！不可 贪懒！

四、把握外围

下面曾经说完了网关的简略应用，看完的小伙伴必定曾经能够上手了！接下来咱们持续趁热打铁，理解下 Gateway 网关的外围。不说别的，路由转发 必定是网关的外围！咱们从下面曾经理解到一个具体路由信息载体，次要定义了以下几个信息（ 回顾下）：

• id： 路由的惟一标识，区别于其余 Route
• uri： 路由指向目的地 uri，即客户端申请最终被转发到的微服务
• order： 用于多个 Route 之间的排序，数值越小排序越靠前，匹配优先级越高
• predicate： 用来进行条件判断，只有断言都返回真，才会真正的执行路由
• filter： 过滤器用于批改申请和响应信息

这里来梳理一下拜访流程：

这张图很分明的形容服务网关的调用流程（自觉自信）

1. GatewayClient 向 GatewayServer 发出请求
2. 申请首先会被 HttpWebHandlerAdapter 进行提取组转成网关上下文
3. 而后网关的上下文会传递到 DispatcherHandler，它负责将申请分发给 RoutePredicateHandlerMapping
4. RoutePredicateHandlerMapping负责路由查找，并更具路由断言判断路由是否可用
5. 如果断言胜利，由 FilteringWebHandler 创立过滤器链并调用
6. 申请会一次通过 PreFilter —> 微服务 —> PostFilter 的办法，最终返回响应

过程理解了，咱们抽取一下其中的要害！断言 和 过滤器

1. 断言

Predicate 也就是断言，次要实用于进行条件判断，只有断言都返回真，才会真正执行路由

1）断言工厂

SpringCloud Gateway 中内置了许多断言工厂，所有的这些断言都和 HTTP 申请不同的属性相匹配，具体如下；

• 基于 Datetime 类型的断言工厂

该类型的断言工厂是依据工夫做判断的

1、AfterRoutePredicateFactory： 接管 一个 日期参数，判断申请日期是否晚于指定日期

2、BeforeRoutePredicateFactory：接管 一个 日期参数，判断申请日期是否早于指定日期

3、BetweenRoutePredicateFactory：接管 两个 日期参数，判断申请日期是否在指定时间段内

• 基于近程地址的断言工厂 RemoteAddrRoutePredicateFactory

该类型的断言工厂是接管 一个参数，IP 地址端，判断申请主机地址是否在地址段中。（eq：-RemoteAddr=192.168.1.1/24）

• 基于 Cookie 的断言工厂 CookieRoutePredicateFactory

该类型的断言工厂接管 两个参数，Cookie 名字和一个正则表达式，判断申请 cookie 是否具备给定名称且值与正则表达式匹配。（eq：-Cookie=cbuc）

• 基于 Header 的断言工厂 HeaderRoutePredicateFactory

该类型的断言工厂接管 两个参数，题目名称和正则表达式。判断申请 Header 是否具备给定名称且值与正则表达式匹配。（eq：-Header=X-Request）

• 基于 Host 的断言工厂 HostRoutePredicateFactory

该类型的断言工厂接管 一个参数，主机名模式。判断申请的host 是否满足匹配规定。（eq：-Host=**.cbuc.cn）

• 基于 Method 申请办法的断言工厂 MethodRoutePredicateFactory

该类型的断言工厂接管 一个参数，判断申请类型是否跟指定的类型匹配。（eq：-Method=GET）

• 基于 Path 申请门路的断言工厂 PathRoutePredicateFactory

该类型的断言工厂接管 一个参数，判断申请的 URI 局部是否满足门路规定。（-eq：-Path=/order/）

• 基于 Query 申请参数的断言工厂 QueryRoutePredicateFactory

该类型的断言工厂接管 两个参数，申请 Param 和 正则表达式。判断申请参数是否具备给定名称且值与正则表达式匹配。（eq：-Query=cbuc）

• 基于路由权重的断言工厂 WeightRoutePredicateFactory

该类型的断言工厂接管 一个[组名，权重]，而后对于同一个组内的路由依照权重转发

2）应用

这么多断言工厂，这里就不一一应用演示了，咱们联合几个断言工厂的应用演示一下。

咱们老样子不多废话，间接上代码：

CustomPredicateRouteFactory

配置文件

测试后果

success

fail

惊呼 Amazing 的同时，不要焦急的往下看，咱们回归代码，看看，为什么一个能够拜访胜利，一个却拜访失败了。两个方面：1. 两者拜访的 URL 有哪些不同 2. 代码哪局部对 URL 做出了解决

先养成独立思考，再去看解决办法

当你思考完后，可能局部同学曾经有后果了，那让咱们持续往下看！首先是一个 CustomRoutePredicateFactory类，这个类的作用有点像拦截器，在做申请转发的时候进行了拦挡，咱们申请的时候能够打个断点：

能够看到，的确是拦截器的性能，在每个申请发动的时候做了拦挡。那问题 2 的后果就进去了，原来 URL 解决是在 RoutePredicateFactory 中做了解决，在 apply 办法中能够通过 exchange.getRequest() 拿到 ServerHttpRequest 对象，从而能够获取到申请的参数、申请形式、申请头等信息。shortcutFieldOrder()办法也是重写的要害之一，咱们须要这里返回，咱们实体类中定义的属性，而后在 apply() 办法中能力接管到咱们赋值的属性参数！

留神：如果自定义的实体中有多个属性须要判断，shortcutFieldOrder()办法中的程序要跟配置文件中的参数程序统一

那么当咱们编写了该断言工厂后，如果让之失效？@Component 这个注解必定必不可少了，目标就是让 Spring 容器治理。那么曾经注册的断言工厂如何申明应用呢？那就得回到配置文件了！

咱们这里重点看 predicates 这个配置项下的配置，别离有三个配置，一个是咱们曾经相熟的 Path，其余两个有点生疏，然而这里再看看 Custom 是不是又有点眼生？是的，咱们在下面如同定义了一个叫 CustomRoutePredicate 的断言工厂，两者有点类似，又如同差点什么。那我就再给你一个提醒：

咱们看下形象的断言工厂有哪些自实现的类！其中是不是有 PathRoutePredicateFactory，没错，就是你想的那样！有没有一种 拨开雨雾见青天 的感觉！原来咱们配置文件的 key 是以类名的前缀申明的，也就是说断言工厂类的格局必须是： 自定义名称 + RoutePredicateFactory 为后缀，而后在配置文件中申明。这样子触类旁通，咱们自然而然的就分明了 - Before 的作用，该作用便是： 限度申请工夫在 xxx 之前。

而 – Custom=cbuc，这个 cbuc 便是咱们限度的规定，只有 name 为 cbuc 的用户能力申请胜利。如果有多个参数，能够用 , 隔开，程序须要与断言工厂中shortcutFieldOrder() 返回参数的程序统一！

如果在自定义断言工厂的途中遇到了什么妨碍，不然看看内置的断言工厂是如何实现的。多看源码总没错！

2. 过滤器

接下来进入第二个外围，也就是过滤器。该外围的作用也挺简略，就是在申请的传递过程中，对申请和响应做一系列的手脚。为了怕你划回去看申请流程过于麻烦，小菜贴心的再贴一遍流程图：

在 Gateway 的过滤器中又能够分为 部分过滤器 和 全局过滤器 。听名称就晓得其作用， 部分 是用于某一个路由上的， 全局 是用于所有路由上的。不过不论是 部分 还是 全局，生命周期都分为 pre 和 post。

• pre： 作用于路由到微服务之前调用。咱们能够利用这种过滤器实现身份验证、在集群中抉择申请的微服务，记录调试记录等
• post： 作用于路由到微服务之后执行。咱们能够利用这种过滤器用来响应增加规范的 HTTP Header，收集统计信息和指标、将响应从微服务发送到客户端。

1）部分过滤器

部分过滤器是针对于单个路由的过滤器。同样 Gateway 曾经内置了许多过滤器

咱们选几种罕用的过滤器进行阐明：（下列过滤器省略后缀 GaewayFilterFactory，残缺名称为 前缀 + 后缀）

内置的过滤器小伙伴们能够本人尝试一番，有问题欢送发问！

咱们接下来讲讲如何自定义过滤器工厂。don't say so much，咱们上代码

CustomGatewayFilterFactory

配置文件

当咱们开启申请计数的时候，能够看到控制台对于申请次数作了统计：

因而咱们能够通过这种形式轻松实现部分过滤器

2）全局过滤器

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

老样子，咱们先看看 Gateway 中存在哪些全局过滤器：

绝对于部分过滤器，全局过滤器的命名就没有太多束缚了，毕竟不须要在配置文件中进行配置。

咱们相熟一下经典的全局过滤器

理解完内置的过滤器，咱们再看看如何定义全局的过滤器！

CustomerGlobalFilter

对于全局过滤器，咱们不须要在配置文件中配置，因为是作用于所有路由

测试后果

success

fail

能够看到，咱们应用全局过滤器进行了 鉴权 解决，如果没有携带 token 将无法访问！

到这里咱们曾经理解到了服务网关的路由转发，权限校验甚至于能够基于 断言和过滤器 做出粗略简略的 API 监控和限流

但其实对于 API 监控 和 限流，SpringCloud 中曾经有了更好的组件实现这两项工作。毕竟繁多准则，做的越多往往错的也越多！

前面会持续整顿对于 SpringCloud 组件的文章，敬请关注！

对于微服务的框架，孰好孰坏由咱们本人断定。然而不论孰好孰坏，面对一门新技术的产生，咱们最须要做的便是接管它，容纳它，而后用好它，是骡子是马，本人溜溜就晓得了。

不要空谈，不要贪懒，和小菜一起做个 吹着牛 X 做架构 的程序猿吧~ 点个关注做个伴，让小菜不再孤独。咱们下文见！

明天的你多致力一点，今天的你就能少说一句求人的话！

我是小菜，一个和你一起变强的男人。 💋

微信公众号已开启，小菜良记，没关注的同学们记得关注哦！