[Day 20] Reactive Programming - Spring WebFlux

前言

对Reactor有一定的认识之後，接下来就要进入正题(迷：经过二十天才到正题？！)，毕竟大部分的开发者不太会单独使用Reactor，势必要有一个比较完整的framework，身为java开发者当然就是Spring framework，相对应於blocking 的Spring MVC，Spring推出建立於Reactor之上，non-blocking的Spring WebFlux。在传统你需要concurrency，需要控制状态与synchronized，这常常会造成程序难以维护与各式各样的Bug，或是需要call api所导致thread大量的等待时间，这些问题在Reactive的WebFlux中都可以获得改善，但大致上是利用哪一种方式来改善的呢？

thread-per-request model

在传统的架构中，Spring MVC是透过thread-per-request model，也就是一个request会对应一条thread，但是request很有可会会因为call 其他服务的api、读取或写入DB等等的事情导致thread等待，也就是所谓的blocking，让珍贵的thread没事做是非常奢侈的，这边如果有写前端经验可以利用javascript来思考，在传统的javascript网页开发没有非同步的概念，读取资料时整个画面会loading无法控制，造成使用者体验很差，效率相对不好。

Event Loop

这时候使用Event Loop的模式，会有专门处理事情的thread，当request进来只是把要处理的task放入queue中，就可以释放这个thread，让worker thread一件一件的将queue里面的task处理完毕後再回传，此时就可以发现thread基本上是没有等待时间的，可以更有效的利用CPU，提高处理效能，从javascript来思考，当AJAX出现後，开发者将需要等待的任务交由AJAX完成，透过callback来取回结果，画面就不会卡住。

图片来源：baeldung

Spring WebFlux

当选择使用Spring WebFlux後，从下方的图可以看到，核心是建立於Reactor之上，有别於以往使用Tomcat，改为非阻断的Netty，Netty改用了Event Loop的方式来处理Request，对应的DB也需要有支援 Reactive，呼应到之前所说，进入到Reactive的世界後，所有相关的都需要改为Reactive。

图片来源：spring

从上面的介绍看来，是不是觉得Reactive太棒了，马上要来把负责的专案全部翻掉改成用WebFlux，或是之後的专案都选择要使用WebFlux，究竟该如何选择呢？官方有提供一些建议。

1. 如果专案使用Spring MVC已经很顺了，那就没必要改变，毕竟命令式的开发方式还是最直觉且相对单纯，而且大部分的libraries都是阻断式(blocking)的，如果你没有遇到无法处理的瓶颈就没必要大刀阔斧的改变。
2. 一个简单的判断方式就是根据你的dependencies，如果你已经在使用阻断式的API (JPA、JDBC)，那Spring MVC是你最好的选择。
3. 如果是一个小型的专案或是一个没有太复杂需求的微服务，这时候可以选择轻量化、funtional的 Spring WebFlux。
4. 小孩子才做选择，在微服务的架构中，是可以同时选择 Spring MVC 或是 Spring WebFlux (不是同一个专案)。
5. 如果你是在一个大型的团队，请记住Reactive (宣告式、functional、非阻断式)开发方式的学习曲线是相对高的，建议是先了解Reactive的好处以及影响。
6. 如果是Gateways、edge service，流量相对大的服务，常常是效能瓶颈的服务，这时候就可以考虑改用Spring WebFlux。
   

   图片来源：spring

Spring WebFlux提供两种模式，一种是我们熟悉的annotation base，让你更容易的从Spring MVC转换过来，另一种则是Function Endpoint，尽量的做到Functional Programming。

结语

今天先简单的认识WebFlux，主要说明了WebFlux产生的原因以及解决了什麽样问题，後续会接着介绍实际上是如何使用。

资料来源