Spring WebFlux 要革了谁的命？

托梦

Java国王昨晚做了一个梦。

梦中有个白胡子老头儿，颇有仙风道骨， 告诉他说：“你们 Java 啊，实在是太弱了，连一个基本的功能都实现不了!”

国王大为惊奇：“什么功能是我堂堂大Java搞不定的?”

老头儿展示了两行代码：

float salary = 1000; 
float tax =  salary * 0.1; 

国王说：“这不很正常吗，薪水(salary)是1000， 税(tax)等于100，我国小学生都能算出来。”

老头儿说：“我要是现在让salary=2000，那tax等于多少啊?”

“还是100! 因为tax没有被重新计算!”

“薪水变了，为什么税不变呢? ”

“这个......”

看到国王不说话了，老头儿继续说：“你们得建立变量tax和变量salary之间的关联，让他们像Excel一样，一个单元格的值变了，Excel的公式自然会更新另外一个单元格，让它随之变化。”

float salary = 1000; 
//假设这个命令建立了tax和salary之间的关联 
float tax <=  salary *0.1 
salary = 2000 ; 
assertEquals(200,tax);  //现在tax自动变成了200 

国王说道：“你这么做有什么用啊，再说这也不是Java的问题，所有的语言都有这个问题啊......”

仙风道骨的老头儿没有回答， 慢慢消失了。

发布-订阅模式

第二天早朝，国王给大臣们讲了自己这个奇怪的梦，看看谁能帮自己解一解， 没想到大臣们七嘴八舌，说自己也做了同样的梦。

这就奇怪了，难道有神灵故意给大家托梦吗? 在梦中，仙人老头儿给大家举的例子都是一模一样的。

集合大臣小心翼翼地说道：“难道他是在暗示我国的税收太高了吗， 有10%，要降低一点?”

国王瞪了他一眼：“胡说些什么?我们的税一点都不高，起征点提高到了5000，除了五险一金扣除，我们还有房贷减免，租房减免，独生子女减免，赡养老人减免等一系列政策， 怎么能叫高呢?”

集合大臣赶紧噤声。

IO大臣继续说：“陛下不用烦恼，老头儿说的问题，我们Java早已经提供了对应的解决方案，那就是发布者-订阅者模式啊。如果把Salary当成一个数据源的发布者， 把Tax当成一个订阅者，注册到Salary当中， 每当Salary有变化，就发送一个事件给Tax，Tax收到后，做相应的计算就可以了。”

“这不就是一种把数据持续推送给观察者或者订阅者的一种模式嘛，这种小儿科的东西，有什么用?” 老对头线程大臣说道。

“在这个场景下确实没啥用处，但是这种事件流的方式，如果处理好了，也许能解决大问题。” IO大臣虽然不太服气，但是也想不出什么好的应用场景出来。

高并发

国王看到两个老家伙又要干起来，马上转移话题：“听说我们Java在高并发方面遇到了一点儿问题?”

IO大臣立刻兴奋起来，顺杆就爬：“没错，这二十来年，我们Java一直使用Tomcat那种线程池的方式，现在在越来越差劲了，难以应对高并发了。”

这一下子把Tomcat大臣，线程大臣，甚至Servlet大臣都给拉了进来，国王暗自后悔。

IO大臣继续侃侃而谈：“现在的模型每来一个请求都会有一个线程来处理，如果这个请求涉及到IO或者网络操作，这个线程不得不阻塞等待，没法干别的事情。”

“如果用户的请求太多，那线程池中的线程很快就会被用光。这时候就没办法对外提供服务了。”

这确实是实情，基于Servlet的线程模型，就是这么工作的。

国王问道：“那个线程调用RPC服务的时候，为什么要等待呢? 让它去干别的事情，比如处理另外一个请求不就可以了?”

“陛下圣明，这就是关键所在，要充分地利用线程，一点出现IO调用，立刻走开，去干别的事情，等到IO调用结束了，就可以通知线程去处理，这样我们用少量的线程，就可以实现大量的并发了。”

国王说：“爱卿言之有理，你已经可以实现这种NIO的方式了，对吧?”

“没错，现在我们要做的就是要改造Tomcat，改造甚至替换Servlet !”

回调地狱

Servlet大臣一听就急了，自己就是传统的工作方式，一个请求一个线程，要是这么搞，自己位置不保，他把目光投向了忠实的盟友线程大臣。

线程大臣心领神会：“IO大臣的办法其实就是把同步的阻塞调用改成异步的非阻塞调用，不是那么容易啊，别的不说，这异步编程，对我们臣民来说就很不容易。”

“你不是有什么Future，Callable之类的东西吗? 可以让臣民们去用啊!” IO大臣不依不饶。

线程大臣笑了：“你是只知其一，不知其二，当你调用那个future.get()的时候，如果线程的工作(例如数据库查询)还没有做完，当前线程还得等待，还是阻塞的。”

IO大臣有点儿后悔，自己怎么忽略了这一层呢?

线程大臣趁胜追击：“还有啊，即使是按你所说，所有的操作都是异步的，都是事件驱动的，那回调会大量存在，这代码中回调地狱问题，你考虑了吗?”

fun1(param,new Callback(){ 
    void onSuccess(...){ 
        ......执行业务逻辑...... 
        fun2(param,new Callback(){   
            void onSuccess(...){ 
                ......执行业务逻辑...... 
                fun3(param,new Callback(){ 
                    void onSuccess(...){ 
                        ......执行业务逻辑...... 
                        fun4(param,new Callback(){ 
                            void onSuccess(...){ 
                                ......执行业务逻辑......                               
                            } 
                            void onError(...){ 
                            } 
                        }); 
                    } 
                    void onError(...){ 
                    } 
                }); 
            } 
            void onError(...){ 
            } 
        }); 
    } 
    void onError(...){ 
    } 
}); 

IO大臣看到这如同乱麻般的代码，头嗡的一声就大了，这异步操作居然这么变态!

国王看到IO大臣神色有异，不再说话，赶紧宣布退朝。

事件流

在朝堂上很郁闷的IO大臣怒气冲冲地回到了家，下人送上的茶水也被他打翻在地。

幕僚已经了解今日朝堂发生之事，走上前来：“大人息怒，小人听说民间有个叫做Reactor的东西，用什么事件流和函数式编程中的高阶函数，就能解决这个回调地狱问题。”

事件流? IO大臣突然被点醒了，我怎么没想起这茬儿， 昨天仙人托梦不就是引导我用事件流吗?

他赶紧问道：“具体是怎么做的?”

“我们用图来表示，一个事件流是这样的， 在这个时间线上，还有Error事件和Complete事件，分别用来表示出错和完成，我就不画了。”

“了解，可是这又有什么用呢?” IO大臣问道。

“可以使用函数式编程对这个事件流做变换，例如map，把事件从‘圆圈’ 变成了‘三角’”

“还可以用filter对事件流做过滤”

“嗯， 看起来很清楚，我想到一个场景， 先调用函数1，产生了事件流，然后对事件流中的每个元素，又要调用函数B，又产生了新的事件流，该怎么办? ” IO大臣问道。

“大人真是厉害，抽象思维能力极高! ” 幕僚适时地拍了一下马屁，“这时候可以用flatmap,把新的事件流给平铺了。”

“map, filter, flatmap 仅仅是最基本的操作，还有switch , take, merge,zip等很多运算符，你想要的功能都能满足!”

“不错，不错，” IO大臣兴奋地直搓手，他已经把握住了其中的关键思想，回调地狱可以被解决了。

比如原来的需求是先异步调用fun1, 根据fun1的结果调用fun2, 只能这么写：

fun1(param,new Callback(){ 
    void onSuccess(...){      
        fun2(param,new Callback(){   
            void onSuccess(...){ 
                ...... 
            } 
            void onError(...){ 
            } 
        }); 
    } 
    void onError(...){ 
    } 
}); 

现在假设fun1 返回的是数据流，fun2返回的也是数据流，用这种新的方式，可以写成这样：

fun1(param) 
.flatMap( e -> func2(e)) 
.subscribe(r -> showResult(r),  
      error -> handleError(error)); 

相当于把这一系列的回调给压平了!

IO大臣问道：“你刚才说的民间的那个软件叫什么来着? ”

“民间很多的，有RxJava, Reactor，要不要我把他们的负责人叫来聊聊?”

“慢着，光是这个Reactor， 用处不大，你把Spring大臣也请来，我们需要让Spring去使用Reactor，抛弃Servlet， 把所有的请求和处理都变成异步处理!”

新框架

三个月后，IO大臣喜气洋洋地向国王汇报：“陛下，臣已经解开了仙人所托的梦，那其实是让我Java帝国实现反应式编程(Reactive Programming)!”

“反应式编程? 这名字有点古怪!”

“对，这种方式是基于事件流和函数式编程的， 可以让我们用非阻塞的、异步的方式来处理请求，还能解决回调地狱的问题。”

IO大臣把Reactor给国王讲了一遍。

“那这个Reactor该如何使用? ”

“陛下还记得我们Java的高并发问题吧，就是由于没法有效地管理异步和回调地狱导致的， 现在好了，臣和Spring携手做了一个叫做Spring WebFlux的东西，献给陛下，它不用Servlet，可以实现非阻塞的IO，可以有效地应对高并发。 ” IO大臣展示了一幅图。

Servlet大臣一看，脸都绿了：我的位置在哪儿?

Tomcat大臣也觉得不爽，原来自己一家独大，现在被Netty给挤走了。

只有JDBC大臣还不慌不忙：“用异步非阻塞处理所有东西? 你省省吧，我这里访问数据库还是阻塞的呢!”

IO大臣心中暗叫不妙，怎么忘了JDBC这么重要的东西，既然想实现异步、非阻塞，那一定是端到端的，全链路的实现，某个点的阻塞调用都会导致整体出问题。

可他还是保持了镇静：“不用担心，民间的开源社区很快就会搞出来非阻塞的JDBC驱动的。”

国王看到这个新的Spring WebFlux简直是要革了好几个大员的命，也只好安抚一下Tomcat, Servlet：“这样吧，新事物总得有个渐进的采纳过程，我们让Spring MVC和Spring WebFlux 并存一段时间，让臣民们按照自己的实际情况来选择吧!”

后记：本文中托梦中的例子来源于：http://blog.leapoahead.com/2016/03/02/introduction-to-reactive-programming/ 我做了改编。

【本文为51CTO专栏作者“刘欣”的原创稿件，转载请通过作者微信公众号coderising获取授权】

戳这里，看该作者更多好文