在开始讨论响应式编程（Reactive Programming）之前，先来看一个我们经常使用的一款堪称“响应式典范”的强大的生产力工具——电子表格。
举个简单的例子，某电商网站正在搞促销活动，任何单品都可以参加“满199减40”的活动，而且“满500包邮”。吃货小明有选择障碍（当然主要原因还是一个字：穷），他有个习惯，就是先在Excel上根据预算算好自己要买的东西：
相信大家都用过Excel中的公式，这是一个统计购物车商品和订单应付金额的表格，其中涉及到一些公式：
上图中蓝色的线是公式的引用关系，从中可以看出，“商品金额”是通过“单价x数量”得到的，“满199减40”会判断该商品金额是否满199并根据情况减掉40，右侧“订单总金额”是“满199减40”这一列的和，“邮费”会根据订单总金额计算，“最终应付款”就是订单总金额加上邮费。
为什么说电子表格软件是“响应式典范”呢，因为“单价”和“数量”的任何变动，都会被引用（“监听”）它的单元格实时更新计算结果，如果还有图表或数据透视图引用了这块数据，那么也会相应变化，做到了实时响应。变化的时候甚至还有动画效果，用户体验一级棒！
这是响应式的核心特点之一：变化传递（propagation of change）。一个单元格变化之后，会像多米诺骨牌一样，导致直接和间接引用它的其他单元格均发生相应变化。
这里我们说的是一种生产者只负责生成并发出数据/事件，消费者来监听并负责定义如何处理数据/事件的变化传递方式。
这些数据/事件在响应式编程里会以数据流的形式发出。
我们再观察一下购物车，这里有若干商品，小明每次往购物车里添加或移除一种商品，或调整商品的购买数量，这种事件都会像过电一样流过这由公式串起来的多米诺骨牌一次。这一次一次的操作事件连起来就是一串数据流（data stream），如果我们能够及时对数据流的每一个事件做出响应，会有效提高系统的响应水平。这是响应式的另一个核心特点：基于数据流（data stream）。
如下图是小明选购商品的过程，为了既不超预算，又能省邮费，有时加有时减：
这是一种**“声明式（declarative）”**的编程范式。通过四个串起来的map调用，我们先声明好了对于数据流“将会”进行什么样的处理，当有数据流过来时，就会按照声明好的处理流程逐个进行处理。
比如对于第一个map操作：
**声明式编程范式的威力在于以不变应万变。**无论到来的元素是什么，计算逻辑是不变的，从而形成了一种对计算逻辑的“绑定”。
总结来说，命令式是面向过程的，声明式是面向结构的。
不过命令式和声明式本身并无高低之分，只是声明式比较适合基于流的处理方式。这是响应式的第三个核心特点：声明式（declarative）。结合“变化传递”的特点，声明式能够让基于数据流的开发更加友好。
总结起来，响应式编程（reactive programming）是一种基于数据流（data stream）和变化传递（propagation of change）的声明式（declarative）的编程范式。
响应式编程的“变化传递”就相当于果汁流水线的管道；在入口放进橙子，出来的就是橙汁；放西瓜，出来的就是西瓜汁，橙子和西瓜、以及机器中的果肉果汁以及残渣等，都是流动的“数据流”；管道的图纸是用“声明式”的语言表示的。
这种编程范式如何让Web应用更加“reactive”呢？
我们设想这样一种场景，我们从底层数据库驱动，经过持久层、服务层、MVC层中的model，到用户的前端界面的元素，全部都采用声明式的编程范式，从而搭建一条能够传递变化的管道，这样我们只要更新一下数据库中的数据，用户的界面上就相应的发生变化，岂不美哉？尤其重要的是，一处发生变化，我们不需要各种命令式的调用来传递这种变化，而是由搭建好的“流水线”自动传递。
这种场景用在哪呢？比如一个日志监控系统，我们的前端页面将不再需要通过“命令式”的轮询的方式不断向服务器请求数据然后进行更新，而是在建立好通道之后，数据流从系统源源不断流向页面，从而展现实时的指标变化曲线；再比如一个社交平台，朋友的动态、点赞和留言不是手动刷出来的，而是当后台数据变化的时候自动体现到界面上的。
转：https://blog.51cto.com/liukang/2090170
原文地址：https://www.cnblogs.com/duanxz/p/14958734.html
