一、前言

响应式编程是啥？

为啥要有响应式编程？

(资料图片仅供参考)

响应式流的核心机制是什么？

Spring 响应式编程能解决我们平时开发的什么痛点？

Spring 响应式编程有哪些应用场景？

Spring 响应式编程未来的趋势如何？

开篇六连问，等咱们熟悉完再来真香也不迟，我们废话少说，直接来畅游 Spring 响应式编程的世界。

二、响应式编程是啥？

在计算中，响应式编程或反应式编程（Reactive programming）是一种面向数据串流和变化传播的声明式编程范式。这意味着可以在编程语言中很方便地表达静态或动态的数据流，而相关的计算模型会自动将变化的值通过数据流进行传播。

有点抽象？没有关系，老周这就来说道说道。核心的一点响应式编程是声明式编程范式，对命令式编程进行替代的一个范例，这种替代的存在是因为响应式编程解决了命令式编程的限制。大多数开发者都是命令式编程起步的，你写的代码就是一行接一行的指令，按照它们的顺序一次一条地出现。一个任务被执行，程序就需要等到它执行完了，才能执行下一个任务。每一步，数据都需要完全获取到了才能被处理，因此它需要作为一个整体来处理。

命令式编程有个最大的弊端是：当正在执行的任务被阻塞了，特别是一个 IO 任务，例如将数据写入到数据库或从远程服务器获取数据，那么调用该任务的线程将无法做任何事情，直到任务完成。说白了，阻塞的线程就是一种浪费，在如今的环境，线程的资源是那么的宝贵。

相反，响应式编程是函数式和声明式的。响应式编程涉及描述通过该数据流的 pipeline 或 stream，而不是描述的一组按顺序执行的步骤。响应式流处理数据时只要数据是可用的就进行处理，而不是需要将数据作为一个整体进行提供。

三、为啥要有响应式编程？

我们上面也说了命令式编程会线程阻塞，而响应式编程是声明式编程范式的，是对命令式编程进行替代的一个范例。

对于命令式编程的同步阻塞，其实业界是有一些处理方案的，比如在 Java 中，为了实现异步非阻塞，一般会采用回调和 Future 这两种机制，但这两种机制都存在一定局限性。

3.1 回调机制

我们来看下面这个图：

服务 B 的 methodB() 方法调用服务 A 的 methodA() 方法，然后服务 A 的 methodA() 方法执行完毕后，再主动调用服务 B 的 callback() 方法。

回调体现的是一种双向的调用方式，实现了服务 A 和服务 B 之间的解耦。在这个 callback 回调方法中，回调的执行是由任务的结果来触发的，所以我们就可以异步来执行某项任务，从而使得调用链路不发生任何的阻塞。

回调的最大问题是复杂性，一旦在执行流程中包含了多层的异步执行和回调，那么就会形成一种嵌套结构，给代码的开发和调试带来很大的挑战。所以回调很难大规模地组合起来使用，因为很快就会导致代码难以理解和维护，从而造成所谓的“回调地狱”问题。之前公司就遇到代码“回调地狱”问题，十几层的回调，后面的人进来维护估计会吐。

3.2 Future 机制

我们再来看看 Future 这种机制，有一个需要处理的任务，然后把这个任务提交到 Future，Future 就会在一定时间内完成这个任务，而在这段时间内我们可以去做其他事情。下面我们来看看来自 Doug Lea 大神在 Java 中的 Future 接口设计：

我们可以看到，大神在上面的设计来达到一定的异步执行效果。但从本质上讲，Future 以及由 Future 所衍生出来的 CompletableFuture 等各种优化方案就是一种多线程技术。多线程假设一些线程可以共享一个 CPU，而 CPU 时间能在多个线程之间共享，这一点就引入了“上下文切换”的概念。

如果想要恢复线程，就需要涉及加载和保存寄存器等一系列计算密集型的操作。因此，大量线程之间的相互协作同样会导致资源利用效率低下。

3.3 响应式编程实现方法3.3.1 数据流与响应式

数据流就是数据像水流一样源源不断的输入过来，而系统的响应能力就体现在对这些数据流的即时响应过程上。我们可以不采用传统的同步调用方式来处理数据，而是由处于数据库上游的各层组件自动来执行事件，从web到service再到dao层，这个过程就像水流一样，整个数据传递链路都应该是采用事件驱动的方式来进行运作的，这个过程都应该是异步非阻塞的，这就是响应式编程的核心特点。

相较传统开发所普遍采用的“拉”模式，在响应式编程下，基于事件的触发和订阅机制，这就形成了一种类似“推”的工作方式。说白了，就类似现在的 Kafka 等消息引擎，大部分都采用事件驱动的 pub/sub 模式的架构。这种模式的最大优势是生成事件和消费事件的过程是异步执行的，意味着资源之间的竞争关系较少，故服务器的响应能力也就越高。

3.3.2 响应式宣言

响应式宣言是一份构建现代云扩展架构的处方。这个框架主要使用消息驱动的方法来构建系统，在形式上可以达到弹性和韧性，最后可以产生响应性的价值。所谓弹性和韧性，通俗来说就像是橡皮筋，弹性是指橡皮筋可以拉长，而韧性指在拉长后可以缩回原样。

响应性: ：只要有可能，系统就会及时地做出响应。即时响应是可用性和实用性的基石，而更加重要的是，即时响应意味着可以快速地检测到问题并且有效地对其进行处理。即时响应的系统专注于提供快速而一致的响应时间，确立可靠的反馈上限，以提供一致的服务质量。这种一致的行为转而将简化错误处理、建立最终用户的信任并促使用户与系统作进一步的互动。

韧性：系统在出现失败时依然保持即时响应性。这不仅适用于高可用的、任务关键型系统——任何不具备回弹性的系统都将会在发生失败之后丢失即时响应性。回弹性是通过复制、遏制、隔离以及委托来实现的。失败的扩散被遏制在了每个组件内部，与其他组件相互隔离，从而确保系统某部分的失败不会危及整个系统，并能独立恢复。每个组件的恢复都被委托给了另一个（外部的）组件，此外，在必要时可以通过复制来保证高可用性。（因此）组件的客户端不再承担组件失败的处理。

弹性：系统在不断变化的工作负载之下依然保持即时响应性。反应式系统可以对输入（负载）的速率变化做出反应，比如通过增加或者减少被分配用于服务这些输入（负载）的资源。这意味着设计上并没有争用点和中央瓶颈，得以进行组件的分片或者复制，并在它们之间分布输入（负载）。通过提供相关的实时性能指标，反应式系统能支持预测式以及反应式的伸缩算法。这些系统可以在常规的硬件以及软件平台上实现成本高效的弹性。

消息驱动：反应式系统依赖异步的消息传递，从而确保了松耦合、隔离、位置透明的组件之间有着明确边界。这一边界还提供了将失败作为消息委托出去的手段。使用显式的消息传递，可以通过在系统中塑造并监视消息流队列，并在必要时应用回压，从而实现负载管理、 弹性以及流量控制。使用位置透明的消息传递作为通信的手段， 得跨集群或者在单个主机中使用相同的结构成分和语义来管理失败成为了可能。非阻塞的通信使得接收者可以只在活动时才消耗资源，从而减少系统开销。

问题：消息驱动与上面提到的事件驱动有啥区别呢？

响应式宣言指出了两者的区别：“消息驱动”中消息数据被送往明确的目的地址，有固定导向；“事件驱动”是事件向达到某个给定状态的组件发出的信号，没有固定导向，只有被观察的数据。

在一个消息驱动系统中，可寻址的接收者等待消息的到来然后响应消息，否则保持休眠状态，消息驱动系统专注于可寻址的接收者。响应式系统更加关注分布式系统的通信和协作以达到解耦、异步的特性，满足系统的弹性和容错性，所以响应式系统更倾向于使用消息驱动模式。

在一个事件驱动系统中，通知的监听者被绑定到消息源上。这样当消息被发出时，它就会被调用，所以，响应式编程更倾向于事件驱动。

下一篇老周会来说下响应式流的核心机制是什么？敬请期待~

---

欢迎大家关注我的公众号【老周聊架构】，Java后端主流技术栈的原理、源码分析、架构以及各种互联网高并发、高性能、高可用的解决方案。