一、什么是 Spring WebFlux
好多人以為Spring WebFlux就是Spring MVC的升級版，其實不然，那到底什么是Spring WebFlux呢，首先就要搞清楚Spring WebFlux與Spring MVC的不同點與相同點。
下圖截自 Spring Boot 官方網站：
上圖是Spring官方給出的Spring MVC和Spring WebFlux的對比圖，先看最上面的描述信息，右側是Spring MVC的描述：
Spring MVC is built on the Servlet API and uses a synchronous blocking I/O architecture whth a one-request-per-thread model.（翻譯：Spring MVC構建在Servlet API之上，使用同步阻塞I/O架構，每個線程一個請求模型。）
左邊是Spring WebFlux的描述：
Spring WebFlux is a non-blocking web framework built from the ground up to take advantage of multi-core, next-generation processors and handle massive numbers of concurrent connections.（翻譯： Spring WebFlux是一個從頭開始構建的非阻塞web框架，它利用多核、新一代處理器並處理大量並發連接。）
二、異同點
說完Spring WebFlux與Spring MVC的描述后，再來對比一下兩者的相同點和區別具體看下圖：
相同點：
1、都可以使用 Spring MVC 注解，如 @Controller, 方便我們在兩個 Web 框架中自由轉換；
2、均可以使用 Tomcat, Jetty, Undertow Servlet 容器（Servlet 3.1+）；
......
三、WebFlux特性
1、Spring MVC 因為是使用的同步阻塞式，更方便開發人員編寫功能代碼，Debug測試等，一般來說，如果 Spring MVC 能夠滿足的場景，就盡量不要用 WebFlux;
2、WebFlux 默認是通過 Netty 啟動，並且自動設置了默認端口為 8080。另外還提供了對 Jetty、Undertow 等容器的支持。開發者自行在添加對應的容器 Starter 組件依賴，即可配置並使用對應內嵌容器實例。
但是要注意，必須是 Servlet 3.1+ 容器，如 Tomcat、Jetty；或者非 Servlet 容器，如 Netty 和 Undertow。
3、starter組件
Webflux 提供了很多 “開箱即用” 的 Starter 組件。Starter 組件是可被加載在應用中的 Maven 依賴項。只需要在 Maven 配置中添加對應的依賴配置，即可使用對應的 Starter 組件。例如，添加 spring-boot-starter-webflux 依賴，就可用於構建響應式 API 服務，其包含了 Web Flux 和 Tomcat 內嵌容器等。
4、WebFlux 官方提供了很多 Starter 組件，每個模塊會有多種技術實現選型支持，來實現各種復雜的業務需求：
- Web：Spring WebFlux
- 模板引擎：Thymeleaf
- 存儲：Redis、MongoDB、Cassandra。不支持 MySQL
- 內嵌容器：Tomcat、Jetty、Undertow
四、WebFlux 分發請求
使用過 Spring MVC 的小伙伴們，應該到知道 Spring MVC 的前端控制器是 DispatcherServlet, 而 WebFlux 是 DispatcherHandler，它實現了 WebHandler 接口：
來看看DispatcherHandler類中處理請求的 handle 方法：
①：ServerWebExchange 對象中放置每一次 HTTP 請求響應信息，包括參數等；
②：判斷整個接口映射 mappings 集合是否為空，空則創建一個 Not Found 的錯誤；
③：根據具體的請求地址獲取對應的 handlerMapping;
④：調用具體業務方法，也就是我們定義的接口方法；
⑤：處理返回的結果；
五、WebFlux 的優勢&性能
WebFlux 內部使用的是響應式編程（Reactive Programming），以 Reactor 庫為基礎, 基於異步和事件驅動，可以讓我們在不擴充硬件資源的前提下，提升系統的吞吐量和伸縮性。
看到這里，你是不是以為 WebFlux 能夠使程序運行的更快呢？量化一點，比如說我使用 WebFlux 以后，一個接口的請求響應時間是不是就縮短了呢？
抱歉了，答案是否定的！以下是官方原話：
Reactive and non-blocking generally do not make applications run faster.（翻譯：被動和非阻塞通常不會使應用程序運行得更快。）
WebFlux 並不能使接口的響應時間縮短，它僅僅能夠提升吞吐量和伸縮性。
六、WebFlux 應用場景
上面說到了， Spring WebFlux 是一個異步非阻塞式的 Web 框架，所以，它特別適合應用在 IO 密集型的服務中，比如微服務網關這樣的應用中。
PS: IO 密集型包括：磁盤IO密集型, 網絡IO密集型，微服務網關就屬於網絡 IO 密集型，使用異步非阻塞式編程模型，能夠顯著地提升網關對下游服務轉發的吞吐量。
七、選 WebFlux 還是 Spring MVC?
首先你需要明確一點就是：WebFlux 不是 Spring MVC 的替代方案！雖然 WebFlux 也可以被運行在 Servlet 容器上（需是 Servlet 3.1+ 以上的容器），但是 WebFlux 主要還是應用在異步非阻塞編程模型，而 Spring MVC 是同步阻塞的，如果你目前在 Spring MVC 框架中大量使用非同步方案，那么，WebFlux 才是你想要的，否則，使用 Spring MVC 才是你的首選。
在微服務架構中，Spring MVC 和 WebFlux 可以混合使用，比如已經提到的，對於 IO 密集型服務(如網關)，我們就可以使用 WebFlux 來實現。
選 WebFlux 還是 Spring MVC? This is not a problem！
咱不能為了裝逼而裝逼，為了技術而技術，還要考量到轉向非阻塞響應式編程學習曲線是陡峭的，小組成員的學習成本等諸多因素。
總之一句話，在合適的場景中，選型最合適的技術。