学习微服务系列（四）：springboot服务gateway网关

什么是服务网关

前文我们已经了解了构建微服务的基础springboot，同时也能使用springboot构建服务。接下来我们就基于springboot聊一下springcloud。这个springcloud并不是一个特定的技术，它指的是微服务中一个生态体系。比如包括网关，注册中心，配置中心等。今天我们就先了解一下微服务网关，微服务网关有很多种我们这次采用现在主流的spring cloud gateway来讲解说明。
在微服务体系中，每个服务都是一个独立的模块都是一个独立运行的组件，一个完整的微服务体系是由若干个独立的服务组成，每个服务完成自己业务模块功能。比如用户服务提供用户信息相关的服务和功能，支付模块提供支付相关的功能。各个服务之间通过REST API或者RPC（以后讲）进行通信，并且一般我们微服务要做到无状态的通信。
我们实现微服务之后在一些方面也会带来不方便的地方，如果网页端或者app端需要请求修改送货地址，还有购物之后要付款在这个场景下：

如上图会出现一些问题：

• 客户端要发起多次请求，请求不同域名对应的服务，增加了通信成本以及对客户端代码的维护增加了复杂性。
• 服务验证会在每个服务里面单独做，如果每个服务验证鉴权逻辑不同就会导致客户端反复验证。
• 另外如果各个服务采用的协议不同那么对于客户端来讲那就是灾难性的。
  基于上面所以我们就需要一个中间层，让客户端去请求中间层，至于需要请求那个服务由中间件去请求，最后将结果汇总返回给客户端，这个中间层就是网关。
  

为什么要使用网关

使用网关有几个作用：

统一鉴权

一般我们在网关上进行鉴权有两种：1，是对于请求的客户端身份的认证。2，访问权限控制就是当确认用户身份之后判断是否有某个资源的访问权限。
曾经我们在单体应用中，客户端请求验证身份和对于资源权限的约束比较简单，通过请求的session就可以获取对应的用户以及权限信息，但是在微服务架构下，所有的服务都被拆成单个微服务而且还是集群部署这种情况就会变得复杂，因为如果还是使用session的话在分布式情况每次请求不一定会落在同一台机器上，这样就会导致session无效。就需要我们进行额外的工作保证集群中的session是一致的。所以我们在网关层进行统一的处理认证：

日志记录

当客户端请求进来之后我们需要记录当前请求的时间依赖来源地址，ip等信息，这样我们就可以统一的在网关层面上进行拦截获取，之后输出到日志文件中通过ELK组件进行输出，记录内容可以多维度多信息统一记录而不需要到具体每个服务中进行分别记录。

请求分发和过滤

对于网关来讲这个请求匹配分发是最重要的功能，我们常见的nginx其实他这个组件就有请求转发和过滤的功能，对于网关来讲可以对请求进行前置和后置的过滤。

• 请求分发：接收客户端的请求，将请求对应到后面的各个微服务上并请求微服务，因为微服务粒度比较细，所以这个网关就可以对各个微服务进行功能性的整合最终给回客户端。
• 过滤：网关会拦截所有请求，相当于spring中AOP一个横向的切面，在这个切面上进行鉴权，限流，认证等操作。

灰度发布

一般公司的互联网产品都是迭代非常快的，基本都是小步快跑。基本是一个周发布一个版本迭代。在这种情况下就会出现风险，比如兼容性，功能完整度，时间比较短会存在bug最终产生事故等问题。这样一般我们发布的时候会将新的功能发布到指定的机器上分过去一小部分流量来观察具体情况。所以网关作为请求的入口就正好可以完成这个功能。

常用网关解决方案

一般我们常用的网关有几种比如：OpenResty、Zuul、Gateway、Kong、Tyk等。我们主要是用spring体系的框架，所以我们本文针对Gateway进行讲解，其它几种网关实现不做重点说明，OpenResty是有nginx+lua集成的web服务器，集成了许多三方库和模块。Zuul其实springcloud前期也是在集成使用，到那时由于他的线程模型策略可能导致的性能问题最终spring选择了自己研发的spring cloud gateway。

环境准备

本文我们使用一个简单的案例来演示一下spring cloud gateway的使用方法，首先我们需要住呢比2个spring boot的应用，具体创建方式请参考我们本专题第二篇文章。

• spring-cloud-gateway-service1 这个是一个微服务
• Spring-cloud-gateway-wangguan 网关微服务
  我们根据以前专题创建了2个服务第一个服务我们添加一个controller

@RequestMapping(value = {
   
   "/getUser"}, method = RequestMethod.GET)
    public String getUser() {
   
   
        Map<String ,String> user = new HashMap<>();
        user.put("name", "张三");
        user.put("age", "45");

        String s = JSONObject.toJSONString(user);
        return s;
    }

第二个网关服务我们增加pom依赖

        <dependency>
            <groupId>org.springframework.cloud</groupId>
            <artifactId>spring-cloud-starter-gateway</artifactId>
            <version>2.0.4.RELEASE</version>
        </dependency>

在application.yml中添加gateway路由

spring:
  cloud:
    gateway:
      routes:
      - predicates:
            - Path =/gateway/**  #匹配规则
        uri: http://localhost:8099/getUser    #服务1的访问地址
        filters:
            - StripRrefix: 1 #去掉前缀
 server：
    port: 8077

针对上面配置含义说明：

• uri：目标服务地址，可配置uri和lb：//应用服务名称
• predicates：匹配条件，根据规则匹配是否请求该路由
• filters: 过滤规则，这个过滤包含前置过滤和后置过滤，
• StripPrefix=1，表示去掉前缀，即在转发目标url的时候去掉’gateway’
  这个时候我们启动服务之后发现服务启动日志：Netty started on port(s): 8077.说明我们服务成功了，并且网关依赖的是nettyserver启动几个服务监听。
  我们访问：

curl http://localhost:8077/gateway/getUser

在配置正确的情况下将会返回服务返回的结果。

spring cloud gateway原理

上图是gateway官方给出的原理图，可能不太好理解，我们自己画个图辅助理解一下：

如上图有几个概念先说明一下：

• 路由（Route）：是网关的组件之一，由id ，uri ，predicate ，filter组成。
• 断言（Predicate）：匹配http请求中的内容。如果返回结果是true则就按当前的router进行转发。
• 过滤器（Filter）：为请求提供前置和后置的过滤。
  当客户端发送请求到网关时，网关会根据一系列的Predicate的匹配结果来决定访问哪个route路由，然后根据过滤器进行请求处理，过滤器可以在请求发送到后端服务之前和之后执行。

路由规则

spring cloud gateway中提供了路由匹配机制，比如我们前文配置的Path=/gateway/** . 意思就是通过Path的属性来匹配URL前缀是/gateway/的请求。其实spring cloud gateway给我们提供了很多规则供我们使用。
每一个Predicate的使用，你可以理解为：当满足这种条件后才会被转发，如果是多个，那就是都满足的情况下被转发。这些Predict的源码在org.springframework.cloud.gateway.handler.predicate包中我们简单看一下：

动态路由

gateway配置路由主要有两种方式，1.用yml配置文件，2.写在代码里。而无论是 yml，还是代码配置，启动网关后将无法修改路由配