专访阿里雷卷：为什么 Reactive 会突然受到了关注？-InfoQ

从 SOA 到微服务架构，再到中台，服务的粒度越来越小，服务的数量越来越多。于是，一直不温不火的 Reactive 再次走入了人们的视线，服务之间的通讯也成为了大家关注的焦点。在 ArchSummit 全球架构师峰会（北京站）的现场，InfoQ 采访到了 Reactive 基金会的初创成员、 RSocket 开发者陈立兵（花名雷卷），听他分享 Reactive 和服务通讯协议的最新发展。

Reactive 基金会的初创成员、 RSocket 开发者陈立兵（花名雷卷）

Reactive 为何突然翻红？

Reactive 不是一个新事物，在其发展历程中，有几个比较关键的节点：

2011 年 6 月，微软推出的 .Net 3.5 内置了 Reactive Extensions 特性；
2013 年 2 月，RxJava 0.1 版本发布；
2014 年 9 月，Reactive Manifesto 发表；
2015 年 2 月，Reactive Streams 出现；
2018 年 6 月，RxJava 2.X 版本和 Reactor 3.X 版本发布；
2019 年 9 月，Reactive Foundation 成立；

…

为什么在当前这个时间节点，Reactive 会突然翻红呢？雷卷认为这与新技术的发展是密切相关的，同时他也点名了三种与 Reactive 发展相关的三种技术，微服务、云计算和 DDD。

Reactive 与微服务

随着业务的快速发展、业务复杂度越来越高，传统单体应用逐渐暴露出了一些问题，例如开发效率低、可维护性差、架构扩展性差、部署不灵活、健壮性差等等。而微服务架构是将单个服务拆分成一系列小服务，且这些小服务都拥有独立的进程，彼此独立，很好地解决了传统单体应用的上述问题，因此受到了业内的重视和推崇。

但是落地微服务架构就必须解决服务之间的通讯问题。传统的通讯方式是 RPC 调用，但是服务与服务之间通讯不只有 RPC，有些服务可能负责消费数据，有些可能负责数据采集或生成，有时服务之间的通讯是相互且对等的，服务的角色在分工细化之后，就需要一个更全面的通讯协议。

Reactive 与云计算

我们常说：“现在大家讨论的已经不再是要不要上云的问题，而是上哪朵云、怎么上的问题了。”企业上云已经是大势所趋，但是上云之后，大家首先会关心的就是成本问题。

上云之前，企业一般是在年初的时候就做好一年的规划，购买足够多的机器，所以对于机器的利用率不是特别关心，只要保证不超出预算就可以。但是上云之后，机器利用率的高低直接关乎着每个月的 IT 费用，所以大家都想着利用率能不能高点、再高点，费用能不能省点，再省点。

而异步就是提升机器利用率最好的方法之一，因此云计算的发展也推动了 Reactive 的发展。

Reactive 与 DDD

领域驱动设计（DDD）是一个开放的软件设计方法论，从 Eric Evans 出版《领域驱动设计》之后，DDD 一直是业内推崇的设计方法学，其划分服务的 Bounded Context 理念已经被微服务设计所接受。但是在各个 Context 之间如何通讯，DDD 推荐的做法是基于消息/事件的理念，但是具体使用什么样的技术、什么样的协议等等，这些都没有明确，可以说是一个宽泛的概念。

2014 年，Dean Wampler 提出：“DDD 是针对设计诞生的，关于实现使用了更多抽象概念，也就是没有明确如何实现，也许 DDD 以一种非 OOP 方式也许更好，Reactive 方式很合适 DDD 实现。”

DDD + Reactive 的结合，就很好地解决了 Context 之间如何相互通讯的问题，将抽象的概念能够以非常直观方式进行实现，这个也是 DDD 倡导的从问题域到实现域一整套解决思路。

RSocket 是什么？

新技术的发展使得异步化、协程、Reactive 等重新走红，但是在具体微服务应用落地过程中，大家发现会遇到一个很大的难题，服务与服务之间的通讯变得非常复杂，而目前并没有一个功能全面的标准协议，大家都是在做各种协议的适配和组合。

于是，RSocket 应运而生了。RSocket 是一个二进制的异步消息通讯协议，由 Facebook、Netifi 和 Pivotal 等工程师联合开发，基于 Reactive Streams 规范具有异步、背压支持、多路复用、基于消息通讯、可扩展等特性，同时提供了 Java、JavaScript、Python、C ++、Golang、Rust 各种语言 SDK 实现，方便应用快速接入 RSocket 协议。

为什么需要 RSocket?

很多人都会好奇为什么我们会需要一个新的通讯协议？“原因很简单，因为原来的通讯协议功能不够丰富和高效。” 雷卷表示：“现有的通讯协议基本都是解决特定领域的问题，并不能囊括所有通讯方式。”

目前最常见的应用间通讯协议是 RPC 和 HTTP REST API。这两者对于 request/response 的通讯完全没有问题，但是针对新的架构设计，比如 Streaming、Event Driven、IoT 和双向通讯，就有点力不从心。

而 RSocket 通讯协议可以覆盖四种通讯方式，而这四种方式几乎覆盖了所有的通讯模式。

Request/Response 模型：通俗来说，就是发出去一个请求，就必须等到一个响应，是目前使用比较广泛的通讯模型；
Request/Stream 模型: 通俗来说，就是单个请求可以接收多个响应，常见的使用场景包括获取视频列表、获取目录中的产品等等。
Fire-and-Forget 模型：通俗来说，就是单向请求，不接收响应，发出去就不要了。
Channel(Bi-direction)模型：提供双向通信，信息流在两个方向上异步流动。通俗来说，就是可以发出多个请求，并接收多个响应。

“RSocket 协议从根本上解决各种通讯问题，适配了新的技术发展。”雷卷表示：“以前的通讯协议能解决特定领域的问题就可以了，是很薄的一层。而实际的通讯是复杂的，一个设计很好的协议，可以从根本上满足不同应用之间通讯需求，解决应用之间互联互通的问题，而不是当前各种协议相互转换和适配，增加架构的复杂度。”

多语言支持

除了架构、性能等问题，开发语言支持也是开发者很关心的问题。据雷卷介绍，目前 RSocket 支持的编程语言包括 Java(Kotlin)、 Javascript(Browser & Node)、 C++、Python、Golang、.Net、Ruby、Rust 等，同时 Dart、Swift 的支持也在规划和开发当中了。

Reactive 的目的之一就是支持异步化，而不少语言都包括了对异步化的支持，另外不同的编程语言有不同的特性，那么如何让 RSocket 在各个语言 SDK 实现更符合该语言的开发习惯呢？雷卷表示：“在做 SDK 的时候，我们坚持的一个原则是 Language-Native，即一种编程语言的 SDK 必须要符合该种编程语言的习惯和规范。例如，Go 语言 SDK 会使用 goroutinue、Python SDK 中会使用 asyncio。”

总的来说，RSocket 在开发 SDK 时通常会有两个：一个是 Reactive 的 API，一个是 Language Native 的 API，开发者可以根据自己的开发习惯选择对应的 API。

RSocket 落地产品

前面讲的这么热闹，有没有已经落地的 RSocket 产品呢？实话说，目前落地的产品很少，虽然 Spring Framework 内置了对 RSocket 的支持，但目前商业产品也就只有 Netifi Broker。不过，阿里巴巴刚刚开源了一款基于 RSocket 协议的中间件产品——Alibaba RSocket Broker。