取代Web MVC的Flux?

时间:2024-03-29 07:54:45

  Spring框架推出5.0,其中包含了WebFlux,与过去我们所知的SpringWebMVC的差异是什么?开发者们准备好接受另一套模型了吗?新版Spring的一大特色,就是ReactiveWeb方案的WebFlux,这是用来替代SpringWebMVC的吗?或者,只是终于可以不再基于Servlet容器了?

取代Web MVC的Flux?

  基于Servlet容器的WebMVC

  身为Java开发者,对于Spring框架并不陌生。它最初起源于2002年,是RodJohnson的著作“ExpertOne-on-OneJ2EE设计与开发”中的界面框架。到了2004年,推出Spring1.0,从XML到3.0之后,开始支援JavaConfig设定;进一步地,在2014年时,除了Spring4.0之外,首次发表了SpringBoot,最大的亮点是采用自动组态,令基于Spring的快速开发成为可能。

  对Web开发者来说,Spring中的WebMVC框架,也一直随着Spring而成长,然而由于基于Servlet容器,早期被批评测试不易(例如:控制器中包含了ServletAPI)。

  不过,从实作Controller介面搭配XML设定,到后来的标注搭配JavaConfig,WebMVC使用越来越便利。如果愿意,也可采用渐进的方式,将基于ServletAPI的Web应用程序,逐步重构为几乎没有ServletAPI的存在(可参考先前专栏文章<筛选框架必要功能>),在程式码层面达到屏壁ServletAPI的效果。

  由于不少Java开发者的Web开发经验,都是从Servlet容器中累积起来的,在这个时候,WebMVC框架基于ServletAPI,就会是一项优点。因为,虽然运用WebMVC撰写程式时,可做到不直接面对ServletAPI,然而,也意味着更强烈地受到Spring的约束,有时则是无法在庞杂设定或API中找到对应方案,有时也因为心智模型还是挂在Servlet容器,经验上难以脱离,在搞不出的HttpSession,ServletContext的对应功能时,直接从HttpSession中,ServletContext的下手,毕竟也是个方法。

  撰写程式时,就算没用到ServletAPI,WebMVC基于Servlet容器仍是事实,因为,底层还是得借助Servlet容器的功能,例如SpringSecurity,本质上还是基于Servlet容器的过滤器方案。

  然而在今日,Servlet被许多开发者视为陈旧,过时技术的象征,或许是因为这样,在JavaEE8宣布推出的这段期间,当我在某些场合谈及Servlet4.0之时,总会听到有人提出「WebFlux可以脱离Servlet了」之类的善心建议。

  实现ReactiveStreams的Reactor

  WebFlux不依赖Servlet容器是事实,然而,在谈及WebFlux之前,我们必须先知道Reactor专案,它是由Pivotal公司,也就是目前Spring的拥有者推出,实现了ReactiveStreams规范,用来支援Reactive编程的实作品。

  既然是实现了ReactiveStreams规范,开发者必然会想到的是RxJava/RxJava2,或者至是Java9的FlowAPI。这也意道着,在能使用WebFlux之前,开发者必须对于ReactiveProgramming典范,有所认识,如果你从未接触过这些玩意儿,可以参考先前专栏。

  开发者这时有疑问了,Spring为何不直接基于RxJava2,而是打造专属的ReactiveStreams实作呢?

  就技术而言,Reactor是在Java8的基础上开发,并全面拥抱Java8之后的新API,像是Lambda相关介面,新日期与时间API等,这意谓着,专案如果还是基于Java7或更早版本,就无法使用电抗器。

  在API层面,RxJava2有着因为历史发展脉络的原因,不得不保留一些令人容易困惑或混淆的模态或操作,而Reactor在这方面,都有着明确的对应API来取代,然而,却也提供与RxJava2(甚至是FlowAPI)间的转换。

  另一方面,Reactor较直觉易用,例如最常介绍的Mono与Flux,实现了ReactiveStreams的发布者介绍,并简化了讯息发布,让开发者在许多场合,不用处理Subscriber和Subscription的细节(当然,这些在Reactor也予以实现)。而在SpringWebFlux中,Mono与Flux也是主要的操作对象。想知道如何使用Mono与Flux,可以参考<使用Reactor进行反应式编程>(https://goo.gl/vc2fGc)。

  又一个的Web框架?

  到了春天5,在Reactor的基础上,新增了WebFlux作为ReactiveWeb方案,我们在许多介绍文件的简单范例,例如<使用Spring5的WebFlux开发反应式Web应用>(https://goo.gl/G5uotZ),就看到当中使用了Flux,Mono来示范,而且,程式码看起来就像是SpringMVC。

  这是因为WebFlux提供了基于Java标注的方式,有许多WebMVC中使用的标注,也拿来用于WebFlux之中,让熟悉WebMVC的开发者也容易理解与上手WebFlux,然而,这不过就是新的网络框架吗?

  实际上,当然不是如此.WebFlux并非依赖WebMVC,而且它是基于Reactor,本质属于非同步,非阻断,ReactiveProgramming的心智模型,也因此,如果打算将WebFlux运行在Servlet容器之上,必须是支援Servlet3.1以上,因为才有非阻断输入输出的支援,虽然WebFlux的API在某些地方,确实提供了阻断的选项,若单纯只是试着将基于WebMVC的应用程式,改写为套用WebFlux,并不会有任何益处,反而会穷于应付如何在WebFlux实现对应的方案。

  例如,SpringSecurity显然就不能用了,毕竟是Spring基于Servlet的安全方案,开发者必须想办法套用SpringSecurityReactive;而且,在储存方案上,也不是直接采用SpringData,而不是SpringData反应等。

  就算能套用相关的设定与API,要能获得WebFlux的益处,应用程式中相关的元件,也必须全面检视,重新设计为非阻断,基于ReactiveProgramming方式,这或许才是最困难,麻烦的部份。

  除了基于Java标注的方式,让熟悉WebMVC的开发者容易理解之外,WebFlux还提供了基于函数式的设计与组态方式。

  实际上,在运用RxJava2/Reactor等ReactiveStreams的实作时,我们也都必须熟悉函数式的思考方式,才能充分掌握,这点在WebFlux并不例外。

  可以脱离的Servlet容器了?

  Servlet容器是个旧时代的象征,如果能够屏蔽Servlet容器或相关API,许多开发者应应都会很开心,可以少一层抽象,不必使用肥肥的Servlet容器,当然会是使用WebFlux时附带的优点,然而,如果只是为了屏蔽的Servlet,其实,早就有其他技术选择存在。

  基于Servlet一路发展过来的WebMVC,虽然目前在某些地方可以安插一些函数式的设计,然而,本质上不变的部分在于,在技术堆叠中所隐含的,仍是一个基于同步,阻断式,命令式的心智模型。如果在这样的堆叠中,开发者老是因为想要实现非同步,非阻断,Reactive,函数式而感到不快,WebFlux也许才会是可考虑的方案,而不单只是用来作为脱离Servlet容器,WebMVC的替代品。

  整体而言,WebFlux还算是新技术,也还有待时间验证可行性,如果只是为了想用WebFlux来取代WebMVC,或甚至更小一点的野心,只是想要能脱离Servlet容器,最好在采取行动之前,全面检视一下,确认自身或团队成员是否准备好接受WebFlux的心智模型,或者真的存在着对应的应用场景吧!