Spring Webflux学习记录

现在Reactive在Java开发者中依然还是个雾里看花的状态，都知道不是银弹，但是也都不知道在一般的业务场景它能不能用？能用到什么程度？代价是什么？因此为了破除迷信，近距离了解这项技术，从Spring Webflux开始学习，关键心得记录如下。

异步思维

首先全异步编程是Reactive的核心，虽然一直作业务产品开发，但是对多线程操作也不陌生，直观感觉上即使是全异步编程也不会有太大的不适应。但是，全异步真的是需要另一套代码习惯。

下面这段代码，按照我一开始的理解应该是要输出都能输出，但是事实上直接就报了“java.io.IOException: Pipe closed”，也就是说由于使用了JDK8 Closeable方式的try catch写法，导致在实际写入前就在主线程被关闭。

在这里传统的优雅的写法成为了全异步化编程模型的“陋习”，不得不在onFinally或者后续的阻塞场景写一些样板代码将其close。同时这里也暴露了另一个问题，那就是在传统开发模式和Reactive混合使用时，很容易由于前置的同步代码潜在的预期语义，导致异步化后出现各种难以捉摸的异常，并且如果没写doOnError还会丢失异常信息。

@RestController
@RequestMapping("/test")
public class GreetingHandler {

    @GetMapping("/hello")
    public Flux<String> hello(ServerHttpRequest request) {
        return Flux.just("a", "b", "c");
    }
}

public static void main(String[] args) throws Exception {
    String url = "http://localhost:8080/test/hello";
    Flux<DataBuffer> response = WebClient.create()
        .get().uri(url).exchange()
        .flatMapMany(b -> b.bodyToFlux(DataBuffer.class));

    try(PipedOutputStream outputStream = new PipedOutputStream();
        PipedInputStream inputStream = new PipedInputStream(outputStream)) {
        DataBufferUtils.write(response, outputStream)
            .doFinally(s -> {
                System.out.println("doFinally: " + s.toString() + Thread.currentThread().getId());
                try {
                    System.out.println(inputStream.available());
                } catch (IOException e) {
                    e.printStackTrace();
                }
            })
            .doOnNext(dataBuffer -> {
                System.out.println("doOnNext" + Thread.currentThread().getId());
            })
            .doOnError(t -> {
                logger.error("", t);
            })
            .subscribe(DataBufferUtils.releaseConsumer());
    } catch (Exception e) {
        logger.error("", e);
    }
}           

客户端限制

Webflux将Controller的返回固定成另Mono和Flux两种，通过使用浏览器接收到的和普通接口无二，那Webflux真的不限制客户端类型吗？

了解这个问题最好的办法一是看源码，其次就是抓包看一下通信协议。本次使用Wireshark抓包，截图如下。从服务端返回可以看出发送了三次数据，因此说明FLux接口会分成多个chunk返回客户端，同时整体上还是一个完整的HTTP协议，所以客户端不受服务端选型影响。

小结

从目前的初步了解来看，在一般的业务中实战Reactive就是个高风险的选型，因为有性能压力的往往只会是少数几个接口，而开发模型混合之后维护难度会加大不少，这或许就是节约成本的代价。