SpringBoot中的Http应用---WebFlux

咱们今天开始进入Spring WebFlux.WebFlux是Spring5.0开始引入的.有别于SpringMVC的Servlet实现,它是彻底支持异步和非阻塞的.在正式使用Spring WebFlux以前,咱们首先得了解他和Servlet的区别,以及他们各自的优点,这样咱们才可以给合适的场景选择合适的开发工具.

首先咱们要问几个问题,为何要有异步?在异步以前,软件行业作过哪些努力,他们的优点是什么?基于这几个问题,咱们今天分享如下三个知识点:

1. 从Http1.X 到Http2.0

2. 从Servlet2.x到Servlet3.x

3. WebFlux的出场

   
   

1. 从Http1.x到Http2.0

异步和同步是没法分开的.他们对性能的理解和处理也是各有千秋.传统的web项目由于是基于阻塞I/O模型而创建的,因此他们只能经过对整个链路的优化来提高性能,而这里的性能就包括了伸缩性和响应速度.这里面比较重要的一个环节就是网络传输.相对而言,这也是距离咱们的用户最近的一个环节,所以他们对并发的处理以及对响应速度的处理就比其余的会更直接地影响咱们的用户.

1.1 Http/1.x

在http1.x中,咱们都知道,http会先进行三次握手,握手成功以后,开始传递数据,服务器响应完毕,就进行四次挥手,最后关闭连接.刚开始应用这个概念的时候,是很是受欢迎的,由于在那时候传递的仍是静态页面或者动态数据比较少的资源,所以不管是客户端仍是服务器端,他都节省了更多的资源.但随着互联网的飞速发展,这种方式就遇到了问题.若是每次传递数据都须要三次握手四次挥手的话,那么随着数据访问量的增长,那么三次握手四次挥手带来的资源消耗就会成为影响系统的瓶颈.这就好像一根针重量能够忽略,但当咱们汇集上亿根针的时候,那么他的重量和所占用的空间,就成了必需要考虑的问题了.

那能不能创建好一次连接以后,我多传递几回数据,而后在关闭呢?固然能够,这就是长连接,也就是你们常说的"Keep-Alive".而HTTP1.1则是默认就开启了Keep-Alive.Keep-Alive虽然暂时性的解决了创建连接所带来的开销,也必定程度的提升了响应速度,但后来又凸显了另外两个问题:

1. 首先,由于http是串行文件传输.因此当客户端请求a文件时,b文件只能等待.等待a连接到服务器,服务器处理文件,服务器返回文件这三个步骤完成后,b才能接着处理.咱们假设,连接服务器,服务器处理,服务器返回各须要1秒,那么b处理完的时候就须要6秒,以此类推.(固然,这里有个前提,服务器和浏览器都是单通道的.)这就是咱们说的阻塞.
   

2. 其次,连接数的问题.咱们都知道服务器的连接数是有限的.而且浏览器也对连接数有限制.这样能接入进来的服务就是有个数限制的,当达到这个限制的时候,其余的就须要等待连接被断开,而后新的请求才可以进入.这个比较容易理解.

之因此http1.x会使用串行文件传输,是由于http传输的不管是request仍是response都是基于文本的,因此接收端没法知道数据的顺序,所以必须按着顺序传输.这也就限制了只要请求就必须新创建一个连接,这也就致使了第二个问题的出现.

1.2 Http/2

为了从根本上行解决http1.x所遗留的这两个问题,http2引入了二进制数据帧和流的概念.其中帧的做用就是对数据进行顺序标识,这样的话,接收端就能够根据顺序标识来进行数据合并了.同时,由于数据有了顺序,服务器和客户端就能够并行的传输数据,而这就是流所做的事情.

这样,由于服务器和客户端能够借助流进行并行的传递数据,那么同一台客户端就可使用一个连接来进行传输,此时服务器能处理的并发数就有了质的飞跃.

http/2的这个新特性,就是多路复用.咱们能够看到,多路复用的本质就是并行传输.那web对请求的处理是否可使用这个思路呢?

2.Servlet

如今咱们来讨论Servlet与Netty.这两个一个主要是以同步阻塞的方式服务的,另外一个是异步非阻塞的.这也就形成了他们适用的场景是不一样的.

2.1 Servlet

作JavaWeb研发的几乎没有不知道Servlet的.在Servlet 3.0以前，Servlet采用Thread-Per-Request的方式处理请求，即每一次Http请求都由某一个线程从头至尾负责处理。若是一个请求须要进行IO操做，好比访问数据库、调用第三方服务接口等，那么其所对应的线程将同步地等待IO操做完成， 而IO操做是很是慢的，因此此时的线程并不能及时地释放回线程池以供后续使用，在并发量愈来愈大的状况下，这将带来严重的性能问题。为了解决这一的问题,Servlet3.0引入了异步处理.

在Servlet 3.0中，咱们能够从HttpServletRequest对象中得到一个AsyncContext对象，该对象构成了异步处理的上下文，Request和Response对象均可从中获取。AsyncContext能够从当前线程传给另外的线程，并在新的线程中完成对请求的处理并返回结果给客户端，初始线程即可以还回给容器线程池以处理更多的请求。如此，经过将请求从一个线程传给另外一个线程处理的过程便构成了Servlet 3.0中的异步处理。

这里举个例子,对于一个须要完成长时处理的Servlet来讲，其实现一般为:

package top.lianmengtu.testjson.servlet;

import javax.servlet.ServletException;
import javax.servlet.annotation.WebServlet;
import javax.servlet.http.HttpServlet;
import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpServletResponse;
import java.io.IOException;

//@WebServlet("/syncHello"),由于使用的SpringBoot模拟,因此注释掉该注解
public class MyServlet extends HttpServlet {
    @Override
    protected void doGet(HttpServletRequest req, HttpServletResponse resp) throws ServletException,       IOException {
        super.doGet(req, resp);
        new LongRunningProcess().run();
        System.out.println("HelloWorld");
    }
}

LongRunningProcess实现以下:

package top.lianmengtu.testjson.servlet;

import java.util.concurrent.ThreadLocalRandom;

public class LongRunningProcess {
    public void run(){
        try {
            int millis = ThreadLocalRandom.current().nextInt(2000);
            String currentThread = Thread.currentThread().getName();
            System.out.println(currentThread + " sleep for " + millis + " milliseconds.");
            Thread.sleep(millis);

        } catch (InterruptedException e) {
            e.printStackTrace();
        }
    }
}

咱们如今将MyServlet注入到Spring容器中:

@Bean
public ServletRegistrationBean servletRegistrationBean(){
    return new ServletRegistrationBean(new MyServlet(),"/syncHello");
}

此时的SyncHelloServlet将顺序地先执行LongRunningProcess的run()方法，而后在控制台打印HelloWorld.而3.0则提供了对异步的支持,所以在Servlet3.0中咱们能够这么写:

@Override
protected void doGet(HttpServletRequest req, HttpServletResponse resp) throws ServletException, IOException {
    AsyncContext asyncContext=req.startAsync();
    asyncContext.start(()->{
        new LongRunningProcess().run();
        try {
            asyncContext.getResponse().getWriter().print("HelloWorld");
        } catch (IOException e) {
            e.printStackTrace();
        }
        asyncContext.complete();
    });

}

此时，咱们先经过request.startAsync()获取到该请求对应的AsyncContext，而后调用AsyncContext的start()方法进行异步处理，处理完毕后须要调用complete()方法告知Servlet容器。start()方法会向Servlet容器另外申请一个新的线程（能够是从Servlet容器中已有的主线程池获取，也能够另外维护一个线程池，不一样容器实现可能不同），而后在这个新的线程中继续处理请求，而原先的线程将被回收到主线程池中。事实上，这种方式对性能的改进不大，由于若是新的线程和初始线程共享同一个线程池的话，至关于闲置下了一个线程，但同时又占用了另外一个线程。

Servlet 3.0对请求的处理虽然是异步的，可是对InputStream和OutputStream的IO操做却依然是阻塞的，对于数据量大的请求体或者返回体，阻塞IO也将致使没必要要的等待。所以在Servlet 3.1中引入了非阻塞IO，经过在HttpServletRequest和HttpServletResponse中分别添加ReadListener和WriterListener方式，只有在IO数据知足必定条件时（好比数据准备好时），才进行后续的操做。

虽然Servlet3.1提供了异步的方式,而且作的也比Servlet3.0更完全,可是若是咱们使用了Servlet3.1提供的异步接口,像刚刚的代码演示的那样,那么咱们在以后的处理中就没有办法再使用他原来的接口了.这就让咱们处于了一种非此即彼的情况中.若是是这样,Servlet系列的技术,如SpringMVC也就是这样了.那怎么办呢?

3. WebFlux的出场

如今咱们会从如下几个层面来探讨WebFlux

1. 为何要有WebFlux?

2. Reactive定义与ReactiveAPI
   

3. WebFlux中的性能问题

4. WebFlux的并发模型
   

5. WebFlux的适用性

3.1为何要有WebFlux

首先,为何要有webFlux?

在前面两部分,咱们一直在探讨并发问题.为了解决并发,咱们须要使用非阻塞的web技术栈.由于非阻塞的web栈使用的线程数更少,对硬件资源的要求更低.虽然Servlet3.1为非阻塞I/O提供了一些支持,但刚刚咱们提到了,若是咱们使用Servlet3.1里的非阻塞API,会致使咱们没法再使用它原来的API.而且,自从非阻塞I/O以及异步概念出现以后,就诞生了一批专为异步和非阻塞I/O设计的服务器,好比Netty,这就催生了新的能服务于各类非阻塞I/O服务器的统一的API.

WebFlux诞生的另外一个重要缘由是函数式程序设计.随着脚本型语言(Nodejs,Angular等)的扩张,函数式程序设计以及后继式API也相继火起来.以致于Java也在Java8中引入了Lambda来对函数式程序设计进行支持,又引入了StreamAPI来对后继式程序进行支持.由此,对具有函数式编程和后继式程序设计的Web框架的需求也愈来愈大了。

3.2Reactive的定义与API

Reactive的定义

咱们接触了"非阻塞"和"函数式",那reactive是什么意思呢?

 "reactive"这个术语指的是:围绕着对改变作出响应的程序设计模型---网络组件对IO事件作出响应,UIController对鼠标事件作出响应等等.在那种状况下,非阻塞取代了阻塞是响应式的,咱们正处于响应模式中,当操做完成和数据变得可用的时候发起通知.

还有另外一个重要的机制那就是咱们在spring team里整合"reactive"以及非阻塞式背压机制.在同步里,命令式的代码,阻塞式地调用服务为普通的表单充当背压机制强迫调用者等待.在非阻塞式编程中,控制事件的频率就变得很重要防止快速的生产者不会压垮他的目的地.

Reactive Streams 是一个定义了使用背压机制的异步组件之间交互设计的小型说明书(在Java9中也采纳了).例如,一个数据仓库(能够看作Publisher)能够生产数据,而后HTTP Server(看作订阅者)能够写入到响应里.Reactive Streams的主要目的是让订阅者能够控制生产者产生数据的速度有多快或有多慢.

Reactive API

Reactive Streams 在互操做性上扮演了一个很重要的角色.类库和基础设施组件虽然有趣,但对于应用程序API来讲却用处甚少,由于他们太底层了.应用程序须要一个更高级别更丰富的函数式API来编写异步逻辑---和Java8里的StreamAPI很相似,不过不只仅是为集合作准备的.

Reactor 是为SpringWebFlux选择的一个reactive类库.它提供了Mono和Flux类型的API来处理0..1(Mono)和0..N(Flux)数据序列化经过一组丰富的操做集和ReactiveX vocabulary of operators对齐.Reactor 是一个Reactive Streams类库,因此他全部的操做都支持非阻塞背压机制.Reactor强烈地聚焦于Server端的Java.他在发展上和Spring有着紧密的协做.

WebFlux要求Reactor做为一个核心依赖,但凭借Reactive Streams也能够和其余的reactive libraries一块儿使用.通常来讲,一个WebFlux API 接收一个Publisher做为输入,转换给一个内置的Reactor类型来使用,最后返回一个Flux或一个Mono做为输出.因此,你能够批准任何的Publisher做为输入,你能够应用操做在输出上,但你由于你使用了其余的reactive library因此你须要进行转换.只要可行(例如,注解controllers),WebFlux能够在使用RXJava和另外一个reactive library之间透明的改变.看Reactive Libraries获取更多地细节.

3.3 性能

性能这个词有不少特征和含义.Reactive 和非阻塞一般不会使应用程序运行地更快.在某些场景下,他们也能够.(例如,在并行条件下使用WebClient来执行远程调用的话).总体来讲,非阻塞方式可能须要作更多的工做而且他也会稍微增长请求处理的时间.

对reactive和非阻塞好处的预期关键在于使用小,固定的线程数和更少的内存来扩展的能力.这使应用程序在加载的时候更加有弹性,由于他们以一种更能够预测的方式扩展.然而为了看到这些好处,你须要一些延迟(包括比较慢的不可预知的网络I/O).那是响应式堆栈开始显示他力量的地方,而且这些不一样是很是吸引人的.

3.4并发模型

Spring MVC和Spring WebFlux都支持注解Controllers,但他们在并发模型和对阻塞和线程的默认呈现(assumptions)上是很是不一样的.在Spring MVC(和通用的servlet应用)中,都假设应用程序是阻塞当前线程的(例如,远程调用),而且出于这个缘由,servlet容器处理请求的期间使用一个巨大的线程池来吸取潜在的阻塞.

在Spring WebFlux(和非阻塞服务器)中,假设应用程序是非阻塞的,因此,非阻塞服务器使用小的,固定代销的线程池(event loop workders)来处理请求.

 "弹性伸缩"和"小数量的线程"或许听起来矛盾,可是对于不会阻塞当前线程(用依赖回调来取代)意味着你不须要额外的线程,由于非阻塞调用给处理了.

调用一个阻塞API

      要是你须要使用阻塞库怎么办?Reactor和RxJava都提供了publishOn操做用一个不一样的线程来继续处理.那意味着有一个简单的脱离舱口(一个能够离开非阻塞的出口).然而,请牢记,阻塞API对于并发模型来讲不太合适.

易变的状态

        在Reactor和RxJava里,你经过操做符生命逻辑,在运行时在不一样的阶段里,都会造成一个进行数据序列化处理的管道.这样作的一个主要好处就是把应用程序从不一样的状态保护中解放了出来,由于管道中的应用代码是毫不会被同时调用的.

线程模型

在运行了一个使用Spring WebFlux的服务器上,你指望看到什么线程呢?

• 在一个"vanilla"Spring WebFlux服务器上(例如,没有数据访问也没有其余可选的依赖),你可以看到一个服务器线程和几个其余的用来处理请求的线程(通常来讲,线程的数目和CPU的核数是同样的).然而,Servlet容器在启动的时候就使用了更多的线程(例如,tomcat是10个),来支持servlet(阻塞)I/O和servlet3.1(非阻塞)I/O的用法.

• 响应式的WebClient操做是用Event Loop方式.因此你能够看到少许的固定数量的线程和他关联.(例如,使用了Reactor Netty链接的reactor-http-nio).然而,若是Reactor Netty在客户端和服务端都被使用了,这二者之间的event loop资源默认是被共享的.

• Reactor和RxJava提供了抽象化的线程池,调度器目的是结合publishOn操做符在不一样的线程池之间切换操做.调度器有一个名字,建议这个名字是一个具体的并发策略--例如,"parallel"(由于CPU-bound使用有限的线程数来工做)或者"elastic"(由于I/O-bound使用大量的线程来工做).若是你看到这类的线程,这就意味着一些代码正在使用一个具体的使用了Scheduler策略的线程池.

• 数据访问库和其余第三方库依赖也建立和使用了他们本身的线程.

下次咱们来分享Spring WebFlux的使用.

本文相关视频链接