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

阅读数:1 2020 年 1 月 6 日 11:16

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

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

专访阿里雷卷:为什么 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。

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

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 欢迎大家试用并提出宝贵意见。

评论

发布