Spring WebFlux 要革了誰的命？
托夢
Java國王昨晚做了一個夢。
夢中有個白胡子老頭兒，頗有仙風道骨， 告訴他說：“你們Java啊，實在是太弱了，連一個基本的功能都實現(xiàn)不了!”
國王大為驚奇：“什么功能是我堂堂大Java搞不定的?”
老頭兒展示了兩行代碼：
- float salary = 1000;
- float tax = salary * 0.1;
國王說：“這不很正常嗎，薪水(salary)是1000， 稅(tax)等于100，我國小學生都能算出來。”
老頭兒說：“我要是現(xiàn)在讓salary=2000，那tax等于多少啊?”
“還是100! 因為tax沒有被重新計算!”
“薪水變了，為什么稅不變呢? ”
“這個......”
看到國王不說話了，老頭兒繼續(xù)說：“你們得建立變量tax和變量salary之間的關聯(lián)，讓他們像Excel一樣，一個單元格的值變了，Excel的公式自然會更新另外一個單元格，讓它隨之變化。”
- float salary = 1000;
- //假設這個命令建立了tax和salary之間的關聯(lián)
- float tax <= salary *0.1
- salary = 2000 ;
- assertEquals(200,tax); //現(xiàn)在tax自動變成了200
國王說道：“你這么做有什么用啊，再說這也不是Java的問題，所有的語言都有這個問題啊......”
仙風道骨的老頭兒沒有回答， 慢慢消失了。
發(fā)布-訂閱模式
第二天早朝，國王給大臣們講了自己這個奇怪的夢，看看誰能幫自己解一解， 沒想到大臣們七嘴八舌，說自己也做了同樣的夢。
這就奇怪了，難道有神靈故意給大家托夢嗎? 在夢中，仙人老頭兒給大家舉的例子都是一模一樣的。
集合大臣小心翼翼地說道：“難道他是在暗示我國的稅收太高了嗎， 有10%，要降低一點?”
國王瞪了他一眼：“胡說些什么?我們的稅一點都不高，起征點提高到了5000，除了五險一金扣除，我們還有房貸減免，租房減免，獨生子女減免，贍養(yǎng)老人減免等一系列政策， 怎么能叫高呢?”
集合大臣趕緊噤聲。
IO大臣繼續(xù)說：“陛下不用煩惱，老頭兒說的問題，我們Java早已經(jīng)提供了對應的解決方案，那就是發(fā)布者-訂閱者模式啊。如果把Salary當成一個數(shù)據(jù)源的發(fā)布者， 把Tax當成一個訂閱者，注冊到Salary當中， 每當Salary有變化，就發(fā)送一個事件給Tax，Tax收到后，做相應的計算就可以了。”
“這不就是一種把數(shù)據(jù)持續(xù)推送給觀察者或者訂閱者的一種模式嘛，這種小兒科的東西，有什么用?” 老對頭線程大臣說道。
“在這個場景下確實沒啥用處，但是這種事件流的方式，如果處理好了，也許能解決大問題。” IO大臣雖然不太服氣，但是也想不出什么好的應用場景出來。
高并發(fā)
國王看到兩個老家伙又要干起來，馬上轉移話題：“聽說我們Java在高并發(fā)方面遇到了一點兒問題?”
IO大臣立刻興奮起來，順桿就爬：“沒錯，這二十來年，我們Java一直使用Tomcat那種線程池的方式，現(xiàn)在在越來越差勁了，難以應對高并發(fā)了。”
這一下子把Tomcat大臣，線程大臣，甚至Servlet大臣都給拉了進來，國王暗自后悔。
IO大臣繼續(xù)侃侃而談：“現(xiàn)在的模型每來一個請求都會有一個線程來處理，如果這個請求涉及到IO或者網(wǎng)絡操作，這個線程不得不阻塞等待，沒法干別的事情。”
“如果用戶的請求太多，那線程池中的線程很快就會被用光。這時候就沒辦法對外提供服務了。”
這確實是實情，基于Servlet的線程模型，就是這么工作的。
國王問道：“那個線程調用RPC服務的時候，為什么要等待呢? 讓它去干別的事情，比如處理另外一個請求不就可以了?”
“陛下圣明，這就是關鍵所在，要充分地利用線程，一點出現(xiàn)IO調用，立刻走開，去干別的事情，等到IO調用結束了，就可以通知線程去處理，這樣我們用少量的線程，就可以實現(xiàn)大量的并發(fā)了。”
國王說：“愛卿言之有理，你已經(jīng)可以實現(xiàn)這種NIO的方式了，對吧?”
“沒錯，現(xiàn)在我們要做的就是要改造Tomcat，改造甚至替換Servlet !”
回調地獄
Servlet大臣一聽就急了，自己就是傳統(tǒng)的工作方式，一個請求一個線程，要是這么搞，自己位置不保，他把目光投向了忠實的盟友線程大臣。
線程大臣心領神會：“IO大臣的辦法其實就是把同步的阻塞調用改成異步的非阻塞調用，不是那么容易啊，別的不說，這異步編程，對我們臣民來說就很不容易。”
“你不是有什么Future，Callable之類的東西嗎? 可以讓臣民們?nèi)ビ冒?” IO大臣不依不饒。
線程大臣笑了：“你是只知其一，不知其二，當你調用那個future.get()的時候，如果線程的工作(例如數(shù)據(jù)庫查詢)還沒有做完，當前線程還得等待，還是阻塞的。”
IO大臣有點兒后悔，自己怎么忽略了這一層呢?
線程大臣趁勝追擊：“還有啊，即使是按你所說，所有的操作都是異步的，都是事件驅動的，那回調會大量存在，這代碼中回調地獄問題，你考慮了嗎?”
- fun1(param,new Callback(){
- void onSuccess(...){
- ......執(zhí)行業(yè)務邏輯......
- fun2(param,new Callback(){
- void onSuccess(...){
- ......執(zhí)行業(yè)務邏輯......
- fun3(param,new Callback(){
- void onSuccess(...){
- ......執(zhí)行業(yè)務邏輯......
- fun4(param,new Callback(){
- void onSuccess(...){
- ......執(zhí)行業(yè)務邏輯......
- }
- void onError(...){
- }
- });
- }
- void onError(...){
- }
- });
- }
- void onError(...){
- }
- });
- }
- void onError(...){
- }
- });
IO大臣看到這如同亂麻般的代碼，頭嗡的一聲就大了，這異步操作居然這么變態(tài)!
國王看到IO大臣神色有異，不再說話，趕緊宣布退朝。
事件流
在朝堂上很郁悶的IO大臣怒氣沖沖地回到了家，下人送上的茶水也被他打翻在地。
幕僚已經(jīng)了解今日朝堂發(fā)生之事，走上前來：“大人息怒，小人聽說民間有個叫做Reactor的東西，用什么事件流和函數(shù)式編程中的高階函數(shù)，就能解決這個回調地獄問題。”
事件流? IO大臣突然被點醒了，我怎么沒想起這茬兒， 昨天仙人托夢不就是引導我用事件流嗎?
他趕緊問道：“具體是怎么做的?”
“我們用圖來表示，一個事件流是這樣的， 在這個時間線上，還有Error事件和Complete事件，分別用來表示出錯和完成，我就不畫了。”
“了解，可是這又有什么用呢?” IO大臣問道。
“可以使用函數(shù)式編程對這個事件流做變換，例如map，把事件從‘圓圈’ 變成了‘三角’”
“還可以用filter對事件流做過濾”
“嗯， 看起來很清楚，我想到一個場景， 先調用函數(shù)1，產(chǎn)生了事件流，然后對事件流中的每個元素，又要調用函數(shù)B，又產(chǎn)生了新的事件流，該怎么辦? ” IO大臣問道。
“大人真是厲害，抽象思維能力極高! ” 幕僚適時地拍了一下馬屁，“這時候可以用flatmap,把新的事件流給平鋪了。”
“map, filter, flatmap 僅僅是最基本的操作，還有switch , take, merge,zip等很多運算符，你想要的功能都能滿足!”
“不錯，不錯，” IO大臣興奮地直搓手，他已經(jīng)把握住了其中的關鍵思想，回調地獄可以被解決了。
比如原來的需求是先異步調用fun1, 根據(jù)fun1的結果調用fun2, 只能這么寫：
- fun1(param,new Callback(){
- void onSuccess(...){
- fun2(param,new Callback(){
- void onSuccess(...){
- ......
- }
- void onError(...){
- }
- });
- }
- void onError(...){
- }
- });
現(xiàn)在假設fun1 返回的是數(shù)據(jù)流，fun2返回的也是數(shù)據(jù)流，用這種新的方式，可以寫成這樣：
- fun1(param)
- .flatMap( e -> func2(e))
- .subscribe(r -> showResult(r),
- error -> handleError(error));
相當于把這一系列的回調給壓平了!
IO大臣問道：“你剛才說的民間的那個軟件叫什么來著? ”
“民間很多的，有RxJava, Reactor，要不要我把他們的負責人叫來聊聊?”
“慢著，光是這個Reactor， 用處不大，你把Spring大臣也請來，我們需要讓Spring去使用Reactor，拋棄Servlet， 把所有的請求和處理都變成異步處理!”
新框架
三個月后，IO大臣喜氣洋洋地向國王匯報：“陛下，臣已經(jīng)解開了仙人所托的夢，那其實是讓我Java帝國實現(xiàn)反應式編程(Reactive Programming)!”
“反應式編程? 這名字有點古怪!”
“對，這種方式是基于事件流和函數(shù)式編程的， 可以讓我們用非阻塞的、異步的方式來處理請求，還能解決回調地獄的問題。”
IO大臣把Reactor給國王講了一遍。
“那這個Reactor該如何使用? ”
“陛下還記得我們Java的高并發(fā)問題吧，就是由于沒法有效地管理異步和回調地獄導致的， 現(xiàn)在好了，臣和Spring攜手做了一個叫做Spring WebFlux的東西，獻給陛下，它不用Servlet，可以實現(xiàn)非阻塞的IO，可以有效地應對高并發(fā)。 ” IO大臣展示了一幅圖。
Servlet大臣一看，臉都綠了：我的位置在哪兒?
Tomcat大臣也覺得不爽，原來自己一家獨大，現(xiàn)在被Netty給擠走了。
只有JDBC大臣還不慌不忙：“用異步非阻塞處理所有東西? 你省省吧，我這里訪問數(shù)據(jù)庫還是阻塞的呢!”
IO大臣心中暗叫不妙，怎么忘了JDBC這么重要的東西，既然想實現(xiàn)異步、非阻塞，那一定是端到端的，全鏈路的實現(xiàn)，某個點的阻塞調用都會導致整體出問題。
可他還是保持了鎮(zhèn)靜：“不用擔心，民間的開源社區(qū)很快就會搞出來非阻塞的JDBC驅動的。”
國王看到這個新的Spring WebFlux簡直是要革了好幾個大員的命，也只好安撫一下Tomcat, Servlet：“這樣吧，新事物總得有個漸進的采納過程，我們讓Spring MVC和Spring WebFlux 并存一段時間，讓臣民們按照自己的實際情況來選擇吧!”
后記：本文中托夢中的例子來源于：http://blog.leapoahead.com/2016/03/02/introduction-to-reactive-programming/ 我做了改編。
【本文為51CTO專欄作者“劉欣”的原創(chuàng)稿件，轉載請通過作者微信公眾號coderising獲取授權】
