我们要了解一个事物,从三个维度去了解就行了; 是什么 、 做什么 、 为什么 。
在SpringCloud微服务体系中,有个 很重要的组件就是网关 ,在1.x版本中都是采用的Zuul网关;但在2.x版本中,zuul的升级一直跳票, SpringCloud最后自己研发了一个网关替代Zuul, 那就是 SpringCloud Gateway 。
还有一点就是Gateway是 基于WebFlux 的。这里引出了WebFlux名词, 那什么是WebFlux?
我们知道 传统的Web框架 ,比如说:struts2,springmvc等 都是基于Servlet API与Servlet容器基础之上运行的 ,在Servlet3.1之后才有了异步非阻塞的支持。
而 WebFlux是一个典型非阻塞异步的框架 ,它的核心是基于Reactor的相关API实现的。相对于传统的web框架来说, 它可以运行在诸如Netty,Undertow及支持Servlet3.1的容器上 。
根据官方的说法, webflux主要在如下两方面体现出独有的优势 :
其实在servlet3.1提供了非阻塞的API,WebFlux提供了一种比其更完美的解决方案。使用非阻塞的方式可以利用较小的线程或硬件资源来处理并发进而提高其可伸缩性
老生常谈的编程方式了,Spring5必须让你使用java8,那么函数式编程就是java8重要的特点之一,而WebFlux支持函数式编程来定义路由端点处理请求。
网关可以理解为网络关卡,是整个微服务的统一入口(门卫)。
可以 和服务注册中心完美的整合 ,如:Eureka、Consol、Nacos
基于 Spring Framework 5,Project Reactor 和 Spring Boot 2.0
动态路由
Predicates 和 Filters 作用于特定路由
集成 Hystrix 断路器
集成 Spring Cloud DiscoveryClient
易于编写的 Predicates 和 Filters
限流
路径重写
上图中是核心的流程图,最主要的 就是Route、Predicates 和 Filters 作用于特定路由 。
1)Route:路由是网关的基本构件。它由ID、目标URI、谓词集合和过滤器集合定义。如果聚合谓词为真,则匹配路由。
2)Predicate:参照Java8的新特性Predicate。这允许开发人员匹配HTTP请求中的任何内容,比如头或参数。
**3)Filter:**可以在发送下游请求之前或之后修改请求和响应。
客户端向 Spring Cloud Gateway 发出请求 。然后在 Gateway Handler Mapping 中 找到与请求相匹配的路由 ,将其 发送到 Gateway Web Handler 。Handler 再通过指定的 过滤器链来将请求发送到我们实际的服务执行业务逻辑 ,然后返回。过滤器之间用虚线分开是因为过滤器可能会在发送 代理请求之前(“pre”)或之后(“post”)执行业务 逻辑。
Filter在**“pre”类型的过滤器可以做参数校验、权限校验、流量监控、日志输出、协议转换 等,在 “post”类型的过滤器中可以做响应内容、响应头的修改,日志的输出,流量监控**等有着非常重要的作用。
一方面因为Zuul已经进入了 维护阶段 ,而且Gateway是SpringCloud团队研发的,是亲儿子产品,值得信赖。而且很多功能Zuul都没有;用起来也非常的简单便捷。
Gateway是基于异步非阻塞模型上进行开发的,性能方面不需要担心。虽然Netflix 早就发布了最新的 Zuul 2.x,但 Spring Cloud 貌似没有整合计划。而且 Netflix相关组件都宣布进入维护期 ;不知前景如何?
多方面综合考虑Gateway是很理想的网关选择。