剖析响应式编程的本质

基于Actor的响应式编程计划分为三部分，第一部分剖析响应式编程的本质思想，为大家介绍何谓响应式编程（Reactive Programming）。第二部分则结合两个案例来讲解如何在AKKA中实现响应式编程。第三部分则是这个主题的扩展，在介绍Reactive Manifesto的同时，介绍进行响应式编程更为主流的ReactiveX框架。

响应式编程（Reactive Programming）到底是什么？从名词定义来讲，中文的响应式并没有很好地展现Reactive的本意。响应这个词语是一个中性词，本身没有任何倾向。Reactive Programming强调的是“响应迅速”，响应用户的请求要如电光火石一般迅捷，做到一触即发。

传统的顺序编程采用每条指令依次执行的方式，倘若上一条指令没有执行结束，当前的线程就得等着，任你如何提升机器性能还是代码性能，如果本质不变，始终改变不了响应需要等待的现实。若要响应迅速，就得把顺序执行指令的方式换一换——同步换成异步，方法执行换做消息发送，于是乎，我们可以精简地定义：

响应式编程就是异步数据流编程。

这其实是一种编程范式，是编程理念的一种思想转型。因为采用响应式编程，我们就不再将软件要处理的业务视为对象，又或者函数，而是直接透析到本质：数据流（Data Stream）。

一言以蔽之：万事万物皆为流。

我这么说，可能有些绝对。响应式编程并非银弹，也非你手中四处寻找钉子来敲打的锤子。我们须得结合着实际的场景，考虑是否选择响应式编程这种范式。然而，如果我们局限在响应式编程的语境下，我们确乎可以视万事万物为流。

从函数式编程的角度来讲，一连串组合函数的调用，其实就是数据在流动。函数可以抽象地视为一种数据类型到另一种数据类型的转换。将各种形式的转换（map、flatMap、filter）穿起来，同时保证数据的不变性（Immutable），则数据就能非常可靠地在函数链条中流动，或者被分析，或者被转换，或者被过滤。

回到业务世界。我们几乎可以将所有业务处理流程都可以建模为数据流的形式。这种流动差不多可以归纳为：

Command -> CommandHandler -> Event -> EventHandler -> Command ...

这是一种颇有节奏感的“建模仪式”。按照CQRS的设计思想，任何业务都可以分解为两种形式的消息：Query与Command。Query模型相对简单，因为它本质上就是一个没有副作用的只读操作。执行Command本身是要改变业务对象值的，然而，如果我们将每次变更都视为是一种“状态的迁移”，然后利用事件去记录每次变更，就可以将可变转换为不变。如果熟悉git，就会发现git的版本管理与此建模思想不谋而合。无论是新增、修改还是删除代码，都可以视为是一次全新的提交。

当我们将编程的范式切换为“流（Stream）”时，我们欣喜地发现，这种方式可以在很大程度上确保数据是不变的。这就为并行开发创造了可能。

然而，普通的数据流编程范式并不能满足“响应式Reactive”的本初定义。我们需要响应迅速。如何才能做到？那就是要做到没有阻塞，这就是我们通常所说的异步工作方式。

因而，响应式编程的设计原则是：

• 保持数据的不变性
• 没有共享
• 阻塞是有害的

这或许也可以视为是响应式编程的特征，恰好，这三条特征也是Actor模型拥有的。

那么，什么是Actor模型？溯源Actor模型，它由Carl Hewitt在1973年提出，之后在Erlang OTP(Open Telecom Platform)中被广泛应用在并发编程上。最初的Scala语言也实现了简单的Actor模型，但随着AKKA框架的推出，Scala放弃了自身的Actor，转而选择使用AKKA。

在《Scala并发编程》一书中，Aleksandar Prokopec形象地描述了Actor系统：

Actor系统模仿了人类的组织，如公司、政府和其他大型机构。在软件公司中，有许多需要以并发方式达成的目标。为了实现这些目标，数百或数千名员工一起努力工作，而且这些员工通常会被组织成一种层次结构。许多员工会为级别比他们低的员工分派工作。为了高效地工作和决策，员工们使用电子邮件进行通信。 当员工早上上班时，就会检查他的电子邮箱并对重要的消息做出回应。如果某封电子邮件非常重要，那么这个员工就必须立刻回复这封邮件。当员工忙着回复一封电子邮件时，可能会收到另一封电子邮件，而且后续的电子邮件都会进入他的电子邮箱中。只有当员工处理完成当前的电子邮件后，他才能继续处理下一封电子邮件。

在这个隐喻中，软件公司就相当于是一个ActorSystem，每位员工则是一个一个Actor。电子邮件是Actor之间彼此发送的消息（Message），一旦发送了消息，就不必等待收件人的回复，可以继续自己的工作，也就是说这种消息发送的方式是异步非阻塞的。Actor持有的MailBox正好借用了这里所谓的电子邮箱概念。

因而对于每个Actor而言：

• 每个Actor都拥有独立的MailBox；
• 接收到的消息皆为不可变对象，且完全独立；
• 不管是tell消息还是ask消息，Actor执行消息的方式都是异步非阻塞的。

金风玉露一相逢，从某种意义上讲，Actor模型就是响应式编程苦苦追寻的良缘佳配。二者天生匹配，且Actor模型的分布式特性还能更好地加强响应式编程的响应与处理速度。