小工匠

WebFlux有两种编程模型- 传统的 Annotated Controllers - 轻量的 Functional Endpoints Annotated Controllers 注释控制器 使用方式传统的MVC方式，允许返回Flux，Mono类型Functional Endpoints 启动非常快，占用内存少。适用小型项目，不然路由表非常复杂 > Spring MVC 和 Spring WebFlux 均能使用注解驱动 Controller，然而不同点在于并发模型和阻塞特性。>

大型系统由多个较小型的系统所构成， 因此整体效用取决于它们的构成部分的反应式属性。即时响应的系统专注于提供快速而一致的响应时间， 确立可靠的反馈上限， 以提供一致的服务质量。它们对系统的失败 也更加的包容， 而当失败确实发生时， 它们的应对方案会是得体处理而非混乱无序。反应式系统具有高度的即时响应性， 为用户提供了高效的互动反馈。解决问题通过自定义线程池， 但线程池中执行业务的时候也是同步阻塞的，比如 查询数据库 或者是调用第三方的API。在有限的资源内，做更多的功能，这就是webflux要解决的问题。

Filter/Servlet在生成响应之前可能要等待一些资源的响应以完成请求处理,比如一个jdbc查询,或者远程服务rpc调用。Servlet 3.0引入了异步处理请求的能力,使得线程可以不用阻塞等待,提早返回到容器,从而执行更多的任务请求。虽然我们可以扩大线程数量，但线程是要消耗操作系统资源的，也并非越多越好，当然了还有其他很多影响因素。再深入想一下，如果每个线程的执行时间是不可控的，而Tomcat线程池中的线程数量是有限的…是一个低效的操作,这将导致受限系统资源急剧紧张,比如线程数、连接数等等。