从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。

Alibaba RSocket Broker 架构图

RSocket Broker的主要作用是桥接应用通讯的双方。

当应用启动后，会与Broker创建一个长连接，并同时表明自己的身份，如果是服务提供者，需要提交发布的服务信息， Broker会针对所有的连接和服务列表建立对应的映射关系。

当一个应用需要调用其他服务时，应用会将请求以消息的方式发给Broker，然后Broker会解析消息的元信息，然后根据路由表将请求转发给服务提供者，然后将处理结果后的消息再转发给调用方。

由于Broker是完全异步化的，且消息转发是基于Zero Copy，所以性能非常高，无需担心中心化Broker会成为性能瓶颈，我们称之为软路由的设计策略。

RSocket Broker 解决了哪些问题呢？具体来说，它解决了传统设计中的常见的以下问题：

配置推送: 通过RSocket的metadataPush可以完成应用配置推送；
服务注册和发现：应用和Broker建立连接后，这个长连接就是服务注册和发现，不需要额外的服务注册中心；
透明路由: 应用在调用服务时，不需要知道服务对应的应用信息， Broker会完成路由；
Service-to-service调用: RSocket支持服务之间通讯的4个模型；
负载均衡(Load balance): 应用和Broker建立长连接后，基于长连接的负载均衡就会变得非常简单；
Circuit Breakers: 断路保护，现在调整为被压(Back Pressure)支持，服务保护策略更自然；
分布式消息(Distributed messaging)通讯: RSocket通讯策略本来就是基于消息的；

Alibaba RSocket Broker 开源地址：https://github.com/alibaba/alibaba-rsocket-broker 欢迎大家试用并提出宝贵意见。

创作场景

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