RSocket in Cloud Native
RSocket in Cloud Native
A note on RSocket in Cloud Native through computing foundations and an explanation of techniques.
Join the DZone community and get the full member experience.Join For Free
In the mission of the cloud-native computing foundation, It states “the techniques enable loosely coupled systems that are resilient, manageable, and observable.” Those three characterizes are the core of the cloud-native computing foundation. Other technologies play a support role.
1. Reactive Programming
1.1 Imperative Programming vs. Reactive Programming
With an imperative approach, a developer writes code that describes in exacting detail the steps that the computer must take to accomplish the goal. Those steps are executed in the order as the developer lays out without considering other systems the code interacts with.
With a reactive approach, a developer can build a non-blocking, asynchronous code that can handle back-pressure (flow control). As a result, the code will observe and react to any actions outside of the system without being restricted by the code programming instruction. It will work well under the pressure.
1.2 Reactive Stream
The Reactive stream is about I/O, asynchronous stream processing with non-blocking backpressure. Asynchronous is about situation and non-blocking is about handling. It has an advantage in a large data processing system.
The concept of backpressure is that a client is a king to ensure the other party can handle its task properly with a given amount of data. For example, in an airport check-in line, the counter clerk will ask whoever on the line comes to the counter once the clerk is available to provide a service. It could be one person or a group of several people coming forward to the check-in counter. That is to say, that node sends a signal on how much data it can handle and the other node sends over data within the data amount the part indicates at the time. In such fashion, a node will handle amount of traffic date it can handle from other nodes.
In terms of asynchronous, any programming languages created in the past decade have the feature. It comes with different terms such as callback-based, Rx/Reactor, co-routines, asynchronous/await, etc. in the form of either build-in and library.
Although various programming languages have a reactive feature, none of those languages have a mechanism of communication in a reactive fashion. For example, two parties/nodes can be reactive on their own, but there isn’t a correlation between them in a reactive fashion. That could lead to an application system break under high pressure. One party/node could engage a communication while the other party/node is busy with a heavy data load. That is the motivation of the circuit break design pattern. The design pattern can be used to check the availability of an external service and detects failures and prevents the application from trying to perform the action that is doomed to fail.
To address this issue, a new application protocol, RSocket, a new application protocol for multiplexed, duplex communication, is formed. Like many cloud-related open source technologies, it was initially developed by NetFlix. Its initial release was in October 2015.
RSocket is a binary protocol for use on byte stream transports such as TCP, WebSockets, and Aeron. The “R” stands for reactive. A network socket is an internal endpoint for sending or receiving data within a node a computer network. Concretely, it is a representation of this endpoint in networking software and is a form of system resource. RSocket is on the same level of HTTP in the communication protocol layer.
RSocket honors reactive syntax for modern cloud application and it has the following features:
- Provides a standard approach to connecting and communicating
- Solves a problem in a consistent way across your applications
2.1 RSocket Interaction Models
As mentioned before, RSocket is on the same level of HTTP in the communication protocol. Http is designed for communication between humans and a computer. After a human submits a request to a computer through a web browser, the computer will send some human-readable data back based on the request. Http is not designed for communication between computers.
RSocket has four communication interaction models. Those four models cover all communication requirements between computers. It enables the following symmetric interaction models via async message passing over a single connection:
request-response — send one message and receive one back
In this interaction model, RSocket behavior likes HTTP. A request is sent and a response will be returned based on the request. In this model, RSocket won’t show any advantages in a low data flow situation.
fire-and-forget — send a one-way message
It is used in a situation that an application doesn’t need to wait for an action result of an external system. For example, acknowledgment isn’t needed in the situation for writing a message into an external log file system.
request-stream — send one message and receive a stream of messages back
One example of the usage scenario is requiring a video file, one party sending a request, and the other party sending back a stream of video data based on the request.
channel — send streams of messages in both directions
One example of using the channel is online chat. A connect is set up on both ends and data constantly flow forward and backward between those two ends.
2.2 RSocket Design Features
2.2.1 Message-Based Binary Protocol.
All Data Is in a Framed Format.
The interaction is broken down into frames that encapsulate messages.
- The Framing Is Binary
(not a human-readable format like JSON or XML) (benefit — at least 30% faster than HTTP format)
- Payload Agnostic
Data can be in various format: Protobuf, GraphSQL, Json, custom binary
- Create single the connection between two nodes
- Interactions are broken into “logic stream” with an ID
- Multiplexing solves the issue by annotating each message on the connection with stream id that partitions the connection into multiple “logical stream”
- Logic stream and connection allow for “soft sticky” state (session)
- Cancel frame while the connection is still up (finding a double frame)
- Resume: reconnect and breaking point. For example, the connection is off in the third frame. After the resume, the following frame, the fourth frame will be sent.
2.2.3 Bi-directional Communication
In the HTTP protocol, only the client can initialize a communication, and the server only can respond to a request from its client. That is designed for human and computer interaction. Also, in the HTTP, a connection is set up when the client issues a request. TCP is bi-directional communication, in which any party can initialize a communication. RSocket is similar to TCP in the way of bi-directional communication.
Resilient is the first citizen in the RSocket. And RSocket doesn’t need an external force to make it resilient.
Key differences between RSocket and HTTP (source: Pivotal)
efficient and responsive
single, shared long-lived connection
new connection per request (HTTP 1.0)
pipeline messages (HTTP 1.1)
communication back pressure
does not communicate back pressure
either party can initiate requests (flexible requester/responder roles)
only client can initiate requests (fixed client/server roles)
support canceling/resuming streams
doesn’t support canceling/resuming
The above is about the resilience of RSocket. In terms of manageability and observability of RSocket, Alibaba RSocket Broker or Netifi Broker will perform those tasks.
As stated previously, any node/server can send an RSocket request to another node/server in one of four symmetric interaction models. There shall not be a node that is designated to send requests only nor to receive requests only unless there is such a business requirement. For some reason, client-server, a conventional computer communication terminology, is floating in most articles on the subject of parties involved in RSocket communication. Some of those articles are presented by big names in the industry. In their demonstration code, there are a client node, only for submitting RSocket requests, and a server node, only for responding to RSocket Requests. One article, I have read, use terms of "requester" and "responder" instead. The pair of terminology is better based on the RSocket specification. However, not all RSocket communication models request providing a response to a request. In my humble opinion, the proper terminology of RSocket shall be "requester" and "receiver" to refer to parties in the RSocket communication. A node/server can be both requester and receiver over a single ‘bi-directional’ connection at the same time.
In short, RSocket, an application protocol for multiplexed, duplex communication over TCP, WebSocket, and other byte stream transports, will make communication between nodes/microservices resilient. And it also simplifies microservices development by eliminating circuit break in your microservices system. Those are the benefits of RSocket.
A coding sample of those four RSocket interaction modes will be in a follow-up note.
* RSocket specification: https://rsocket.io/docs/Protocol
* RSocket extensions: https://github.com/rsocket/rsocket/tree/master/Extensions
* The first sample code will be explained in the follow-up note: https://github.com/vw98075/spring-rsocket-sample (this code sample is in Java and it demonstrates the fire-and-forget and request-response interaction models. It will be gratefully appreciated for your suggestions on how to use other Rsocket interaction models in the given system functionality)
Opinions expressed by DZone contributors are their own.