Spring Cloud Gateway应用篇（十三）

1、概述

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

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

2、微服务网关的做用

因此，咱们能够在微服务以前增长一个前置节点，这个节点就是网关，网关就是一个网络链接到另外一个网络的“关口”。也就是网络。而在微服务架构中，它不只仅只是一个网络互连的一个关口，还有更多的做用，之前面分析的这个场景为例，增长网关以后全部请求的下发都由网关下发；对于商品详情展现的场景来讲，增长了 API 网关以后，在 API 网关层能够把后端的多个服务进行整合，而后提供一个惟一的业务接口，客户端只须要调用这个接口便可完成数据的获取及展现。在网关中会再去消费后端的多个微服务进行统一的整合，给客户端返回一个惟一的响应。去消费后端的多个微服务进行统一的整合，给客户端返回一个惟一的响应。

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

 2.一、网关的做用

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

3、服务网关的要求

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

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

常见的网关方案

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

网关选型

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

4、Spring Cloud Gateway的核心概念

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

它的总体工做原理以下。

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

5、应用实战

新建一个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.一、断言

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

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

 

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

 

 

 

 

 

 

 

 5.二、自定义断言

若是官网提供的断言不知足本身的要求，官网也支持自定义断言；自定义断言要继承AbstractRoutePredicateFactory这个抽象工厂，咱们自定义的断言类名后缀必须是RoutePredicateFactory；自定义也很简单也就是看别人怎么写的而后抄就完了

 

 

 

 

 

 而后把以前测试工具的Cookies删除，调用成功