Spring Cloud Gateway应用篇（十三）

一、概述

在微服务架构中，每个服务都是一个可以独立开发和运行的组件，而一个完整的微服务架构由一系列独立运行的微服务组成。其中每个服务都只会完成特定领域的功能，比如订单服务提供与订单业务场景有关的功能、商品服务提供商品展示功能等。各个微服务之间通过轻量级通信机制 REST API 或者 RPC 完成通信。 微服务之后在某些层面会带来一定的影响，比如，一个用户查看一个商品的详情，对于客户端来说，可能需要调用商品服务、评论服务、库存服务、营销服务等多个服务来完成数据的渲染在这个场景中，客户端虽然能通过调用多个服务实现数据的获取，但是会存在一 些问题，比如：

• 客户端需要发起多次请求，增加了网络通信的成本及客户端处理的复杂性。
• 服务的鉴权会分布在每个微服务中处理，客户端对于每个服务的调用都需要重复鉴权。
• 在后端的微服务架构中，可能不同的服务采用的协议不同，比如有 HTTP、RPC 等。客户端如果需要调用多个服务，需要对不同协议进行适配

二、微服务网关的作用

所以，我们可以在微服务之前增加一个前置节点，这个节点就是网关，网关就是一个网络连接到另一个网络的“关口”。也就是网络。而在微服务架构中，它不仅仅只是一个网络互连的一个关口，还有更多的作用，以前面分析的这个场景为例，增加网关之后所有请求的下发都由网关下发；对于商品详情展示的场景来说，增加了 API 网关之后，在 API 网关层可以把后端的多个服务进行整合，然后提供一个唯一的业务接口，客户端只需要调用这个接口即可完成数据的获取及展示。在网关中会再去消费后端的多个微服务进行统一的整合，给客户端返回一个唯一的响应。去消费后端的多个微服务进行统一的整合，给客户端返回一个唯一的响应。

• 针对所有请求进行统一鉴权、限流、熔断、日志。
• 协议转化。针对后端多种不同的协议，在网关层统一处理后以 HTTP 协议对外提供服务。
• 用过 Dubbo 框架的应该知道，针对 Dubbo 服务还需要提供一个 Web 应用来进行协议转化。
• 统一错误码处理。
• 请求转发，并且可以基于网关实现内外网隔离

2.1、网关的作用

• 性能：API高可用，负载均衡，容错机制。
• 安全：权限身份认证、脱敏，流量清洗，后端签名（保证全链路可信调用）,黑名单（非法调用的限制）。
• 日志：日志记录（spainid,traceid）一旦涉及分布式，全链路跟踪必不可少。
• 缓存：数据缓存。
• 监控：记录请求响应数据，api耗时分析，性能监控。
• 限流：流量控制，错峰流控，可以定义多种限流规则。
• 灰度：线上灰度部署，可以减小风险。
• 路由：动态路由规则。

三、服务网关的要求

从上面的案例来看，网关成了所有流量的入口，那么对于这样一个角色来说，它需要在某些方面有很高的要求

• 稳定性，
• 安全性，防止恶意请求，以及保障数据传输的安全性
• 高性能、可用性，
  • 网关作为所有流量的入口，那么对于性能这块的要求就非常高了，因为一旦网关的性能出现瓶颈，就算后端的服务性能再高，意义也不大
  • 网关必须要支持集群部署，这个是分布式架构的基本要求。否则网关服务挂掉就会导致整个系统不可用
• 扩展性，可维护性，对于定制化需求方面，如何实现可扩展；

常见的网关方案

• OpenResty（Nginx+lua）
• Kong，是基于openresty之上的一个封装，提供了更简单的配置方式。 它还提供了付费的商业插件
• Tyk（开源、轻量级），Tyk 是一个开源的、轻量级的、快速可伸缩的 API 网关，支持配额和速度限制，支持认证和数据分析，支持多用户多组织，提供全 RESTful API。它是基于go语言开发的组件。
• Zuul，是spring cloud生态下提供的一个网关服务，性能相对来说不是很高
• Spring Cloud Gateway，是Spring团队开发的高性能网关

网关选型

• 部署和维护成本
• 开源还是闭源
• 是否私有化部署
• 功能是否满足当前需求
• 社区资料的完善以及版本迭代和功能维护

四、Spring Cloud Gateway的核心概念

• Route 路由，它是网关的基础元素，包含ID、目标URI、断言、过滤器组成，当前请求到达网关时，会通过Gateway Handler Mapping，基于断言进行路由匹配，当断言为true时，匹配到路由进行转发
• Predicate，断言，学过java8的应该知道这个函数，它可以允许开发人员去匹配HTTP请求中的元素，一旦匹配为true，则表示匹配到合适的路由进行转发
• Filter，过滤器，可以在请求发出的前后进行一些业务上的处理，比如授权、埋点、限流等。

它的整体工作原理如下。

其中，predicate就是我们的匹配条件；而filter，就可以理解为一个无所不能的拦截器。有了这两个元素，再加上目标uri，就可以实现一个具体的路由了。客户端向 Spring Cloud Gateway 发出请求，如果请求与网关程序定义的路由匹配，则该请求就会被发送到网关 Web 处理程序，此时处理程序运行特定的请求过滤器链。过滤器之间用虚线分开的原因是过滤器可能会在发送代理请求的前后执行逻辑。所有 pre 过滤器逻辑先执行，然后执行代理请求；代理请求完成后，执行 post 过滤器逻辑

五、应用实战

新建一个spring-cloud-gateway服务

在spring-cloud-gateway服务中导入以下包

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

然后在配置文件中配置如下

server:
  port: 9100
spring:
  application:
    name: spring-cloud-gateway
  cloud:
    gateway:
      routes:
         - predicates:
            - Path=/service/**
           filters:   #过滤
            - StripPrefix=1
           uri: http://localhost:8080/

eureka:
  instance:
    hostname: localhost
  client:
    serviceUrl:
      defaultZone: http://localhost:8761/eureka/,http://localhost:8762/eureka/  #指向服务注册中心的地址

启动项目通过网关访问业务服务，发现可以直接通过网关的端口发起访问

5.1、断言

https://docs.spring.io/spring-cloud-gateway/docs/2.2.5.RELEASE/reference/html/#the-after-route-predicate-factory

这是官方提供的11种断言方法，有兴趣可以按官网的去配置玩下，cloud整个体系配置相对来说很简单的

下面就写一个关于常用的Cookie配置下；