本文共 2417 字,大约阅读时间需要 8 分钟。
Cloud全家桶中有个很重要的组件就是网关,在1.x版本中都是采用Zuul网关。但是在2.x版本中,zuul的升级一直跳票,SpringCloud最后自己研发了一个网关代替Zuul,就是SpringCloud Gateway,gateway就是原zuul1.x版的替代。
Gateway是在Spring生态之上构建的API网关服务,基于Spring5,SpringBoot 2和Project Reactor等技术。Gateway旨在提供一种简单而有效的方式来对API进行路由,以及提供一些强大的过滤器功能,例如:熔断、限流、重试等。
SpringCloud Gateway作为SpringCloud生态系统中的网关,目标是替代Zuul,在SpringCloud2.0以上版本中,没有对新版本的Zuul2.0以上最高性能版本进行集成,任然还是使用Zuul1.x非Reactor模式的老版本。而为了提升网关的性能,SpringCloud Gateway是基于WebFlux框架实现的,而WebFlux框架底层则使用了高性能的Reactor模式通信框架Netty。
SpringCloud Gateway的目标提供同一的路由方式且基于Filter链的方式提供了网关基本的功能,例如:安全、监控/指标和限流。
源码架构:
SpringCloud中所集成的Zuul版本,采用的是Tomcat容器,使用的是传统的Servlet IO处理模型。
servlet由servlet container进行生命周期管理。
上述模式的缺点:
servlet是一个简单的网络IO模型,当请求进入servlet container时,servlet container就会为其绑定一个线程,在并发不高的场景下这种模型是使用的。但是一旦高并发,线程数量就会上涨,而线程资源代价是昂贵的(上下文切换,内存消耗大)严重影响请求的处理时间。在一些简单业务场景下,不希望为每个request分配一个线程,只需要1个或几个线程就能应对极大并发的请求,这种业务场景下servlet模型没有优势。
所以Zuul1.x是基于Servlet之上的一个阻塞式处理模型,即Spring实现了处理所有request请求的servlet(DispatcherServlet)并由该servlet阻塞式处理。所以SpringCloud Zuul无法摆脱servlet模型的弊端。
传统的Web框架,比如说:struts2,springmvc等都是基于Servlet API与Servlet容器之上运行的。
但是在Servlet3.1之后有了异步非阻塞的支持。而WebFlux是一个典型的非阻塞异步框架,它的核心是基于Reactor的相关API实现的。相对于传统的web框架来说,它可以运行在诸如Netty,Undertow及支持Servlet3.1的容器上。非阻塞+函数式编程(Spring5必须使用java8)。Spring WebFlux是Spring 5.0引入的新的响应式框架,区别于SpringMVC,它不需要依赖Servlet API,它是完全异步非阻塞的,并且基于Reactor来实现响应式流规范。
转载地址:http://rspqb.baihongyu.com/