简介：RSocket 是高效一个二进制的网络通讯协定，可能满足很多场景下应用。另外，RSocket 也是一个激进的响应式捍卫者，激进到连 API 都跟响应式无缝集成。本文咱们将和大家分享 RSocket 与响应式编程。
作者 | 素渡
起源 | 阿里技术公众号
一 RSocket 的次要个性
首先，RSocket 是高效一个二进制的网络通讯协定，可能满足很多场景下应用。其次，RSocket 是一个激进的响应式捍卫者，激进到连 API 都跟响应式无缝集成。
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 是个很乏味的网络协议，它可能不会遍及风行，但贵在它解决问题的思路和设计很令人耳目一新。如果大家有趣味，能够去它的官网理解下。
原文链接
本文为阿里云原创内容，未经容许不得转载。