Reactive(1) 从响应式编程到"好莱坞"

概念

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协商了。

Java 9 平台开始支持 Reactive Stream API

关于Reactive Stream 规范的定义可以参考这篇翻译:
https://github.com/yelf2000/rxjava/wiki/Reative-Streams-%E8%A7%84%E8%8C%83

为什么要使用Reactive

回答这个问题并不容易,一定是要从 Reactive 编程中获得一定好处了之后才能解答,当然不同人的看法也不一样。
就笔者浅显的看法来说,Reactive响应式编程提出了一种更高级的抽象,将数据的处理方式沉淀到可复用的库之后可以提高开发的效率。

实质上, Reactive响应式始终是一种模式,只是在不同的框架体系中产生了各种五花八门的说法,导致初学者非常容易迷路。
光是Java语言中的 RxJava、Reactor、Java 9 这些不同类库的接口概念就有不少差异,更不用说跨语言了。

对此,下面的这篇文章有比较详细的解读,值得一看:

https://yq.aliyun.com/articles/617709

参考文档

极客学院译文-响应式编程介绍
https://wiki.jikexueyuan.com/project/android-weekly/issue-145/introduction-to-RP.html

Java 平台 Reactive编程
https://cloud.tencent.com/developer/article/1073888

the-hollywood-principle(好莱坞原则)
https://dzone.com/articles/the-hollywood-principle

维基百科- Reactive Programing
https://en.wikipedia.org/wiki/Reactive_programming

posted @ 2019-08-21 00:57  美码师  阅读(...)  评论(... 编辑 收藏