1、网关Gateway应用实践
1.1 背景分析
我们知道,一个大型系统在设计时,经常会被拆分为很多个微服务。那么作为客户端要如何去调用 这么多的微服务呢?客户端可以直接向微服务发送请求,每个微服务都有一个公开的URL,该URL可以直接映射到具体的微服务,如果没有网关的存在,我们只能在客户端记录每个微服务的地址,然后分别去调用。这样的架构,会存在着诸多的问题,例如,客户端请求不同的微服务可能会增加客户端代码或配置的复杂性。还有就是每个服务,在调用时都需要独立认证。并且存在跨域请求,也在一定程度上提高了代码的复杂度。基于微服务架构中的设计及实现上的问题,为了在项目中简化前端的调用逻辑,同时也简化内部服务之间互相调用的复杂度,更好保护内部服务,提出了网关的概念。
1.2 网关概述
网关本质上要提供一个各种服务访问的入口,并提供服务接收并转发所有内外部的客户端调用,还有就是权限认证,限流控制等等。Spring Cloud Gateway是Spring公司基于Spring 5.0,Spring Boot 2.0 和 等技术开发的一个网关组件,它旨在为微服务架构提供一种简单有效的统一的 API入口,负责服务请求路由、组合及协议转换,并且基于 Filter 链的方式提供了权限认证,监控、限流等功能。
1.3 网关优缺点分析
1.3.1 优点
- 性能强劲:是第一代网关Zuul的1.6倍。
- 功能强大:内置了很多实用的功能,例如转发、监控、限流等
- 设计优雅,容易扩展。
1.3.2 缺点
- 依赖Netty与WebFlux(Spring5.0),不是传统的Servlet编程模型(Spring MVC就是基于此模型实现),学习成本高。
- 需要Spring Boot 2.0及以上的版本,才支持
1.4 Gateway入门们案例
1.4.1 业务描述
通过网关作为服务访问入口,对系统中的服务进行访问,例如通过网关服务去访问sca-provider服务.
1.4.2 创建Gateway项目
说明:在Sca-01的父工程中创建Sca-Gateway项目
1.4.3 添加Gateway依赖项
说明:在Gateway.pom文件中添加依赖
<dependency>
<groupId>org.springframework.cloud</groupId>
<artifactId>spring-cloud-starter-gateway</artifactId>
</dependency>
1.4.4 添加application.yml配置文件
server:
port: 9000
spring:
application:
name: sca-gateway
cloud:
gateway:
routes: #配置网关路由规则
- id: route01 #路由id,自己指定一个唯一值即可
uri: http://localhost:8081/ #网关帮我们转发的url
predicates: ###断言(谓此):匹配请求规则
- Path=/nacos/provider/echo/** #请求路径定义,此路径对应uri中的资源
filters: ##网关过滤器,用于对谓词中的内容进行判断分析以及处理
- StripPrefix=1 #转发之前去掉path中第一层路径,例如nacos
说明:
路由(Route) 是 gateway 中最基本的组件之一,表示一个具体的路由信息载体。主要定义了下面的几个信息:
- id,路由标识符,区别于其他 Route。
- uri,路由指向的目的地 uri,即客户端请求最终被转发到的微服务。
- predicate,断言(谓词)的作用是进行条件判断,只有断言都返回真,才会执行路由。
- filter,过滤器用于修改请求和响应信息。
1.4.5 创建启动类
1.4.6 启动服务测试
说明:依次启动sca-provider,sca-gateway服务,然后打开浏览器,进行访问测试,
1.5 小结面试分析
- 什么是网关?服务访问(流量)的一个入口,类似生活中的“海关“
- 为什么使用网关?(服务安全,统一服务入口管理,负载均衡,限流,鉴权)
- Spring Cloud Gateway 应用的初始构建过程(添加依赖,配置)
- Gateway 服务的启动底层是通过谁去实现的?(Netty网络编程框架-ServerSocket)
- Gateway 服务做请求转发时一定要在注册中心进行注册吗?(不一定,可以直接通过远端url进行服务访问)
2、负载均衡设计
2.1 为什么负载均衡
网关才是服务访问的入口,所有服务都会在网关层面进行底层映射,所以在访问服务时,要基于服务serivce id(服务名)去查找对应的服务,让请求从网关层进行均衡转发,以平衡服务实例的处理能力。
2.2 Gateway实现负载均衡
2.2.1 添加依赖
<dependency>
<groupId>com.alibaba.cloud</groupId>
<artifactId>spring-cloud-starter-alibaba-nacos-discovery</artifactId>
</dependency>
2.2.2 修改application.yml文件
server:
port: 9000
spring:
application:
name: sca-gateway
cloud:
nacos:
discovery:
server-addr: localhost:8848
gateway: # API Gateway (负责API管理)
discovery:
locator:
enabled: true #开启基于服务名获取服务实例的功能(基于服务名创建路由)
routes: #网关路由配置
- id: router01 #http://localhost:9000/nacos/provider/echo/hello
#uri: http://localhost:8081
uri: lb://sca-provider #ribbon
predicates: #定义请求规则(请求需要按照此规则设计)
- Path=/nacos/provider/echo/** #请求路径设计
filters:
- StripPrefix=1 #转发之前去掉path中第一层路径,例如nacos
说明:lb指的是从nacos中按照名称获取微服务,并遵循负载均衡策略。同时建议开发阶段打开gateway日志,
logging:
level:
org.springframework.cloud.gateway: debug
2.2.3 启动服务访问测试
说明:将Sca-Provider服务以不同的端口启动访问,反复刷新
2.3 Gateway工作流程
2.4 小结面试
- 网关层面是如何实现负载均衡的?(通过服务名去查找具体的服务实例)
- 网关层面是如何通过服务名查找服务实例的?(Ribbon)
- 你了解Ribbon中的哪些负载均衡算法?(轮询,权重,hash,……可通过IRule接口进行查看分析)
- 网关进行请求转发的流程是怎样,有哪些关键对象?(XxxHandlerMapping,Handler,。。。)
- 网关层面服务的映射方式怎样的?(谓词-path,…,服务名/服务实例)
- 网关层如何记录服务的映射?(通过map,并要考虑读写锁的应用)
3、断言(Predicate)增强分析
3.1 Predicate 简介
Predicate(断言)又称谓词,用于条件判断,只有断言结果都为真,才会真正的执行路由。断言其本质就是定义路由转发的条件。
3.2 Predicate 内置工厂
SpringCloud Gateway包括一些内置的断言工厂,所有这些断言都与http请求的不同属性相匹配
3.2.1 基于Datetime类型的断言工厂
此类型的断言根据时间做判断,主要有三个
- AfterRoutePredicateFactory:判断请求日期是否晚于指定日期
- BeforeRoutePredicateFactory:判断请求日期是否早于指定日期
- BetweenRoutePredicateFactory:判断请求日期是否在指定时间段内
3.3 Predicate 应用案例实践
3.3.1 After测试
-After=2021-08-23T21:59:59.789+08:00[Asia/Shanghai]
当且仅当请求时的时间After配置的时间时,才转发该请求,若请求时的时间不是After配置的时间时,则会返回404 not found。时间值可通过ZonedDateTime.now()获取。
3.3.2 修改配置文件
3.3.3 测试结果
3.3.4 基于header的断言工厂HeaderRoutePredicateFactory
判断请求Header是否具有给定名称且值与正则表达式匹配。例如:
-Header=X-Request-Id, \d+
3.3.5 修改配置文件
3.3.6 测试效果
3.3.7 基于Method请求方法的断言工厂
MethodRoutePredicateFactory接收一个参数,判断请求类型是否跟指定的类型匹配。例如:
-Method=GET
3.3.8 修改配置文件
3.3.9 测试效果
4、小节面试分析
- 何为谓词?(网关中封装了判断逻辑的一个对象)
- 谓词逻辑的设计是怎样的?(谓词判断逻辑返回值为true则进行请求转发)
- 你了解哪些谓词逻辑?(path,请求参数,ip,请求方式,cookie,请求头,….)
- 我们可以自己定义谓词工厂对象吗?(可以的)