再见了SpringMVC！这个框架有点厉害，甚至干掉了Servlet！

# 前言

对于所有的 Java 开发人员而言，在版本更新方面确实迈出了重要一步。

# 基于 Servlet 容器的 Web MVC

作为一位熟练的Java开发者所知，在Spring框架方面有着丰富的经验。
这款软件技术源自于Rod Johnson在《 Expert One-on-One J2EE Design and Development》一书中提出的Interface 21框架设计。
随着时间推移逐步发展完善。
在早期版本中从XML开始到版本3.0后逐渐引入并支持JavaConfig设定。
直至2014年才真正推出一个更成熟的版本——Spring Boot。
其最大亮点在于采用自动生成配置的能力。

对Web开发者而言，在Spring框架体系中逐渐成熟的Web MVC架构也始终伴随着Spring的发展而不断演进和完善。然而由于其基于ServletContext容器的特点，在早期曾受到批评难以实现高效的测试功能（例如：控制器中集成有Servlet API组件）。

然而，在实操中运用Controller面板与XML设置的过程中发展出使用annotations和JavaConfig进行配置的方法，并逐渐使Web MVC的应用变得更加便捷。如果有兴趣，则可以通过渐近式的方法来实现这一目标：对于基于ServletContext API的Web应用程序而言，在不依赖ServletContext API的情况下逐步地将这些应用逐步重构至几乎不再依赖ServletContext API的状态，并最终使得在代码层面上完全消除了对ServletContext API的依赖。

考虑到大多数Java开发者积累的Web开发经验主要源自他们对Servlet容器的深入了解。那时，“基于ServletContext框架构建的WebMVC确实具有显著优势”。尽管使用WebMVC编程时可以避免直接与ServletContext框架交互，并且也能减少对Spring这一流行技术的支持依赖。然而这也可能导致开发人员过分依赖Spring的应用架构模式。有时候会发现无法通过简单的配置或标准API来解决问题。同样会受限于对ServletContext框架的传统思维模式。遇到HttpSession和HttpServerSession相关功能无法匹配时，默认的做法就是从HttpSession、HttpServerSession下手处理问题

在开发过程中, 即使未涉及ServletContext API, Web MVC始终建立在该容器的基础之上, 因为开发过程仍需依赖于该容器的功能, 例如Spring Security框架, 最终仍采用基于Filter方案的实现。

然而今日,Servlet 被许多开发者视为老旧、过时的技术象征,这是因为提及 Servlet 4.0 的场合中,总会听到有人提出"Web Flux 已经不再依赖于 servlet"之类的观点

# 实现 Reactive Streams 的 Reactor

Web Flux无需依赖Java Servlet容器的事实。然而，在提及Web Flux之前必须先了解Reactor项目。这个项目由Pivotal公司开发，并遵循了Reactive Streams规范作为支持反应式编程的产物。

既然遵循了 Reactive Streams 标准, 开发者自然会联想到 RxJava 或者是 RxJava 2, 而且也可能是 Java 9 的 Flow API. 这也意味着, 在使用 Web Flux 前, 开发者必须对 reactive programming 标范有所了解.

开发者这时感到疑惑：Spring为何没有直接基于RxJava 2而开发专属的Reactive Streams项目呢？

就技术特性而言，Reactor遵循Java 8的整体框架。它充分整合了Java 8之后推出的最新API组件，并包括如Lambda API接口和新的日期时间处理功能等核心组件。这意味着如果项目的开发环境仍基于Java 7或更旧版本，则无法使用Reactor。

在API层面，在经过其历史发展脉络的影响下

另一方面, React因其直观易用性著称, 其中最为常见的两种工具是 Mono 和 Flux. 它们均实现了对 Reactive Streams 发布商界面的支持, 并简化了信息发布的流程, 让开发者无需在众多场景中处理订阅者（subscriber）和订阅（subscription）的细节（而这些功能在 Reactions 中同样被实现）. 相比之下, 在 Spring Web Flux 中, Mono 和 Flux 则是其主要操作对象. 如需深入了解如何利用 Mono 与 Flux 进行开发, 请参考《使用 Reactor 实现反应式编程》.

# 又一个 Web 框架？

引入了 Spring 5版本后，在基于 Reactor 框架的基础上增加了 Web Flux方案作为Reactive Web的应用方法之一。在一些简明示例文件中展示了这一技术应用过程，并详细说明其中采用了 Flux框架以及 Mono组件来进行功能实现，并且程序的整体架构设计思路与传统SpringMVC开发模式具有高度相似性

说明

因为 Web Flux 采用了基于 Java 注解的设计模式，并将许多 Web MVC 中常见的注解也引入到其框架中。从而帮助熟悉 Web MVC 开发者的用户更容易理解和掌握 Web Flux 的应用。然而这本质上是否只是新的 Web 框架呢？

实际上并非如此。Web_flux_不依赖于web_mvc这一技术架构，并且它采用的是Reactor框架作为其核心基础。其核心理念是建立在无并发、无阻塞以及响应式编程的思想之上。因此如果希望将web_flux_部署到Servlet容器上则必须具备Servlet_3.1及以上版本的支持是因为它需要无阻塞输入输出功能来实现高效处理。尽管web_flux_的API在某些方面确实提供了阻断功能的支持但若单纯只是试着将基于web_mvc的应用程序改写为套用web_flux_并不会有任何益处反而会增加开发难度

比如在这种情况下

尽管能够应用相关设置及API，并不代表能够充分带来Web Flux的好处，在其中涉及的应用程序组件也需要进行全面审查，并重新架构为非阻断型且基于Reactive Programming的方式。这可能是实现起来最为复杂和费时的部分。

除了Java注解实现的方法外，在为熟悉WebMVC的开发者易于理解的基础上，WebFlux还提供了基于函数式的架构与配置方式。

特别是在实践中使用Reactive Streams技术的情况下，在实际操作中采用RxJava 2/Reactors等Reactive Streams技术的情况下，并非所有人都能完全掌握其中的精髓所在，并且这一点在Web Flux平台也不可忽视

# 可以脱离 Servlet 容器了？

Servlet容器象征着旧时代的特性，在某些情况下若能规避去掉ServletContext及其相关的API层架构设计，则开发者们对于这一情况通常会感到欣喜若狂——因为这将减少一层抽象层次,无需依赖于笨重笨拙的ServletContext框架,从而能够更加高效地完成Web应用开发任务。然而,一旦采用WebFlux技术方案,则可获得一些额外优势——比如自动化的事务处理能力等特性,但其实不然地讲,即使只是单纯为了规避掉ServletContext本身的技术选择也不过是杯水车薪之举而已——毕竟在现代Web开发领域里已经有许多更为成熟可靠的技术替代方案可供选择

基于Servlet经历了长时间的发展与演进，在Web应用领域逐渐形成了经典的Web MVC模式。尽管在某些特定场景中可以引入一些函数式的概念与设计手法进行拓展与集成（Integrate），但其本质未变的部分在于：在技术堆叠的过程中所隐含的核心思维方式仍是一个基于同步机制、阻断机制以及命令式的运行逻辑模型（Model）。如果开发者常常因为希望实现非同步运行、无阻断机制以及Reactive特性，并且追求函数式编程风格而感到不满或不便（Discontent），那么Web Flux或许才是一个值得考虑的解决方案；而单纯地作为一种替代品用于脱离Servlet容器环境的技术方案（Technology），Web MVC本身并不具备这样的特性

就目前情况来看，Web Flux 被视为一项新兴技术，并尚需时间验证其实用性。如果只是单纯考虑将Web Flux替代WebMVC这一方案的话，并且规模较小的设想，则仅仅是为了能够脱离Servlet容器这一目标而存在的情况下建议，在采取行动前进行充分评估，并进行全面检查以确保现有团队是否已准备好接受这一新的技术架构是否存在适用的具体场景呢？

本人特意为Java学习者整理了一份高级技术资料。
包括了Java以及Redis、MongoDB、MySQL、Zookeeper、Spring Cloud和Dubbo等高阶技术与应用。
总共有30G的数据量，方便获取。

获取入口：资料领取