5.微服务项目实战---Gateway--服务网关，实现统一认证、鉴权、监控、路由转发等

5.1 网关简介

大家都都知道在微服务架构中，一个系统会被拆分为很多个微服务。那么作为客户端要如何去调用

这么多的微服务呢？如果没有网关的存在，我们只能在客户端记录每个微服务的地址，然后分别去调用。

 这样的架构，会存在着诸多的问题：

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

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

所谓的 API 网关，就是指系统的 统一入口 ，它封装了应用程序的内部结构，为客户端提供统一服

务，一些与业务本身功能无关的公共逻辑可以在这里实现，诸如认证、鉴权、监控、路由转发等等。

添加上 API 网关之后，系统的架构图变成了如下所示：

我们也可以观察下，我们现在的整体架构图：

在业界比较流行的网关，有下面这些：

• Ngnix+lua

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

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

• Kong

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

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

• Zuul Netflflix开源的网关，功能丰富，使用JAVA开发，易于二次开发 问题：缺乏管控，无法动态配 置；依赖组件较多；处理Http请求依赖的是Web容器，性能不如Nginx
• Spring Cloud Gateway

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

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

5.2 Gateway简介

Spring Cloud Gateway 是 Spring 公司基于 Spring 5.0 ， Spring Boot 2.0 和 Project Reactor 等技术

开发的网关，它旨在为微服务架构提供一种简单有效的统一的 API 路由管理方式。它的目标是替代 Netflflix Zuul，其不仅提供统一的路由方式，并且基于 Filter 链的方式提供了网关基本的功能，例如：安全，监控和限流。

优点：

• 性能强劲：是第一代网关Zuul的1.6倍
• 功能强大：内置了很多实用的功能，例如转发、监控、限流等
• 设计优雅，容易扩展

缺点：

• 其实现依赖Netty与WebFlux，不是传统的Servlet编程模型，学习成本高
• 不能将其部署在Tomcat、Jetty等Servlet容器里，只能打成jar包执行
• 需要Spring Boot 2.0及以上的版本，才支持

5.3 Gateway快速入门

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

5.3.1 基础版

第 1 步：创建一个 api - gateway 的模块 , 导入相关依赖

第 2 步 : 创建主类

第 3 步 : 添加配置文件

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

5.3.2 增强版

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

注册中心获取此地址。

第 1 步：加入 nacos 依赖

第2步：在主类上添加注解

第 3 步：修改配置文件

第 4 步 : 测试

5.3.3 简写版

第 1 步 : 去掉关于路由的配置

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

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

5.4 Gateway核心架构

5.4.1 基本概念

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

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

5.4.2 执行流程

执行流程大体如下：

1. Gateway Client向Gateway Server发送请求
2.  请求首先会被HttpWebHandlerAdapter进行提取组装成网关上下文
3. 然后网关的上下文会传递到DispatcherHandler，它负责将请求分发给 RoutePredicateHandlerMapping
4. RoutePredicateHandlerMapping负责路由查找，并根据路由断言判断路由是否可用
5. 如果过断言成功，由FilteringWebHandler创建过滤器链并调用
6. 请求会一次经过PreFilter--微服务--PostFilter的方法，最终返回响应

5.5 断言

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

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

5.5.1 内置路由断言工厂

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

• 基于Datetime类型的断言工厂

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

1. AfterRoutePredicateFactory： 接收一个日期参数，判断请求日期是否晚于指定日期
2. BeforeRoutePredicateFactory： 接收一个日期参数，判断请求日期是否早于指定日期
3. BetweenRoutePredicateFactory： 接收两个日期参数，判断请求日期是否在指定时间段内

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

• 基于远程地址的断言工厂 RemoteAddrRoutePredicateFactory：接收一个IP地址段，判断请求主机地址是否在地址段中

-RemoteAddr=192.168.1.1/24

• 基于Cookie的断言工厂

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

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

-Cookie=chocolate, ch.

• 基于Header的断言工厂

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

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

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

• 基于Host的断言工厂

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

-Host=**.testhost.org

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

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

-Method=GET

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

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

-Path=/foo/{segment}

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

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

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

-Query=baz, ba.

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

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

routes:

-id: weight_route1 uri: host1 predicates:

-Path=/product/**

-Weight=group3, 1

-id: weight_route2 uri: host2 predicates:

-Path=/product/**

-Weight= group3, 9

内置路由断言工厂的使用

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

5.5.2 自定义路由断言工厂

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

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

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

第3 步：启动测试

5.6 过滤器

三个知识点:

1. 作用: 过滤器就是在请求的传递过程中,对请求和响应做一些手脚
2. 生命周期: Pre Post
3. 分类: 局部过滤器(作用在某一个路由上) 全局过滤器(作用全部路由上)

在Gateway中, Filter的生命周期只有两个：“pre” 和 “post”。

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

Gateway 的Filter从作用范围可分为两种: GatewayFilter与GlobalFilter。

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

5.6.1 局部过滤器

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

5.6.1.1 内置局部过滤器

在 SpringCloud Gateway 中内置了很多不同类型的网关路由过滤器。具体如下：

内置局部过滤器的使用

5.6.1.2 自定义局部过滤器

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

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

第 3 步：启动测试

5.6.2 全局过滤器

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

5.6.2.1 内置全局过滤器

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

5.6.2.2 自定义全局过滤器

内置的过滤器已经可以完成大部分的功能，但是对于企业开发的一些业务功能处理，还是需要我们

自己编写过滤器来实现的，那么我们一起通过代码的形式自定义一个过滤器，去完成统一的权限校验。

开发中的鉴权逻辑：

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

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

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

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

5.7 网关限流

网关是所有请求的公共入口，所以可以在网关进行限流，而且限流的方式也很多，我们本次采用前

面学过的 Sentinel 组件来实现网关的限流。 Sentinel 支持对 SpringCloud Gateway 、 Zuul 等主流网关进行限流。

从 1.6.0 版本开始， Sentinel 提供了 SpringCloud Gateway 的适配模块，可以提供两种资源维度的限流：

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

1 导入依赖

2 编写配置类

基于 Sentinel 的 Gateway 限流是通过其提供的 Filter 来完成的，使用时只需注入对应的

SentinelGatewayFilter 实例以及 SentinelGatewayBlockExceptionHandler 实例即可。

3 测试

在一秒钟内多次访问 http://localhost:7000/product-serv/product/1 就可以看到限流启作用了。

 

4 自定义 API 分组

自定义 API 分组是一种更细粒度的限流规则定义