【熵增教育】Anders-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的使用.

本文相關視頻