共计 3119 个字符，预计需要花费 8 分钟才能阅读完成。
一、前言
- 响应式编程是啥？
- 为啥要有响应式编程？
- 响应式流的外围机制是什么？
- 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 响应式宣言
响应式宣言是一份构建古代云扩大架构的处方。这个框架次要应用音讯驱动的办法来构建零碎，在模式上能够达到弹性和韧性，最初能够产生响应性的价值。所谓弹性和韧性，艰深来说就像是橡皮筋，弹性是指橡皮筋能够拉长，而韧性指在拉长后能够缩回原样。
- 响应性 :：只有有可能，零碎就会及时地做出响应。即时响应是可用性和实用性的基石，而更加重要的是，即时响应意味着能够疾速地检测到问题并且无效地对其进行解决。即时响应的零碎专一于提供疾速而统一的响应工夫，确立牢靠的反馈下限，以提供统一的服务质量。这种统一的行为转而将简化错误处理、建设最终用户的信赖并促使用户与零碎作进一步的互动。
- 韧性 ：零碎在呈现失败时仍然放弃即时响应性。这不仅实用于高可用的、工作要害型零碎——任何不具备回弹性的零碎都将会在产生失败之后失落即时响应性。回弹性是通过复制、遏制、隔离以及委托来实现的。失败的扩散被遏制在了每个组件外部，与其余组件互相隔离，从而确保零碎某局部的失败不会危及整个零碎，并能独立复原。每个组件的复原都被委托给了另一个（内部的）组件，此外，在必要时能够通过复制来保障高可用性。（因而）组件的客户端不再承当组件失败的解决。
- 弹性 ：零碎在一直变动的工作负载之下仍然放弃即时响应性。反应式零碎能够对输出（负载）的速率变动做出反馈，比方通过减少或者缩小被调配用于服务这些输出（负载）的资源。这意味着设计上并没有争用点和地方瓶颈，得以进行组件的分片或者复制，并在它们之间散布输出（负载）。通过提供相干的实时性能指标，反应式零碎能反对预测式以及反应式的伸缩算法。这些零碎能够在惯例的硬件以及软件平台上实现老本高效的弹性。
- 音讯驱动 ：反应式零碎依赖异步的消息传递，从而确保了松耦合、隔离、地位通明的组件之间有着明确边界。这一边界还提供了将失败作为音讯委托进来的伎俩。应用显式的消息传递，能够通过在零碎中塑造并监督音讯流队列，并在必要时利用回压，从而实现负载治理、弹性以及流量管制。应用地位通明的消息传递作为通信的伎俩，得跨集群或者在单个主机中应用雷同的构造成分和语义来治理失败成为了可能。非阻塞的通信使得接收者能够只在流动时才耗费资源，从而缩小零碎开销。
问题：音讯驱动与下面提到的事件驱动有啥区别呢？
响应式宣言指出了两者的区别：“音讯驱动”中音讯数据被送往明确的目标地址，有固定导向；“事件驱动”是事件向达到某个给定状态的组件收回的信号，没有固定导向，只有被察看的数据。
- 在一个音讯驱动零碎中，可寻址的接收者期待音讯的到来而后响应音讯，否则放弃休眠状态，音讯驱动零碎专一于可寻址的接收者。响应式零碎更加关注分布式系统的通信和合作以达到解耦、异步的个性，满足零碎的弹性和容错性，所以响应式零碎更偏向于应用音讯驱动模式。
- 在一个事件驱动零碎中，告诉的监听者被绑定到音讯源上。这样当音讯被收回时，它就会被调用，所以，响应式编程更偏向于事件驱动。
下一篇老周会来说下响应式流的外围机制是什么？敬请期待~
