SpringCloud GateWay网关

一、网关基本概念

1、API网关介绍

API 网关出现的原因是微服务架构的出现，不同的微服务一般会有不同的网络地址，而外部客户端可能需要调用多个服务的接口才能完成一个业务需求，如果让客户端直接与各个微服务通信，会有以下的问题：
（1）客户端会多次请求不同的微服务，增加了客户端的复杂性。
（2）存在跨域请求，在一定场景下处理相对复杂。
（3）认证复杂，每个服务都需要独立认证。
（4）难以重构，随着项目的迭代，可能需要重新划分微服务。例如，可能将多个服务合并成一个或者将一个服务拆分成多个。如果客户端直接与微服务通信，那么重构将会很难实施。
（5）某些微服务可能使用了防火墙 / 浏览器不友好的协议，直接访问会有一定的困难。
以上这些问题可以借助 API 网关解决。API 网关是介于客户端和服务器端之间的中间层，所有的外部请求都会先经过 API 网关这一层。也就是说，API 的实现方面更多的考虑业务逻辑，而安全、性能、监控可以交由 API 网关来做，这样既提高业务灵活性又不缺安全性

2、Spring Cloud Gateway

Spring cloud gateway是spring官方基于Spring 5.0、Spring Boot2.0和Project Reactor等技术开发的网关，Spring Cloud Gateway旨在为微服务架构提供简单、有效和统一的API路由管理方式，Spring Cloud Gateway作为Spring Cloud生态系统中的网关，目标是替代Netflix Zuul，其不仅提供统一的路由方式，并且还基于Filer链的方式提供了网关基本的功能，例如：安全、监控/埋点、限流等。

3、Spring Cloud Gateway核心概念

网关提供API全托管服务，丰富的API管理功能，辅助企业管理大规模的API，以降低管理成本和安全风险，包括协议适配、协议转发、安全策略、防刷、流量、监控日志等贡呢。一般来说网关对外暴露的URL或者接口信息，我们统称为路由信息。如果研发过网关中间件或者使用过Zuul的人，会知道网关的核心是Filter以及Filter Chain（Filter责任链）。Sprig Cloud Gateway也具有路由和Filter的概念。
下面介绍一下Spring Cloud Gateway中几个重要的概念。
（1）路由。路由是网关最基础的部分，路由信息有一个ID、一个目的URL、一组断言和一组Filter组成。如果断言路由为真，则说明请求的URL和配置匹配
（2）断言。Java8中的断言函数。Spring Cloud Gateway中的断言函数输入类型是Spring5.0框架中的ServerWebExchange。Spring Cloud Gateway中的断言函数允许开发者去定义匹配来自于http
request中的任何信息，比如请求头和参数等。
（3）过滤器。一个标准的Spring webFilter。Spring cloud gateway中的filter分为两种类型的Filter，分别是Gateway Filter和Global Filter。过滤器Filter将会对请求和响应进行修改处理

如上图所示，Spring cloud Gateway发出请求。然后再由Gateway Handler Mapping中找到与请求相匹配的路由，将其发送到Gateway web handler。Handler再通过指定的过滤器链将请求发送到我们实际的服务执行业务逻辑，然后返回。

Spring cloud Gateway的功能很多很强大，下面简单实现一下负载均衡以及服务发现
引入相关依赖

<dependency>
	<groupId>org.springframework.cloud</groupId>
	<artifactId>spring-cloud-starter-alibaba-nacos-discovery</artifactId>
</dependency>
<dependency>
	<groupId>org.springframework.cloud</groupId>
	<artifactId>spring-cloud-starter-gateway</artifactId>
</dependency>
<!--gson-->
<dependency>
	<groupId>com.google.code.gson</groupId>
	<artifactId>gson</artifactId>
</dependency>
<!--服务调用-->
<dependency>
	<groupId>org.springframework.cloud</groupId>
	<artifactId>spring-cloud-starter-openfeign</artifactId>
</dependency>

添加配置文件

# 服务端口
server.port=8222
# 服务名
spring.application.name=service-gateway
# nacos服务地址
spring.cloud.nacos.discovery.server-addr=127.0.0.1:8848
#使用服务发现路由
spring.cloud.gateway.discovery.locator.enabled=true
#设置路由id 0代表第一个服务
spring.cloud.gateway.routes[0].id=service-edu
#设置路由的uri lb://nacos注册的服务名称
spring.cloud.gateway.routes[0].uri=lb://service-edu
#设置路由断言,代理servicerId为auth-service的/auth/路径
spring.cloud.gateway.routes[0].predicates= Path=/eduservice/**
#设置路由id
spring.cloud.gateway.routes[1].id=service-msm
#设置路由的uri lb://nacos注册的服务名称
spring.cloud.gateway.routes[1].uri=lb://service-msm
#设置路由断言,代理servicerId为auth-service的/auth/路径
spring.cloud.gateway.routes[1].predicates= Path=/edumsm/**

记得在启动类上添加上@EnableDiscoveryClient 注解因为gateway需要结合nacos一起使用
确保gateway网关模块和其他模块都在nacos中注册了，如

原本edu模块的端口号是8001，现在去访问gateway模块的8222端口也能访问到edu的服务了，这样就实现了服务发现 负载均衡（gateway能自动帮助我们负载均衡，无需再做其他的配置）。这样是不是就觉得能抛弃nginx了呢？
其实实际项目中更多是是nginx和gateway结合一起使用的，主要是因为gateway相当于还是业务系统的一部分，一旦发生宕机整个系统将不可访问。在gateway前面一定要再加nginx。nginx后端对应多个gateway，nginx只是代理流量转发没有任何业务逻辑，这样既能保证稳定，又能实现横向负载均衡。
即：Nginx先将客户端的请求负载均衡到SpringGateway，然后SpringGateway再通过服务发现，将请求负载均衡到各个业务微服务上。

此外nignx与gateway结合还能实现动静分离
在实际的开发中，有些请求需要通过后台处理，有些请求则不需要。需要后台处理的文件称之为动态资源，不要后台处理的称之为静态资源。那么我们可以将静态资源部署在nginx上，将动态资源部署在微服务集群上，这样能提高资源的响应速度。