Spring WebFlux
WebFlux と呼ばれる Spring WebFlux は、Spring 5.0 で新しく導入されたフレームワークです。
SpringBoot は WebFlux の自動構成も提供します。
Spring WebFlux と Spring MVC は競合関係にあり、どちらもフレームワークです。両方が 1 つのプロジェクト内に存在することもできます。
SpringMVC はサーブレット API に基づいており、同期フレームワークです。リクエストが到着したとき、SpringMVC がリクエストされたデータを取得したとき、データが読み取られていない場合、データを読み取っているスレッドは常にブロックされます。つまり、クライアントがリクエストを送信するたびに、サーバーはリクエストを処理するためにスレッドを割り当てる必要があります。したがって、同時実行性が高い場合、SpringMVC にはいくつかの制限があります。
WebFlux は、サーブレット API から分離されたリアクティブ API に基づいており、リアクティブ API は非同期であり、リクエストごとに個別のスレッドを生成する必要はありません。
Spring WebFlux は Reactor フレームワークを統合/Reactor フレームワークに基づいています
Spring WebFlux と Reactor はデフォルトで Netty を Web サーバーとして使用します
★リアクターフレームワーク（リアクティブフレームワーク）
Reactor框架采用Mono和Flux两个类代表消息发布者，因此它们都实现了CorePublisher<T>接口，它们的区别在于：
- Mono代表0～1个非阻塞数据；而Flux则代表0～N数据个非阻塞序列。
- Mono相当于只是一个Optional值；而Flux才是Stream。
基本原理，其实就是基于 消息发布 - 消息订阅 的异步通信方式。
★春のWebFlux
Spring WebFlux就是基于Reactor实现的，其中Flux名称就是来自Reactor中的Flux类，WebFlux包括了
对反应式HTTP、服务器推送事件（SSE：Server Send Event）及WebSocket的支持。
Spring WebFlux提供了两种开发方式：
- 使用类似Spring MVC的注解方式。在这种方式下，依然使用@Controller、@RequestMapping等注解修饰类、方法即可。
- 使用函数式编程模型的方式。在这种方式下，程序使用RouterFunction来注册映射地址和处理器方法之间路由关系。
上面这两种编程模型只是形式上有所不同（代码编写方式上存在不同），它们本质上完全是一样的，
它们都运行在相同的反应式流的基础之上。
★ Spring MVC VS Spring WebFlux
================================Spring MVC ================================
--- Spring MVC 基于传统Servlet，服务器需要使用很大的线程池才能支持大量的并发请求；
HttpServletRequest来获取请求参数：getParameter()，它是一个典型的同步方法，该方法的返回值是String类型。
——这意味着在没有获取请求参数之前，该方法就会阻塞线程，这就是同步。
HttpServletResponse来生成响应，它也是同步：服务器生成的响应完全发送给客户端之前，该线程什么也做不了。
这种同步的设计意味着，每当一个客户端请求到来时，必须启动单独的线程来为该请求提供服务。
当请求的并发数量非常大时，只能通过水平的集群扩展、增加更多集群节点来处理这些并发请求。
================================Spring WebFlux=============================
--- Spring WebFlux采用异步、非阻塞的编程模型，底层反应式容器无需启动额外的线程。
ServerRequest来获取请求参数，
比如 bodyToFlux(Class<? extends T> elementClass)、
bodyToMono(Class<? extends T> elementClass)、
formData()
这些的返回值都是 Flux 或 Mono
而 Flux 和 Mono 都并不是最终的数据 ，因此无需同步、阻塞等待数据的到来，Mono和Flux都是CorePublisher
因此它们可以说只是消息发布者（或者说是一个消息通道，可以不管获取的消息是否有数据），而尝试获取消息的程序就是消息订阅者。
这意味着程序在获取Flux或Mono之后，完全可以继续向下执行，无需阻塞线程。
Spring WebFlux的最大优势在于：能以较小的、固定数量的线程和更少的内存处理更多的并发请求，
因此Spring WebFlux可以在高负载的情况具有更好的可伸缩性——因为无需显著增加线程和内存。
Spring MVC适用于同步处理的场景，Spring WebFlux适用于异步处理的场景，
尤其在大量IO密集型（比如Spring Cloud网关）的服务中使用Spring WebFlux比较适合。
★ Spring WebFluxの自動設定
Spring WebFlux的自动配置主要由WebFluxAutoConfiguration自动配置类负责提供支持。
自动配置在Spring WebFlux默认功能的基础上添加了如下特性：
- 为HttpMessageReader和HttpMessageWriter实例配置了codecs。
- 对服务器静态资源提供支持，包括对WebJars的支持。
★ WebFlux 自動構成をカスタマイズします。
若要在保留自动配置的基础上增加一些自定义的Spring WebFlux配置（例如添加拦截器、格式化器、视图控制器等），
则可通过实现自己的WebFluxConfigurer类，并使用@Configuration注解修饰该类、但不要使用@EnableWebFlux注解修饰。
实现该类的如下方法：
- addFormatters(FormatterRegistry registry)：添加格式化器
- configureArgumentResolvers(ArgumentResolverConfigurer configurer)：配置参数解析器
- configurePathMatching(PathMatchConfigurer configurer)：配置路径匹配器
- configureViewResolvers(ViewResolverRegistry registry)：配置视图解析器
...
★完全買収
如果使用@Configuration和@EnableWebFlux注解同时修饰自己的Spring WebFlux配置类。
这意味着完全关闭了Spring WebFlux的自动配置，开发者必须手动完成所有关于Spring WebFlux的配置工作。
★ 静的リソース処理
(Spring Boot が提供する Spring MVC の静的リソース処理と完全に似ています)
与Spring MVC类似，Spring Boot同样使用类加载路径下/static目录（或/public或/resources或/META-INF/resources）
或应用根路径作为WebFlux的静态资源路径。
如需添加静态资源路径，可提供WebFluxConfigurer实现类，通过实现addResourceHandlers()方法可添加自定义的静态资源目录
如果要更改，覆盖原来的静态资源目录，可通过spring.web.resources.static-locations来覆盖系统原有的静态资源目录。
同样支持版本无关的静态资源和静态资源缓存清除
★アイコンとホームページ
(Spring Boot のホームページと Spring MVC のアイコンのサポートにまったく似ています)
与Spring MVC类似，Spring WebFlux同样可使用静态资源路径下的index.html或templates路径下index模板作为应用的首页。
Spring WebFlux同样会使用静态资源路径下的favicon.ico文件作为应用的图标。