YZDHY的博客

之前的文章前后梳理了接收connection中的msg、将msg转成request、处理request的主流程，当业务代码执行完毕后，对response会有一段处理逻辑，本文对其进行梳理。

在webflux接收请求时，第一步实际上 netty-reacto r将 channel 中的字节信息解析成msg(实践中发现，当调用接口时若request存在异常，代码不会执行到业务代码，且不会有异常日志，初遇到时很让人困惑。返回错误信息时，response是框架层面定义的，没有response body，需要根据http code判断。此处梳理request的解析链路，重点关注异常request的处理。)，进而解析成request，之后才是webflux的处理流程。

完成了从connection中接收请求动作，之后请求会传递到了，进入webflux处理请求的主流程。这个链路上的方法调用了subscribe 方法，触发了响应式调用链的执行

分析之前，先看一下reactor提供的顶级接口发布者Publisher是一个可以发送无限序列元素的发布者，允许调用多次，每次调用都会启动一个新的。每个Subscription只能被一个Subscriber使用；Subscriber消费者只能订阅一次Publisher。//发布者/*** 订阅方法* 请求发布者启动数据流* @param s 消费者*/订阅者（消费者）其中只会被调用一次/*** 该方法在调用Publisher#subscribe(Subscriber)后执行。

WebFlux是Spring 5.0框架推出的一个全新的响应式Web框架，是基于Project Reactor构建的，它旨在利用响应式编程的特性来构建异步非阻塞的应用程序。在io密集型的场景中，使用webflux这类响应式io框架，能大幅提高系统的吞吐量。本文主要是关于其主流程的梳理，包括关键实例的创建、配置等。