好处和不足
好处：
Reactive 是异步非阻塞编程
能实现通过较少的线程处理并发，大大提升程序性能。
Reactive 解决传统编程模型遇到的困境
对于阻塞，可以通过 Callbacks和Futures解决 ；但Callbacks会产生回调地狱问题(callback hell)；Futures 相对于 Callbacks 好一点，不过还是无法组合，不过 CompletableFuture 能够提升这方面的不足
不足：
没有异步的JDBC api
Java先前大多提供的是同步阻塞库或规范，没有golang类似的官方支持的协程。不过这些都在改善提高中，例如openJDK中的Loom项目就计划实现协程功能，而阿里巴巴的Wisp协程技术已经在阿里生产环境中使用，这两个(Loom和Wisp)未来可能会合并成一个项目。异步JDBC在两年之内应该可以发布。
思维方式改变，带来开发的难度
使用场景
RxJava多用于android
《Reactive Programming with RxJava》所给出的使用场景说明：
When You Need Reactive Programming
Reactive programming is useful in scenarios such as the following:
- Processing user events such as mouse movement and clicks, keyboard typing,GPS signals changing over time as users move with their device, device gyroscope signals, touch events, and so on.
- Responding to and processing any and all latency-bound IO events from disk or network, given that IO is inherently asynchronous ...
- Handling events or data pushed at an application by a producer it cannot control ...
webflux：响应式Spring Data支持的数据库
各个数据库都开始陆续推出异步驱动，目前Spring Data支持的可以进行响应式数据访问的数据库有MongoDB、Redis、Apache Cassandra和CouchDB。今天我们用MongoDB来写一个响应式demo。
webflux：网关api
api网关作为反向代理，对外部系统提供统一的服务访问入口，对请求进行鉴权限流等访问控制处理，通过后将请求路由转发给后端服务。在高并发和潜在的高延迟场景下，api网关要实现高性能高吞吐量的一个基本要求是全链路异步，不要阻塞线程。
2016年以前，spring cloud zuul网关采用同步阻塞模式不符合要求。Zuul 1本质上一个web servlet应用，因此是多线程的、阻塞的，也就是说对每一个Http连接都会用一个单独的线程来处理。在Zuul 1中，对于IO操作，会再用一个工作线程来执行，工作线程中的IO操作执行完成后会通知处理请求的线程，操作完成前，后者是阻塞的。Zuul 2对API网关的异步化改造。
协程实现
编写高性能api网关也可采用协程，当有阻塞时，阻塞在协程上而不是阻塞在线程上。和线程相比，协程是很轻量级的资源，在一个线程中可有几千个协程，协程的调度在用户级，调度开销也比线程小得多，所以采用协程也能实现网络io或io密集型系统的高吞吐量。
参考
学习 Promise （结合 Rxjava） - CSDN博客
基于spring webflux的高性能rest api网关 - 不求大道出迷途，纵负贤才岂丈夫 - ITeye博客
Reactive Programming 带来哪些显著的编程变化 - 简书
有疑问加站长微信联系（非本文作者）
