上一篇文章我们了解了微服务间各服务通信组件Dubbo的使用，无论是通过RESTFul还是RPC通信，都是为了实现服务间的信息传递，属于微服务架构内部的事情。而对于用户端来说是不用理会这些事情的。但微服务如何有效管理？微服务又将如何将接口暴露给用户呢？这就需要API网关来实现了。那么这篇文章，我们就一起来看看API网关的相关知识。

本篇文章主要从三个方面来介绍：

• 1、什么是API网关？有哪些产品能实现API网关？
• 2、SpringCloud GateWay如何配置？

下面我们来一起看看。

一、什么是API网关？

API网关是一种软件组件，它充当客户端与后端服务之间的中介，负责管理和控制对后端服务的访问。

二、API网关有什么作用？

对于微服务来说，将接口直接暴露给用户的做法是错误的，主要会有以下几个问题：

1、服务将所有 API 接口对外直接暴露给用户端，那么用户可能越权访问不属于它的功能，例如普通的用户去访问管理员的高级功能。这本身就是不安全和不可控的。

2、后台服务可能采用不同的通信方式，如服务 A 采用 RESTful 通信，服务 B 采用 RPC 通信，不同的接入方式让用户端接入困难。尤其是 App 端接入 RPC 过程更为复杂。

3、在服务访问前很难做到统一的前置处理，如服务访问前需要对用户进行鉴权，这就必须将鉴权代码分散到每个服务模块中，随着服务数量增加代码将难以维护。

为了解决以上几个问题，API网关便应运而生。当引入API网关后，在用户端和微服务之间就建立起了一道屏障。通过API网关为微服务提供了统一的访问入口，所有的用户端请求被API网关拦截，并在此基础上实现其他一些额外功能，比如：

• 1、针对所有请求进行统一鉴权、熔断、限流、日志等前置处理，让微服务专注自己的业务。
• 2、统一调用风格，通常 API 网关对外提供 RESTful 风格 URL 接口。用户传入请求后，由 API 网关负责转换为后端服务需要的 RESTful、RPC、WebService 等方式，这样便大幅度简化用户的接入难度。有效统一对外的规范。
• 3、更好的安全性，在通过 API 网关鉴权后，可以控制不同角色用户访问后端服务的权利，实现了服务更细粒度的权限控制。
• 4、API 网关是用户端访问 API 的唯一入口，从用户的角度来说只需关注 API 网关暴露哪些接口，至于后端服务的处理细节，用户是不需要知道的。从这方面讲，微服务架构通过引入 API 网关，将用户端与微服务的具体实现进行了解耦。

那市面上又有哪些API网关产品呢？

三、API网关产品

目前市面上的API网关产品，主流的有三种，分别是： OpenResty、Spring Cloud Zuul、Spring Cloud Gateway三款。

这里OpenResty因为与主流注册中心存在一定的兼容性问题，需要使用者自行实现其服务注册、发现的功能。导致 Spring Cloud 官方极力推崇自家封装的 Zuul 或者 Spring Cloud Gateway，渐渐 OpenResty 便淡出了我们的视野。

SpringCloud Zuul是Netflix 开源的微服务网关，它的主要职责是对用户请求进行路由转发与过滤。但因Netflix 官方宣布Zuul停止维护，导致这里也不推荐使用。

SpringCloud GateWay是Spring自己开发的新一代API网关产品，它基于 NIO 异步处理，摒弃了 Zuul 基于 Servlet 同步通信的设计，因此拥有更好的性能。同时，Spring Cloud Gateway 对配置进行了进一步精简，比 Zuul 更加简单实用。

四、SpringCloud GateWay配置技巧

1、SpringCloud GateWay使用入门

这里我们通过一个示例来介绍：

假设我们一个service-a微服务，它提供了三个接口，分别是：/list（查询列表）、/create(创建数据)、/delete（删除数据）。

还有个service-b微服务，它提供的也有三个接口：/login（登录接口）、/loginout（用户注销）、/getinfo（获取用户信息）。

那我们如何通过SpringCloud GateWay实现API路由功能来屏蔽后端细节呢？

（1）创建工程

利用 Spring Initializr 向导创建 Gateway 工程，确保 pom.xml 引入以下依赖：

<!-- Nacos客户端 -->
<dependency>
    <groupId>com.alibaba.cloud</groupId>
    <artifactId>spring-cloud-starter-alibaba-nacos-discovery</artifactId>
</dependency>
<!-- Spring Cloud Gateway Starter -->
<dependency>
    <groupId>org.springframework.cloud</groupId>
    <artifactId>spring-cloud-starter-gateway</artifactId>
</dependency>
<!-- 对外提供Gateway应用监控指标 -->
<dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-actuator</artifactId>
</dependency>

（2）在application.yml文件中添加以下配置：

spring:
  application:
    name: gateway #配置微服务id
  cloud:
    nacos:
      discovery:
        server-addr: 106.14.221.171:8848 #nacos通信地址
        username: nacos
        password: nacos
    gateway: #让gateway通过nacos实现自动路由转发
      discovery:
        locator:
          enabled: true #locator.enabled是自动根据URL规则实现路由转发
server:
  port: 80 #服务端口号
management: 
  endpoints:
    web:
      exposure:
        include: '*' #对外暴露actuator所有监控指标，便于监控系统收集跟踪

上面配置中最重要的一个就是：

spring.cloud.gateway.discovery.locator.enabled=true

这是一个自动项，允许 Gateway 自动实现后端微服务路由转发， Gateway 工程启动后，在浏览器地址栏按下面格式访问后端服务。

http://网关IP:端口/微服务id/URI

(3)工程启动，接口调用

比如，我们网关IP是：192.168.3.1，我们需要通过网关执行service-a服务的list方法，具体写法是：

http://192.168.3.1:80/service-a/list

2、路由转发流程

上面工程启动后，我们在Nacos中也可以看到微服务注册成功，同时也可以调用service-a微服务的某个接口，但转发的流程是什么样的呢？ 我们一起来看一下：

• 1、GateWay、service-a这些都是微服务的实例，在启动时自动向Nacos注册登记；
• 2、用户端向GateWay发起调用请求后，请求地址为：/service-a/list；
• 3、Gateway 网关实例收到请求，解析其中第二部分 service-a，即微服务 Id，第三部分 URI 为“/list”。之后向 Nacos 查询 service-a 可用实例列表；
• 4、Nacos 返回 3.1 与 3.2 两个可用微服务实例信息；
• 5、Spring Cloud Gateway 内置 Ribbon，根据默认轮询策略将请求转发至 3.2 实例，转发的完整 URL 将附加用户的 URI；
• 6、3.2 实例处理后返回 JSON 响应数据给 Gateway；
• 7、Gateway 返回给用户端，完成一次完整的请求路由转发过程。

到这里，我们基本就聊完了SpringCloud GateWay的使用和执行过程。但在真实项目中，存在着各种特殊的路由转发规则，而非自动路由能简单解决的。在SpringCloud GateWay中内置了强大的“谓词”系统，可以满足各种业务的转发规则，我们下篇文章再接着聊！

欢迎关注公众号：服务端技术精选。欢迎点赞、关注、转发。