RSocket云原生架构下的另外一种通讯协议选择

写在前面

奈飞公司在整个微服务架构体系处于行业领先地位，在其内部有一种自研的通讯协议方式，以实现微服务架构下高性能的通讯，他就是RSocket。同时在云原生概念盛行的今天，一种能够在service mesh下高性能通讯的组件一样也是各个企业须要的，因此今天咱们就聊聊RSocket吧。

为何须要一种新的通讯协议？

在微服务，云原生架构盛行的今天，各类服务之间，mesh之间须要进行大量的通讯，网络彷佛成了整个架构栈中的一等公民。

为减小因网络的不肯定性而带来对于整个网络架构系统的影响，下降请求延迟每每须要进行一系列的可用性设计。

而目前常见的网络协议，如HTTP的request-response交互方式，很难有效或高效的进行通讯，也很难解决海量请求下对于后端资源有效使用的问题。同时HTTP这种文本协议方式较二进制协议的实现也能够有效提高性能。

RSocket是什么？

对RSocket吹了一波，那么RSocket到底是什么呢？

官方定义：RSocket是基于reactive stream flow control的双向，多路，基于消息的，二进制的通讯协议。

RSocket是一种新的七层通讯协议，某种程度能够认为是HTTP等其余协议的替代方案。较HTTP协议来讲，其增长了异步，双向背压，多路复用，断线重连，消息驱动等特色。

因为是Pivatal公司主导的项目，其实现上大量引入了Reactive Stream相关的编程实现。

以前咱们Reactive相关文章说过，响应式规范的兴起，目的之一就是为了解决海量终端设备背景下，服务端接受请求过载，超时宕机等问题，经过响应式编程中的背压能够实现这种压力过载的控制。

交互模式分为四种：

1. request-response：请求响应式，目前基于http请求的模式都是这种。
2. fire-and-forget：对于那些不关心结果的请求，直接返回。
3. request-stream：一个请求，能够经过流方式返回屡次结果。
4. channel：服务器能够主动发多个请求到客户端，客户端能够发多个结果给服务器。

特色：

• 对于请求和响应均可以取消掉，能够释放掉一些系统资源。
• 若是数据提供方因为某种缘由hang住，请求方能够先断开，以后有时间以后再来检查结果。
• 相似于“背压”的能力，能够根据本身的性能状况控制调用方的频率。

因此其更适合分布式场景下的通讯。

在RSocket传输信息中，请求能够划分为一个个的帧，每一个帧都包含一个帧头，其中包含：流ID，帧类型，其余数据。帧头后是元数据和有效负载（承载用户数据）。

对于这种帧的流，咱们可使用任何的序列化方式进行处理，好比JSON，Protobuf或avro等。

除了这种在协议文本上下功夫以外，其多路复用模型也是其能够进行高效通讯的缘由。

在请求中，每一个流都有一个惟一的ID，经过ID能够区分每一个流，解决了之前HTTP协议下每一个请求独占链接的问题，解决相应的性能问题。

另外一个优点就是咱们屡次提到的“背压”，其“背压”实现上实现了一种“租约机制”，响应者能够指定请求者在定义的时间范围内发送多少请求。

在负载均衡角度，RSocket能够实现客户端方式的负载均衡，实现方式依赖于LoadBalancedRSocketMono对象，在其中一组可用的RSocket实例中选择合适的RSocket实例进行访问。须要订阅LoadBalancedRSocketMono的onNext方法获取所有RSocket实例，同时对每一个RSocket信息进行统计，计算每一个实例负载以肯定最佳选择。

在统计信息选择上包括：延迟，保持的链接数及未处理的请求数。这些运行时数据能够实时反应出来。

整个流上，经过keep-alive帧按期来回发送，探测链接的稳定性，keep-alive帧中还包含令牌，以确认请求者响应者最后的接收位置。

框架的支持

在Java体系下，对于RSocket的实现通常是基于TCP长连接实现的。不一样于其余基于TCP协议的长连接的在于RSocket是一系列的协议规范。

在Spring5时代，Reactor和webflux是值得咱们关注的一套技术，Reactor模型并不能提高请求性能，下降延迟，可是能够提高吞吐加强系统弹性。可是结合了RSocket后，对于http处理性能则如虎添翼。

以前的文章中讲过Reactor和WebFlux就不赘述了，RSocket和WebFlux结合的很好，能够很方便的使用Mono/Flux相关接口。

既然一直在提“背压”，那么“背压”在真实产品体验上有什么用呢？

试想一下，咱们在刷朋友圈的时候，常常会遇到卡顿的状况，这个时候通常是发起的http请求没有正常获得响应，通常须要用户主动重试，这样就再次发起了一次请求，http自己是无状态的，每次请求服务器都须要受理并处理。

若是有了基于应用程序协议上的“背压”实现，能够必定程度上减小APP上的无效或重复请求，必定程度上提高系统资源利用率。一些超级用户量产品的通讯工程团队已经这样搞了，好比谷歌和FB。

固然国内阿里团队也将一部分精力投入到对于RSocket应用的普及上了，好比在Dubbo中就尝试了对RSocket的适配。

说了这么多，你是否是已经手痒痒了呢？打开SpringBoot2赶忙搞起来吧！