Spring框架推出5.0，其中包含了WebFlux，与过去我们所知的SpringWebMVC的差异是什么？开发者们准备好接受另一套模型了吗？新版Spring的一大特色，就是ReactiveWeb方案的WebFlux，这是用来替代SpringWebMVC的吗？或者，只是终于可以不再基于Servlet容器了？
基于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的心智模型，或者真的存在着对应的应用场景吧！