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.
2. RSocket
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
In the language scope, RSocket doesn’t reinvent the wheel. In different languages, RSocket achieves its goal with various approaches with existing features and/or libraries. For example, it uses the Reactor in Java. It uses the Event-Loop of Node.js in Javascript. And it uses Goroutines in Go.
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.
- requester-responser
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
2.2.2 Multiplexed/Connection-Oriented
- 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.
#tutorial #microservices #reactive #reactive architecture #rsocket #reactive development
