對Java開發者來說,2017年9月是個熱鬧的月份,非但Java SE 9、Java EE 8相繼釋出,就連Spring框架,也在這段時間發布5.0正式版。

而新版Spring的一大特色,就是Reactive Web方案Web Flux,這是用來替代Spring Web MVC的嗎?或者,只是終於可以不再基於Servlet容器了?

基於Servlet容器的Web MVC

身為Java開發者,對於Spring框架並不陌生。它最初起源於2002年、Rod Johnson著作《Expert One-on-One J2EE Design and Development》中的Interface 21框架,到了2004年,推出Spring 1.0,從XML到3.0之後,支援JavaConfig設定;進一步地,在2014年時,除了Spring 4.0之外,首次發表了Spring Boot,最大的亮點是採用自動組態,令基於Spring的快速開發成為可能。

對Web開發者來說,Spring中的Web MVC框架,也一直隨著Spring而成長,然而由於基於Servlet容器,早期被批評測試不易(例如:控制器中包含了Servlet API)。

不過,從實作Controller介面搭配XML設定,到後來的標註搭配JavaConfig,Web MVC使用越來越便利。如果願意,也可採用漸進的方式,將基於Servlet API的Web應用程式,逐步重構為幾乎沒有Servlet API的存在(可參考先前專欄文章〈篩選框架必要功能〉),在程式碼層面達到屏壁Servlet API的效果。

由於不少Java開發者的Web開發經驗,都是從Servlet容器中累積起來的,在這個時候,Web MVC框架基於Servlet API,就會是一項優點。因為,雖然運用Web MVC撰寫程式時,可做到不直接面對Servlet API,然而,也意味著更強烈地受到Spring的約束,有時則是無法在龐雜設定或API中找到對應方案,有時也因為心智模型還是掛在Servlet容器,經驗上難以脫離,在搞不出HttpSession、ServletContext對應功能時,直接從HttpSession、ServletContext下手,畢竟也是個方法。

撰寫程式時,就算沒用到Servlet API,Web MVC基於Servlet容器仍是事實,因為,底層還是得借助Servlet容器的功能,例如Spring Security,本質上還是基於Servlet容器的Filter方案。

然而在今日,Servlet被許多開發者視為陳舊、過時技術的象徵,或許是因為這樣,在Java EE 8宣布推出的這段期間,當我在某些場合談及Servlet 4.0之時,總會聽到有人提出「Web Flux可以脫離Servlet了」之類的善心建議。

實現Reactive Streams的Reactor

Web Flux不依賴Servlet容器是事實,然而,在談及Web Flux之前,我們必須先知道Reactor專案,它是由Pivotal公司,也就是目前Spring的擁有者推出,實現了Reactive Streams規範,用來支援Reactive Programming的實作品。

既然是實現了Reactive Streams規範,開發者必然會想到的是RxJava/RxJava 2,或甚至是Java 9的Flow API。這也意謂著,在能使用Web Flux之前,開發者必須對於Reactive Programming典範,有所認識,如果你從未接觸過這些玩意兒,可以參考先前專欄〈Reactive 與 Java 9〉。

開發者這時有疑問了,Spring為何不直接基於RxJava 2,而是打造專屬的Reactive Streams實作呢?

就技術而言,Reactor是在Java 8的基礎上開發,並全面擁抱Java 8之後的新API,像是Lambda相關介面、新日期與時間API等,這意謂著,專案如果還是基於Java 7或更早版本,就無法使用Reactor。

在API層面,RxJava 2有著因為歷史發展脈絡的原因,不得不保留一些令人容易困惑或混淆的型態或操作,而Reactor在這方面,都有著明確的對應API來取代,然而,卻也提供與RxJava 2(甚至是Flow API)間的轉換。

另一方面,Reactor較直覺易用,例如最常介紹的Mono與Flux,實現了Reactive Streams的Publisher介面,並簡化了訊息發布,讓開發者在許多場合,不用處理Subscriber和Subscription的細節(當然,這些在Reactor也予以實現)。而在Spring Web Flux中,Mono與Flux也是主要的操作對象。想知道如何使用Mono與Flux,可以參考〈使用Reactor進行反應式編程〉(https://goo.gl/vc2fGc)。

又一個Web框架?

到了Spring 5,在Reactor的基礎上,新增了Web Flux作為Reactive Web方案,我們在許多介紹文件的簡單範例,例如〈使用Spring 5的WebFlux開發反應式Web應用〉(https://goo.gl/G5uotZ),就看到當中使用了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/Reactor等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的心智模型,或者真的存在著對應的應用場景吧!

作者簡介


Advertisement

更多 iThome相關內容