学习WebFlux时常见的问题
前言
只有光頭才能變強(qiáng)。
文本已收錄至我的GitHub精選文章，歡迎Star：https://github.com/ZhongFuCheng3y/3y
回顧一下上篇我對(duì)WebFlux的入門，如果沒讀過的同學(xué)建議讀一下再來看本篇文章，上一篇文章花了我很多的心血~~
- 外行人都能看懂的WebFlux，錯(cuò)過了血虧
開局再來一張圖，內(nèi)容全靠編：
這篇主要寫寫我初學(xué)時(shí)對(duì)WebFlux的一些疑問，不知道大家在看上一篇文章的時(shí)候有沒有相應(yīng)的問題呢？
這次學(xué)WebFlux主要的動(dòng)力是公司組內(nèi)分享，寫了一個(gè)PPT，有需要的同學(xué)在我的公眾號(hào)（Java3y)下回復(fù)“PPT”即可獲取。
一、本來就能實(shí)現(xiàn)異步非阻塞，為啥要用WebFlux?
相信有過相關(guān)了解的同學(xué)都知道，Servlet 3.1就已經(jīng)支持異步非阻塞了。
我們可以以自維護(hù)線程池的方式實(shí)現(xiàn)異步
- 說白了就是Tomcat的線程處理請(qǐng)求，然后把這個(gè)請(qǐng)求分發(fā)到自維護(hù)的線程處理，Tomcat的請(qǐng)求線程返回
@WebServlet(value = "/nonBlockingThreadPoolAsync", asyncSupported = true)
public class NonBlockingAsyncHelloServlet extends HttpServlet {
private static ThreadPoolExecutor executor = new ThreadPoolExecutor(100, 200, 50000L, TimeUnit.MILLISECONDS, new ArrayBlockingQueue<>(100));
protected void doGet(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException {
AsyncContext asyncContext = request.startAsync();
ServletInputStream inputStream = request.getInputStream();
inputStream.setReadListener(new ReadListener() {
@Override
public void onDataAvailable() throws IOException {
}
@Override
public void onAllDataRead() throws IOException {
executor.execute(() -> {
new LongRunningProcess().run();
try {
asyncContext.getResponse().getWriter().write("Hello World!");
} catch (IOException e) {
e.printStackTrace();
}
asyncContext.complete();
});
}
@Override
public void onError(Throwable t) {
asyncContext.complete();
}
});
}
}
流程圖如下：
上面的例子來源：
- https://www.cnblogs.com/davenkin/p/async-servlet.html
簡(jiǎn)單的方式，我們還可以使用JDK 8 提供的CompletableFuture類，這個(gè)類可以方便的處理異步調(diào)用。
protected void doGet(HttpServletRequest request,
HttpServletResponse response) throws ServletException, IOException {
long t1 = System.currentTimeMillis();
// 開啟異步
AsyncContext asyncContext = request.startAsync();
// 執(zhí)行業(yè)務(wù)代碼(doSomething 指的是處理耗費(fèi)時(shí)間長(zhǎng)的方法)
CompletableFuture.runAsync(() -> doSomeThing(asyncContext,
asyncContext.getRequest(), asyncContext.getResponse()));
System.out.println("async use:" + (System.currentTimeMillis() - t1));
}
要處理復(fù)雜的邏輯時(shí)，無論是回調(diào)或 CompletableFuture在代碼編寫上都會(huì)比較復(fù)雜（代碼量大，不易于看懂)，而WebFlux使用的是Reactor響應(yīng)式流，里邊提供了一系列的API供我們?nèi)ヌ幚磉壿?/strong>，就很方便了。
更重要的是：
- WebFlux使用起來可以像使用SpringMVC一樣，能夠大大減小學(xué)習(xí)成本
- WebFlux也可以使用Functional Endpoints方式編程，總的來說還是要比
回調(diào)/CompletableFuture要簡(jiǎn)潔和易編寫。
值得一提的是：
如果Web容器使用的是Tomcat，那么就是使用Reactor橋接的servlet async api
如果Web容器是Netty，那么就是使用的Netty，天生支持Reactive官方的推薦是使用Netty跑WebFlux
二、WebFlux性能的問題
我們從上篇文章中就發(fā)現(xiàn)，瀏覽器去調(diào)用處理慢的接口，無論是該接口是同步的，還是說是異步的，返回到瀏覽器的時(shí)間都是一致的。
- 同步：服務(wù)器接收到請(qǐng)求，一個(gè)線程會(huì)處理請(qǐng)求，直到該請(qǐng)求處理完成，返回給瀏覽器
- 異步：服務(wù)器接收到請(qǐng)求，一個(gè)線程會(huì)處理請(qǐng)求，然后指派別的線程處理請(qǐng)求，請(qǐng)求的線程直接空閑出來。
官網(wǎng)也說了：
Reactive and non-blocking generally do not make applications run faster
使用異步非阻塞的好處就是：
The key expected benefit of reactive and non-blocking is the ability to scale with a small, fixed number of threads and less memory.That makes applications more resilient under load, because they scale in a more predictable way
好處：只需要在程序內(nèi)啟動(dòng)少量線程擴(kuò)展，而不是水平通過集群擴(kuò)展。異步能夠規(guī)避文件IO/網(wǎng)絡(luò)IO阻塞所帶來的線程堆積。
下面來看一下針對(duì)相同的請(qǐng)求量，同步阻塞和異步非阻塞的吞吐量和響應(yīng)時(shí)長(zhǎng)對(duì)比：
注：
- 請(qǐng)求量不大時(shí)(3000左右)，同步阻塞多線程處理請(qǐng)求，吞吐量和響應(yīng)時(shí)長(zhǎng)都沒落后。（按道理WebFlux可能還要落后一些，畢竟多做了一步處理
-->將請(qǐng)求委派給另一個(gè)線程去做處理 - 請(qǐng)求量大時(shí)，線程數(shù)不夠用，同步阻塞(MVC)只能等待，所以吞吐量要下降，響應(yīng)時(shí)長(zhǎng)要提高(排隊(duì))。
Spring WebFlux在應(yīng)對(duì)高并發(fā)的請(qǐng)求時(shí)，借助于異步IO，能夠以少量而穩(wěn)定的線程處理更高吞吐量的請(qǐng)求，尤其是當(dāng)請(qǐng)求處理過程如果因?yàn)闃I(yè)務(wù)復(fù)雜或IO阻塞等導(dǎo)致處理時(shí)長(zhǎng)較長(zhǎng)時(shí)，對(duì)比更加顯著。
三、WebFlux實(shí)際應(yīng)用
WebFlux需要非阻塞的業(yè)務(wù)代碼，如果阻塞，需要自己開線程池去運(yùn)行。WebFlux什么場(chǎng)景下可以替換SpringMVC呢？
- 想要內(nèi)存和線程數(shù)較少的場(chǎng)景
- 網(wǎng)絡(luò)較慢或者IO會(huì)經(jīng)常出現(xiàn)問題的場(chǎng)景
SpringMVC和WebFlux更多的是互補(bǔ)關(guān)系，而不是替換。阻塞的場(chǎng)景該SpringMVC還是SpringMVC，并不是WebFlux出來就把SpringMVC取代了。
如果想要發(fā)揮出WebFlux的性能，需要從Dao到Service，全部都要是Mono和Flux，目前官方的數(shù)據(jù)層Reactive框架只支持Redis，Mongo等幾個(gè)，沒有JDBC。
目前對(duì)于關(guān)系型數(shù)據(jù)庫(kù)，Pivotal團(tuán)隊(duì)開源出R2DBC（Reactive Relational Database Connectivity），其GitHub地址為：
- https://github.com/r2dbc
目前R2DBC支持三種數(shù)據(jù)源：
- PostgreSQL
- H2
- Microsoft SQL Server
總的來說，因?yàn)閃ebFlux是響應(yīng)式的，要想發(fā)揮出WebFlux的性能就得將代碼全改成響應(yīng)式的，而JDBC目前是沒支持的(至少M(fèi)ySQL還沒支持)，而響應(yīng)式的程序不好調(diào)試和編寫（相對(duì)于同步的程序），所以現(xiàn)在WebFlux的應(yīng)用場(chǎng)景還是相對(duì)較少的。
所以，我認(rèn)為在網(wǎng)關(guān)層用WebFlux比較合適（本來就是網(wǎng)絡(luò)IO較多的場(chǎng)景）
現(xiàn)在再回來看Spring官網(wǎng)的圖，是不是就更親切了？
參考資料：
- [https://blog.lovezhy.cc/2018/12/29/webflux%E6%80%A7%E8%83%BD%E9%97%AE%E9%A2%98/](https://blog.lovezhy.cc/2018/12/29/webflux性能問題/)
四、有必要學(xué)Functional Endpoints 編程模式嗎？
前面也提到了，WebFlux提供了兩種模式供我們使用，一種是SpringMVC 注解的，一種是叫Functional Endpoints的
Lambda-based, lightweight, and functional programming model
總的來看，就是配合Lambda和流式編程去使用WebFlux。如果你問我：有必要學(xué)嗎？其實(shí)我覺得可以先放著。我認(rèn)為現(xiàn)在WebFlux的應(yīng)用場(chǎng)景還是比較少，等真正用到的時(shí)候再學(xué)也不是什么難事，反正就是學(xué)些API嘛~
有Lambda表達(dá)式和Stream流的基礎(chǔ)，等真正用到的時(shí)候再學(xué)也不是啥問題~
以下是通過注解的方式來使用WebFlux的示例：
以下是通過Functional Endpoints的方式來使用WebFlux的示例：
路由分發(fā)器，相當(dāng)于注解的GetMapping...
UserHandler，相當(dāng)于UserController：
五、WebFlux的實(shí)際使用場(chǎng)景
總的來說，因?yàn)閃ebFlux是響應(yīng)式的，要想發(fā)揮出WebFlux的性能就得將代碼全改成響應(yīng)式的，而JDBC目前是沒支持的(至少M(fèi)ySQL還沒支持)，而響應(yīng)式的程序不好調(diào)試和編寫（相對(duì)于同步的程序），老項(xiàng)目也不太可能把依賴直接升上Spring5.0，所以現(xiàn)在WebFlux的應(yīng)用場(chǎng)景還是相對(duì)較少的(個(gè)人覺得)。
網(wǎng)關(guān)層用WebFlux比較合適（本來就是網(wǎng)絡(luò)IO較多的場(chǎng)景）
- SpringCloud Gateway是基于WebFlux實(shí)現(xiàn)的
最后
這次學(xué)WebFlux主要的動(dòng)力是公司組內(nèi)分享，寫了一個(gè)PPT，有需要的同學(xué)在我的公眾號(hào)（Java3y)下回復(fù)“PPT”即可獲取。
本已收錄至我的GitHub精選文章，歡迎Star：https://github.com/ZhongFuCheng3y/3y
樂于輸出干貨的Java技術(shù)公眾號(hào)：Java3y。公眾號(hào)內(nèi)有300多篇原創(chuàng)技術(shù)文章、海量視頻資源、精美腦圖，關(guān)注即可獲取！
非常感謝人才們能看到這里，如果這個(gè)文章寫得還不錯(cuò)，覺得「三歪」我有點(diǎn)東西的話 求點(diǎn)贊 求關(guān)注? 求分享
以上是生活随笔為你收集整理的学习WebFlux时常见的问题的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問題。
總結(jié)
- 上一篇： 6.4.1 标准库 os、os.path
- 下一篇： hdu6438 Buy and Re