Spring Cloud Alibaba - Gateway 入门案例（一）（网关介绍 / Gateway 介绍 / Gateway 快速入门（非阿里组件））

回溯

前面的博文我们讲述了微服务之间的互相调用，微服务的注册以及熔断。那么问题来了，当微服务数量增多的时候，作为客户端，只能不断记录相对应的地址然后调用吗？

什么是网关

大家都都知道在微服务架构中，一个系统会被拆分为很多个微服务。那么作为客户端要如何去调用这么多的微服务呢？如果没有网关的存在，我们只能在客户端记录每个微服务的地址，然后分别去调用。

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

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

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

所谓的API网关，就是指系统的 统一入口，它封装了应用程序的内部结构，为客户端提供统一服务，一些与业务本身功能无关的公共逻辑可以在这里实现，诸如认证、鉴权、监控、路由转发等等。添加上API网关之后，系统的架构图变成了如下所示：

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

• Ngnix+lua
  使用nginx的反向代理和负载均衡可实现对api服务器的负载均衡及高可用lua是一种脚本语言,可以来编写一些简单的逻辑, nginx支持lua脚本。
• Kong
  基于Nginx+Lua开发，性能高，稳定，有多个可用的插件(限流、鉴权等等)可以开箱即用。 问题：只支持Http协议；二次开发，自由扩展困难；提供管理API，缺乏更易用的管控、配置方式。
• Zuul
  Netflix开源的网关，功能丰富，使用JAVA开发，易于二次开发 问题：缺乏管控，无法动态配置；依赖组件较多；处理Http请求依赖的是Web容器，性能不如Nginx。ps（zuul 开源的是1.0版本，已经没人维护 了，不过他们公司有zuul 2.0版本，可惜没有开源）
• Spring Cloud Gateway
  Spring公司为了替换Zuul而开发的网关服务，将在下面具体介绍。

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

Gateway 介绍

Spring Cloud Gateway is built on Spring Boot 2.x, Spring WebFlux, and Project Reactor. As a consequence, many of the familiar synchronous libraries (Spring Data and Spring Security, for example) and patterns you know may not apply when you use Spring Cloud Gateway. If you are unfamiliar with these projects, we suggest you begin by reading their documentation to familiarize yourself with some of the new concepts before working with Spring Cloud Gateway.

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

优点

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

缺点

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

Gateway 快速入门

此入门做一个简单的案例，能通过api网关，访问到微服务。

由于 Gateway 不是传统的 Servlet 编程模型，所以不能直接创建 springBoot 服务，因为它自动添加的依赖会导致冲突。

首先创建一个maven项目取名 api-gateway

在pom文件里面添加依赖，选取官网推荐的当前稳定版本。

创建一个启动类

@SpringBootApplication
public class ApiGarwayApplication {
    
    
    public static void main(String[] args) {
    
    
        SpringApplication.run(ApiGarwayApplication.class);
    }
}

在resources下添加一个配置文件：

里面添加配置：

在server:
  port: 7777
spring:
  application:
    name: api-gateway
  cloud:
    gateway:
      routes:

我们发现 routes 是个集合，那么我们跟进去查询它的配置具体有哪些？


配置项有四个，我这边简要介绍一下：

• id：当前路由标识，要求唯一 （默认值uuid，一般不用，需要自定义）
• uri：请求最终要被转发的地址（微服务的地址）
• order： 路由优先级，数字越小，优先级越高
• predicates： 断言 判断条件，返回值是boolean 转发请求要返回的条件 （也是数组）
• filters：过滤器（在请求传递过程中，对请求做一些手脚）（也是数组）

最终配置：

server:
  port: 7777
spring:
  application:
    name: api-gateway
  cloud:
    gateway:
      routes: # 路由数组  指当请求满足什么样的条件的时候，转发到哪个微服务上
        - id: nacosxfz_route #当前路由标识，要求唯一 （默认值uuid，一般不用，需要自定义）
          uri: http://localhost:8071 #请求最终要被转发的地址
          order: 1 #路由优先级，数字越小，优先级越高
          predicates: #断言 判断条件，返回值是boolean 转发请求要返回的条件 （可以写多个）、
            - Path=/scz_server/** #当请求路径满足path指定的规则时，此路由信息才会正常转发
          filters: #过滤器（在请求传递过程中，对请求做一些手脚）
            - StripPrefix=1 # 在请求转发之前去掉一层路径

为什么要加 StripPrefix？

因为在进行转发的时候，就以上诉配置为例，会把 scz_server 也带上，这样就会在访问路径上多出一个前缀，使得访问失败。

进行测试

微服务控制层如下：

@Slf4j
@RequestMapping("/scz/")
@RestController
public class TestController {
    
    
    @RequestMapping("testNotParamFunction")
    public String testNotParamFunction(){
    
    
        return "success";
    }
}

启动微服务和api网关服务。

浏览器访问 api 网关，能够调用到微服务，证明 api 网关初步搭建成功。

点击测试后，能够正常访问到微服务，证明 api 网关初步搭建成功。