引用於
https://www.cnblogs.com/niechen/p/9303451.html
下邊的評論很精彩
SpringWebflux是SpringFramework5.0添加的新功能，WebFlux本身追隨當下最火的Reactive Programming而誕生的框架，那么本篇就來簡述一下這個框架到底是做什么的
一、關於WebFlux
我們知道傳統的Web框架，比如說：struts2，springmvc等都是基於Servlet API與Servlet容器基礎之上運行的，在Servlet3.1之后才有了異步非阻塞的支持。而WebFlux是一個典型非阻塞異步的框架，它的核心是基於Reactor的相關API實現的。相對於傳統的web框架來說，它可以運行在諸如Netty，Undertow及支持Servlet3.1的容器上，因此它的運行環境的可選擇行要比傳統web框架多的多。
根據官方的說法，webflux主要在如下兩方面體現出獨有的優勢：
1）非阻塞式
其實在servlet3.1提供了非阻塞的API，WebFlux提供了一種比其更完美的解決方案。使用非阻塞的方式可以利用較小的線程或硬件資源來處理並發進而提高其可伸縮性
2) 函數式編程端點
老生常談的編程方式了，Spring5必須讓你使用java8，那么函數式編程就是java8重要的特點之一，而WebFlux支持函數式編程來定義路由端點處理請求。
二、SpringMVC與SpringWebFlux
我們先來看官網的一張圖：
它們都可以用注解式編程模型，都可以運行在tomcat，jetty，undertow等servlet容器當中。但是SpringMVC采用命令式編程方式，代碼一句一句的執行，這樣更有利於理解與調試，而WebFlux則是基於異步響應式編程，對於初次接觸的碼農們來說會不習慣。對於這兩種框架官方給出的建議是：
1）如果原先使用用SpringMVC好好的話，則沒必要遷移。因為命令式編程是編寫、理解和調試代碼的最簡單方法。因為老項目的類庫與代碼都是基於阻塞式的。
2）如果你的團隊打算使用非阻塞式web框架，WebFlux確實是一個可考慮的技術路線，而且它支持類似於SpringMvc的Annotation的方式實現編程模式，也可以在微服務架構中讓WebMvc與WebFlux共用Controller，切換使用的成本相當小
3）在SpringMVC項目里如果需要調用遠程服務的話，你不妨考慮一下使用WebClient，而且方法的返回值可以考慮使用Reactive Type類型的，當每個調用的延遲時間越長，或者調用之間的相互依賴程度越高，其好處就越大
我個人意見是：官網明確指出，SpringWebFlux並不是讓你的程序運行的更快(相對於SpringMVC來說)，而是在有限的資源下提高系統的伸縮性，因此當你對響應式編程非常熟練的情況下並將其應用於新的系統中，還是值得考慮的，否則還是老老實實的使用WebMVC吧
三、Reactive Spring Web
在這里定義了最基本的服務端接口：HttpHandler和WebHandler
HttpHandler
HttpHandler定義了最基本的處理Http請求行為，這個接口主要作用是處理Http請求並將結果做出響應，下面這個表格是說明了Server API的使用方式及何種方式進行響應式流支持的：
WebHandler
WebHandler定義了Web請求必要一些處理行為，大家不妨想想看：WebFlux已經脫離了Servlet API，那么使用WebFlux時遇到會話機制怎么辦，想要對請求過濾處理怎么辦或者想要處理靜態資源怎么辦等等，那么WebHandler就是做這個事情的。其實在HttpHandler的基本實現類通過適配器模式及裝飾模式也間接的實現了WebHandler接口：
WebHandler常見的實現類，我在這里列舉一下：
WebHandlerDecorator：WebHandler的裝飾器，利用裝飾模式實現相關功能的擴展
HttpWebHandlerAdapter: 進行Http請求處理，同時也是HttpHandler的實現類
FilteringWebHandler：通過WebFilter進行過濾處理的類，類似於Servlet中的Filter
ExceptionHandlingWebHandler: 針對於異常的處理類
ResourceWebHandler：用於靜態資源請求的處理類
DispatcherHandler：請求的總控制器，類似於WebMVC中的DispatcherServlet
下邊的評論
1 有個困惑：flux 真的能讓業務請求響應更快嗎？並不覺得。
傳統mvc：主線程接收到request --> 【准備數據（時間長）】--> 給用戶返回數據。
整個過程是單線程阻塞，所以用戶感覺等待時間長。
flux是異步模式： 主線程在接收到request --> 立刻返回
（所以性能測試出來的響應時間是很短，是個不變的常數，不隨用戶數量增加變化）
但是，真實數據還沒有准備好，它會開啟一個新worker線程去做實際的准備數據工作（這才是真正的業務操作），等worker線程完成工作，用戶才收到真實數據。
所以，從整體上來講，flux更快嗎？ 感覺只是抖個機靈而已。實際速度由於更多的線程開銷應該更慢了才對。
這個問題很好，webflux在spring官網里明確告訴我們並不是提高性能：
Reactive and non-blocking generally do not make applications run faster.
它只是說明，webflux可以在有限的資源下提高系統的吞吐量和伸縮性：
The key expected benefit of reactive and non-blocking is the ability to scale with a small, fixed number of threads and less memory.
2 一台服務器，一秒鍾請求3000次服務器崩潰了。但是增加吞吐后，一秒接受請求5000次。
3 異步不僅僅是抖機靈。同步會阻塞，然后依靠系統多線程來切換。而異步的話，遞交，然后忙別的事情去了，不占用這部分通信的資源，等待處理完成再返回。會提升性能滴
4 感覺webflux的作用就跟Nginx差不多。
原本spring mvc是同步阻塞的，相當於一個商場，客人進去購物必須有導購員跟着。商場外面有5個導購，來一個客人，就有一個導購員跟着他，直到他購物完畢出去，一趟要花個幾十分鍾。如果一下子來了10個人，那導購員就不夠用了，客人就只能在門外等，或者被拒絕進入。
但是現在webflux異步非阻塞，就相當於門口不要導購員了，只留1個禮儀小姐，商場內部安排4個導購員。禮儀小姐只需要迎接客人進入商場，客人進入商場后就交給導購員帶客人去購物，購物完后導購員將客人交給禮儀小姐帶客人離開。如果一下子來了10個人，就讓禮儀小姐一一帶入商場內休息【排隊】，導購員依次帶他們去購物。
同步阻塞、異步非阻塞其實指的是負責接收http連接的線程。跟工作線程無關。總體業務花費的時間始終保持不變。只是可以接收的http網絡鏈接多了。