到了 Spring 5,在 Reactor 的基础上,新增了 Web Flux 作为 Reactive Web 的方案,我们在许多介绍文件的简单示例,例如〈使用 Spring 5 的 WebFlux 开发反应式 Web 应用〉,就看到当中使用了 Flux、Mono 来示范,而且,程序的代码看起来就像是 Spring MVC。这是因为 Web Flux 提供了基于 Java 注解的方式,有许多 Web MVC 中使用的标注,也拿来用在 Web Flux 之中,让熟悉 Web MVC 的开发者也容易理解与上手 Web Flux,然而,这不过就是新的 Web 框架吗?实际上,当然不是如此。Web Flux 并不依赖 Web MVC,而且它是基于 Reactor,本质属于非同步、非阻断、Reactive Programming 的心智模型,也因此,如果打算将 Web Flux 运行在 Servlet 容器之上,必须是支持 Servlet 3.1 以上,因为才有非阻断输入输出的支持,虽然 Web Flux 的 API 在某些地方,确实提供了阻断的选项,若单纯只是试着将基于 Web MVC 的应用程序,改写为套用 Web Flux,并不会有任何益处,反而会穷于应付如何在 Web Flux 实现对应的方案。例如,此时,Spring Security 显然就不能用了,毕竟是 Spring 基于 Servlet 的安全方案,开发者必须想办法套用 Spring Security Reactive;而且,在储存方案上,也不是直接采用 Spring Data,而是 Spring Data Reactive 等。就算能套用相关的设定与 API,要能获得 Web Flux 的益处,应用程序中相关的元件,也必须全面检视,重新设计为非阻断、基于 Reactive Programming 方式,这或许才是最困难、麻烦的部份。除了基于 Java 注解的方式,让熟悉 Web MVC 的开发者容易理解之外,Web Flux 还提供了基于函数式的设计与组态方式。实际上,在运用 RxJava 2/Reacto r等 Reactive Streams 的实操时,我们也都必须熟悉函数式的思考方式,才能充分掌握,这点在 Web Flux 并不例外。
可以脱离 Servlet 容器了?
Servlet 容器是个旧时代的象征,如果能够屏蔽 Servlet 容器或相关 API,许多开发者应该都会很开心,可以少一层抽象,不必使用肥肥的 Servlet 容器,当然会是使用 Web Flux 时附带的优点,然而,如果只是为了屏蔽 Servlet,其实,早就有其他技术选择存在。基于 Servlet 一路发展过来的 Web MVC,虽然目前在某些地方可以安插一些函数式的设计,然而,本质上不变的部分在于,在技术堆叠中所隐含的,仍是一个基于同步、阻断式、命令式的心智模型。如果在这样的堆叠中,开发者老是因为想要实现非同步、非阻断、Reactive、函数式而感到不快,Web Flux 也许才会是可考虑的方案,而不单只是用来作为脱离 Servlet 容器,Web MVC 的替代品。整体而言,Web Flux 还算是新技术,也还有待时间验证可行性,如果只是为了想用 Web Flux 来取代 Web MVC,或者更小一点的野心,只是想要能脱离 Servlet 容器,最好在采取行动之前,全面检视一下,确认自身或团队成员是否准备好接受 Web Flux 的心智模型,或者真的存在着对应的应用场景吧。公众号最新导航栏