一、网关基本概念
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上，将动态资源部署在微服务集群上，这样能提高资源的响应速度。