1 四种通讯模式
即发即忘FireAndForget
立即发送一个请求,无需为这个请求发送响应报文。适用于监控埋点,日志上报等,这种场景下无需回执,丢失几个请求无伤大雅。
请求响应RequestResponse
请求方发送一条请求消息,响应方收到请求后并返回一条响应消息。传统的HTTP是典型的RequestResponse。
流RequestStream
请求方发送一个请求报文,响应方发回N个响应报文。传统的MQ是典型的RequestStream。
通道RequestChannel
创建一个通道上下文,双方可以互相发送消息。IM是个典型的RequestChannel通讯场景。
2 双向通讯Bi-Directional
RSocket的Client连接到Server,这个过程称为Setup,在连接成功后,会约定收发消息的方向逻辑:
- 当Client请求Server时,发送的请求ID永远为奇数
- 当Server请求Client时,发送的请求ID永远为偶数
正是因为这个奇偶性确定方向的特性,不同于传统的如HTTP请求,RSocket可以做到双向请求。
3 其他
- 二进制协议,紧凑高效
- 多路复用
- 基于帧(Frame)的背压,与ReactiveStreams语义契合
- 灵活的传输层切换: TCP/UDP/WebSocket等
- 支持Cancel、断点续传、租约等高级特性
综上与HTTP做一些比较,RSocket的效率更高,支持的通讯场景更丰富,也没有队头阻塞的问题。与SocketIO这种基于纯事件的框架相比,RSocket的请求具有很清晰的上下文,API精炼易用。
二 RSocket的内部实现
1 帧的设计
帧(Frame)是RSocket协议报文的最小单位。
- 一个帧由6 bytes的Header和剩余的Body构成,其中Header的4 bytes表示 StreamID,6 bits表示Frame Type, 10 bits作为Flags。Body根据不同的帧类型,结构也不同,常用的带Payload的帧一般会包括Metadata和Data两个部分。
- 传输层如果本身不支持分帧特性的(如TCP),那么RSocket会用3 bytes的uint24表示帧长度,所以最大的帧大小是16MB。
- 如果帧超出16MB,RSocket支持帧分裂重组,也就是拆成更小的帧,接收端再自动重组。
2 数据载体——Payload
基于帧之上,一般开发者接触到的是Payload, 它类似一个HTTP报文,可以是一个Request,也可以是一个Response。由两个二进制部分组成:
- Metadata——元数据,类似HTTP的header
- Data——数据,类似HTTP的body
3 架构
这里基于笔者在实现Golang版SDK的基础上整理的架构图,Java版基本也类似。
- Transport层将网络二进制流编解码为Frames。
- RSocket支持自定义最大Frame Size,默认16MB,当某个Frame超出时,会被拆解为N个小Frame,收到时再重组,在介绍帧的时候也提到了,这个特性称为Fragmentation。
- DuplexConnection转换Frames为Payload,抽象为一个个Request/Response上下文,并负责读写。
- RSocket组装Connection为RSocket Interface,其中Resumable支持断点续传,连接断开重连也能自愈,个人觉得这个特性有点鸡肋,在弱网环境有些优势,但是因为期间会缓存住未处理完毕的帧,所以会耗费大量的系统资源。
- RSocket使用Reactor核心库暴露为4种通讯模式,抽象为高级API。
4 玩法
RSocket有很多玩法,传统的RPC自然不在话下,用来做IM也未尝不可,某些特性也可以用来做代理或者网络穿透。
IoT的场景,比如小明的家里有个智能空调,小明想在外面通过手机APP来控制空调开关,如何优雅地描述这个控制问题?最精炼的解决方案就是"小明调用空调上开关的API"。
另外最经典的玩法就是Broker了,Broker类似一种“软路由”的方案,可以让服务的发布访问变得简单。发布服务只要连接到Broker,调用方通过反向请求的方式来让Broker透明转发即可,摒弃了传统的注册中心,端口管理等常见的服务治理手段。
5 关于RSocket Broker
Broker有很多优势,发布服务不需要监听端口,无需Sidecar,服务注册变得简单,无需zk、etcd之类,LoadBalance变得简单,也更安全,没监听端口后很难攻击。也有很多劣势,网络上多了一跳,性能是有一定损耗的,Broker是中心化设计,类似我们平时全局的Nginx一样,但是Broker的优雅启停显然更加复杂,受限于整个Broker集群的瓶颈等等。上帝为你关闭了一扇门,就一定会为你打开一扇窗。
目前高德落地的FaaS中大量使用了基于RSocket架构的集团Broker,支撑了今年的五一长假,峰值QPS超20万,平稳零故障。
这里笔者也准备了一个教学用的Mini Broker,演示了两个浏览器之间相互上下文调用彼此服务的场景,有兴趣的同学可以查看。
三 响应式编程
响应式编程是个老话题了,它早已无处不在,甚至你在Excel里SUM求和,本质上也是种响应式的思维。响应式本质上就是响应变化的数据流。RSocket这个协议本身就是以响应式之名,将其扩展到网络层面。
1 响应式编程大概长这样
而在我们平时工作中,必然会引入各种操作和变换:
2 Reactive Streams
JDK推出了响应式标准API,撇开Processor之外,其核心接口就Publisher/Subscriber/Subscription,非常精炼。
- Publisher:发布者,负责生产数据。唯一的方法subscribe,接收一个Subscriber开始一次新的订阅。
- Subscriber:订阅者,负责订阅消费数据。
- Subscription:订阅,某次订阅的上下文控制,如取消、通知获取下N条数据。
Spring的Reactor是一个标准的实现,其一次完整的执行过程如下图:
- 创建subscriber,开始订阅Publisher。
- 生成上下文subscription。
- Publisher就绪,调用onSubscribe。
- Publisher开始生产数据。
- 每条成功生产的数据回调onNext。
- 当生产失败时,回调onError并结束当前订阅。
- 当所有数据生产完毕时,回调onComplete并结束当前订阅。
- 中途可以调用subscription随时cancel取消订阅,或者通过request(n)通知生产下N个元素,这个过程即背压。
由于Java天生的语言优势,很适合使用RxJava或Reactor之类的框架,代码逻辑清晰可读性会非常高。笔者在实现Go版的Reactor时,深深地体会到了没有泛型支持的API表现力是多么匮乏,也期待Go2的泛型能够有所改善。
四 总结
RSocket是个很有趣的网络协议,它可能不会普及流行,但贵在它解决问题的思路和设计很令人耳目一新。如果大家有兴趣,可以去它的官网了解下。
本文总结了笔者在实现Go和Rust版RSocket SDK过程中的一些心得感悟,有兴趣的同学可查看相关链接。