学习WebFlux时常见的问题

前言

只有光头才能变强。

文本已收录至个人GitHub精选文章，欢迎Star：https://github.com/ZhongFuCheng3y/3y

回顾一下上篇我对WebFlux的入门，若是没读过的同窗建议读一下再来看本篇文章，上一篇文章花了我不少的心血~~

• 外行人都能看懂的WebFlux，错过了血亏

开局再来一张图，内容全靠编：

这篇主要写写我初学时对WebFlux的一些疑问，不知道你们在看上一篇文章的时候有没有相应的问题呢？

此次学WebFlux主要的动力是公司组内分享，写了一个PPT，有须要的同窗在个人公众号（Java3y)下回复“PPT”便可获取。

1、原本就能实现异步非阻塞，为啥要用WebFlux?

相信有过相关了解的同窗都知道，Servlet 3.1就已经支持异步非阻塞了。

咱们能够以自维护线程池的方式实现异步

• 说白了就是Tomcat的线程处理请求，而后把这个请求分发到自维护的线程处理，Tomcat的请求线程返回

@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

简单的方式，咱们还可使用JDK 8 提供的CompletableFuture类，这个类能够方便的处理异步调用。

protected void doGet(HttpServletRequest request,
                     HttpServletResponse response) throws ServletException, IOException {
    long t1 = System.currentTimeMillis();

    // 开启异步
    AsyncContext asyncContext = request.startAsync();

    // 执行业务代码(doSomething 指的是处理耗费时间长的方法)
    CompletableFuture.runAsync(() -> doSomeThing(asyncContext,
                                                 asyncContext.getRequest(), asyncContext.getResponse()));

    System.out.println("async use:" + (System.currentTimeMillis() - t1));
}

要处理复杂的逻辑时，不管是回调或 CompletableFuture在代码编写上都会比较复杂（代码量大，不易于看懂)，而WebFlux使用的是Reactor响应式流，里边提供了一系列的API供咱们去处理逻辑，就很方便了。

更重要的是：

• WebFlux使用起来能够像使用SpringMVC同样，可以大大减少学习成本
• WebFlux也可使用Functional Endpoints方式编程，总的来讲仍是要比回调/CompletableFuture要简洁和易编写。

值得一提的是：

若是Web容器使用的是Tomcat，那么就是使用Reactor 桥接的servlet async api
若是Web容器是Netty，那么就是使用的Netty，天生支持Reactive

官方的推荐是使用Netty跑WebFlux

2、WebFlux性能的问题

咱们从上篇文章中就发现，浏览器去调用处理慢的接口，不管是该接口是同步的，仍是说是异步的，返回到浏览器的时间都是一致的。

• 同步：服务器接收到请求，一个线程会处理请求，直到该请求处理完成，返回给浏览器
• 异步：服务器接收到请求，一个线程会处理请求，而后指派别的线程处理请求，请求的线程直接空闲出来。

官网也说了：

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

好处：只须要在程序内启动少许线程扩展，而不是水平经过集群扩展。异步可以规避文件IO/网络IO阻塞所带来的线程堆积。

下面来看一下针对相同的请求量，同步阻塞和异步非阻塞的吞吐量和响应时长对比：

注：

• 请求量不大时(3000左右)，同步阻塞多线程处理请求，吞吐量和响应时长都没落后。（按道理WebFlux可能还要落后一些，毕竟多作了一步处理-->将请求委派给另外一个线程去作处理
• 请求量大时，线程数不够用，同步阻塞(MVC)只能等待，因此吞吐量要降低，响应时长要提升(排队)。

Spring WebFlux在应对高并发的请求时，借助于异步IO，可以以少许而稳定的线程处理更高吞吐量的请求，尤为是当请求处理过程若是由于业务复杂或IO阻塞等致使处理时长较长时，对比更加显著。

3、WebFlux实际应用

WebFlux须要非阻塞的业务代码，若是阻塞，须要本身开线程池去运行。WebFlux什么场景下能够替换SpringMVC呢？

• 想要内存和线程数较少的场景
• 网络较慢或者IO会常常出现问题的场景

SpringMVC和WebFlux更多的是互补关系，而不是替换。阻塞的场景该SpringMVC仍是SpringMVC，并非WebFlux出来就把SpringMVC取代了。

若是想要发挥出WebFlux的性能，须要从Dao到Service，所有都要是Mono和Flux，目前官方的数据层Reactive框架只支持Redis，Mongo等几个，没有JDBC。

目前对于关系型数据库，Pivotal团队开源出R2DBC（Reactive Relational Database Connectivity），其GitHub地址为：

• https://github.com/r2dbc

目前R2DBC支持三种数据源：

• PostgreSQL
• H2
• Microsoft SQL Server

总的来讲，由于WebFlux是响应式的，要想发挥出WebFlux的性能就得将代码全改为响应式的，而JDBC目前是没支持的(至少MySQL还没支持)，而响应式的程序很差调试和编写（相对于同步的程序），因此如今WebFlux的应用场景仍是相对较少的。

因此，我认为在网关层用WebFlux比较合适（原本就是网络IO较多的场景）

如今再回来看Spring官网的图，是否是就更亲切了？

参考资料：

• [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/...

4、有必要学Functional Endpoints 编程模式吗？

前面也提到了，WebFlux提供了两种模式供咱们使用，一种是SpringMVC 注解的，一种是叫Functional Endpoints的

Lambda-based, lightweight, and functional programming model

总的来看，就是配合Lambda和流式编程去使用WebFlux。若是你问我：有必要学吗？其实我以为能够先放着。我认为如今WebFlux的应用场景仍是比较少，等真正用到的时候再学也不是什么难事，反正就是学些API嘛~

有Lambda表达式和Stream流的基础，等真正用到的时候再学也不是啥问题~

如下是经过注解的方式来使用WebFlux的示例：

如下是经过Functional Endpoints的方式来使用WebFlux的示例：

路由分发器，至关于注解的GetMapping...

UserHandler，至关于UserController：

5、WebFlux的实际使用场景

总的来讲，由于WebFlux是响应式的，要想发挥出WebFlux的性能就得将代码全改为响应式的，而JDBC目前是没支持的(至少MySQL还没支持)，而响应式的程序很差调试和编写（相对于同步的程序），老项目也不太可能把依赖直接升上Spring5.0，因此如今WebFlux的应用场景仍是相对较少的(我的以为)。

网关层用WebFlux比较合适（原本就是网络IO较多的场景）

• SpringCloud Gateway是基于WebFlux实现的

最后

服务器89/年，229/3年，买来送本身，送女友立刻过年再合适不过了，买了搭建个项目给面试官看也香，还能够熟悉技术栈，(老用户用家人帐号买就行了，我用我女友的😂）。扫码或者点击购买

搭建教程，从0开始一步一步带你搭建😂

此次学WebFlux主要的动力是公司组内分享，写了一个PPT，有须要的同窗在个人公众号（Java3y)下回复“PPT”便可获取。

本已收录至个人GitHub精选文章，欢迎Star： https://github.com/ZhongFuCheng3y/3y

乐于输出干货的Java技术公众号：Java3y。公众号内有300多篇原创技术文章、海量视频资源、精美脑图，关注便可获取！

很是感谢人才们能看到这里，若是这个文章写得还不错，以为「三歪」我有点东西的话 求点赞 求关注️ 求分享👥 求留言💬 对暖男我来讲真的 很是有用！！！

创做不易，各位的支持和承认，就是我创做的最大动力，咱们下篇文章见！