从React 编程到"好莱坞"

华为云开发者联盟

墨衍会员 · AI 创作全网分发码龄10年

关注

原创 2019-08-27 15:29:54 2.4k 阅读 AI 写同款· GEO 优化 ›

概念

Reactive Programming(响应式编程)已经不是一个新东西了。
关于 Reactive 其实是一个泛化的概念，由于很抽象，一些理论性的介绍很容易把人带到沟里去，包括一些语言框架在实现上也会使用不同的一些概念。

按照维基百科的解释：

reactive programming is a declarative programming paradigm concerned with data streams and the propagation of change

意思就是，Reactive Programming 就是一种面向数据流、关注变更的声明式编程范式。
面向数据流比较容易理解，而关注变更则说的应该是数据流的特点，比如来自某个界面元素属性的变更(前端领域)、又或是某个后端实体的更新事件(日志)..

以下面的这个函数为例：

c = a + b;

这里定义了变量c 是变量a、变量b 之和，当a=1,b=2时，c的值就是3。
假设我们在程序中执行了这个语句，那么对于一次执行过程所产生的c的值就是确定的(上下文中的a、b变量也是确定的)
但是，如果a、b的值是不确定的呢？即这个语句仅仅是定义了变量c与变量a、b 的计算关系，那么c 的值就是可变的！

如下：

a=1,b=1,c=2
a=2,b=2,c=4
a=3,b=2,c=5
...

简言之，c需要动态的由 a、b 共同来决定：
当 a、b 的值发生变化时，c 的结果要能及时的做出响应(或者叫反应)，以此来保证正确性。

这应该就是 Reactive(响应式) 的由来了，由于变量 a、b的值可能会不断的变化，于是会形成持续不断的变更事件，也就是事件流，因此 Reactive 是面向流式处理来设计的。
此外，在处理这种"变更的流"时，通常是由异步通知的方式来完成，因此异步化也是其特征之一。

从现有的一些Reactive框架来看，关于下面的定义则更加的贴切：

Reactive编程是面向数据流的、异步化的编程范式

图-Reactive-Proactive

与Reactive 相对的是Proactive ，后者是一种同步的、轮询式的处理方式

面向流设计

首先，有别于面向对象编程的思想，在Reactive 范式里面，所有的东西都可以当做流，即 Everything is Stream。
流(Stream) 被作为响应式编程的基本元素，这和其他的编程范式非常类似：

面向对象设计，基本单位是对象
面向函数设计，基本单位就是函数
响应式设计，基本单位就是流..

那么流是什么样的东西呢？

可以是用户输入、数据结构、缓存、动态变量... 等等！
可以来自静态的数据集合，或是动态的事件流。

案例：MVC

MVC(Model-View-Controller) 是前端设计的标准，这也是用来说明"面向流"的一个很好的例子。

图-MVC

其中，来自于用户的点击操作，会被转换为各种事件传递给 Controller 进行处理。
在这里，我们可以认为这些持续不断的事件形成了"事件流"。比如一个按钮的点击事件流如下图：

在这里，事件流是按时间排序进行处理的。但你可能会说，这不就是简单的一个事件处理机制嘛?
别着急，基于响应式流可以做更多的事情，如下图：

上图的每个灰框代表了一个处理方法：

buffer(stream.throttle(250ms))，buffer就是缓冲，而throttle 是节流。
这个函数的意思就是对流进行缓冲处理，将250毫秒范围内发生的事件合并到一起。
map('length of list')，将合并后的列表进行转换，输出为每个列表的长度
filter(x>=2)，即按照>=2的条件进行过滤。

当然，使用传统的编程方式也完全可以实现这些逻辑，只是相比之下基于响应式流的处理会更加的优雅，所用代码也会更少。

上面的这个例子出自于《The introduction to Reactive Programming you've been missing》(英文原文：https://gist.github.com/staltz/868e7e9bc2a7b8c1f754)，该文章也获得非常多的star，至少有一部分可以说明基于MVC的例子来理解响应式还是比较容易的。当然，除了前端领域之外，也很容易将响应式流的思想扩展到各个方面，包括 Web后端、大数据处理、实时流计算等等。

异步化

异步化处理是响应式编程的另一个重要特征，这里的异步与我们常说的网络IO异步化意思上是相同的，与异步相对的概念是同步。

下面的案例可以很好的解释两者的区别：


假设你是一个读书爱好者，某一天你想看《开国大典》这本书，于是你打电话给图书馆的管理员，询问馆内是否有这本书可以借。

同步的方式，管理员在接到电话之后让你等一下，然后去图书室查找一番，几分钟后回来再拿起电话告诉你结果；
异步的方式，管理员把你的电话号码记下来，然后挂掉电话，后面他查找完了再打回电话给你通知结果。

同步和异步的区别就在于结果通知的方式不同，很明显，异步的方式会显得更加的人性化和高效。
因此，响应式编程通常是采用异步回调的方式，回调方法的调用和控制则会由响应式框架来完成，对于应用开发来说只需要关注回调方法的实现就可以了。

关于同步、异步，往往会牵扯到阻塞、非阻塞这两个相似的概念，需注意的是后者的侧重点不同：
阻塞、非阻塞所关注的是调用者的状态(是否可以停下来做其他事情)的区别

既然谈到了异步，这里提一个著名的设计原则：好莱坞原则(Hollywood principle)

don't call us, we'll call you
不要给我们打电话，我们会给你打电话

在好莱坞，把简历递交给演艺公司后就只有回家等待。由于演艺公司对整个娱乐圈是完全控制的，演员只能被动式的接受公司的差使，只能在需要的环节中完成自己的演出。

好莱坞原则的核心是以通知代替轮询，其强调的是使用回调来降低模块间的依赖关系，或是提升消息处理效率。

与好莱坞原则相关(延伸)的设计模式有许多：

Spring 的依赖注入(DI)，通过将Bean的定义、依赖关系配置到XML文件中，由容器来完成Bean的自动装配。
这样控制权就从具体的 Bean转移到到了容器手上，于是就有了控制反转IoC(Inversion of Control)一词。
Swing UI框架中大肆使用的观察者模式(Observer), 我们希望获知某个UI组件的事件变化，可以添加一个ActionListener。
之后Swing将会自动将发生的事件传递到我们的回调方法上(actionPerformed)。
Reactor 响应器模式，基于事件驱动的一种设计模式，其设定了Service Handler负责派发事件，Service Handler同步获得输入的事件后，进而分发给相应的Request Handler(多路复用)
Reactor 一般是用于NIO的场景，如Netty 的网络处理模型：

注意到了吗？这些设计模式都不约而同使用了回调！，当然在Reactive 范式中也必然离不开这点。

或许，100 种设计模式中，调整一下角度，可以归纳为10种甚至更少。

响应式宣言

https://www.reactivemanifesto.org/

除了上述的两大特征之外，还需要提到的一个东西叫 Reactive Manifesto(响应式宣言)，这个是由Lightbend 公司发起的。它的前身是Typesafe，大名鼎鼎的Scala 就是其发明的。还有流行的Web后端框架 Playframework 也出自于此。

Playframework 的底层是基于Scala的(可同时支持Java和Scala开发)，同时也包含了NIO、Reactive的各种特性，不少国外的企业如Linkin、Verizon 都在使用。

于是，有了响应式宣言之后，Reactive开始得到了正名，随后的Akka、Rx系列、包括Spring生态都纷纷加入了这个队列。

在这个宣言里面，对于响应式的系统特征定义了四个特性：

及时响应(Responsive)：系统能及时的响应请求。
有韧性(Resilient)：系统在出现异常时仍然可以响应，即支持容错。
有弹性(Elastic)：在不同的负载下，系统可弹性伸缩来保证运行。
消息驱动(Message Driven)：不同组件之间使用异步消息传递来进行交互，并确保松耦合及相互隔离。

在响应式宣言的所定义的这些系统特征中，无一不与响应式的流有若干的关系，于是乎就有了 2013年发起的 响应式流规范(Reactive Stream Specification)。

https://www.reactive-streams.org/

其中，对于响应式流的处理环节又做了如下定义：

具有处理无限数量的元素的能力，即允许流永不结束
按序处理
异步地传递元素
实现非阻塞的负压(back-pressure)

负压这个概念或许有些陌生，但本质是为了协调流的处理能力提出的，对于流处理来说会分为 Publisher(发布者) 和Subscriber(订阅者)两个角色，可看做生产者与消费者的模式。当发布者产生的消息过快时，订阅者的处理速度可能会跟不上，此时可能会导致一系列的系统问题。因此负压的目的就是定义一种反馈机制，让订阅者(消费方)向发布者告知其自身的状态(包括处理速度)，
尽可能让发布方作出调整，本质上是一种系统自我保护的手段。说到这里，不得不想到TCP的 MTU协商了。