What is RSF?

A high availability, high performance, lightweight distributed services framework. Supports Dr, load balancing, and clustering. A typical application scenario is that the same service is deployed on multiple servers to provide request and Response notifications. With RSF, calls can be point-to-point or distributed. Deployment mode: It can be used with the registry or independently.

 

yuanyuan

The core idea of RSF refers to excellent frameworks such as Taobao HSF and Dubbo. The functionality is broadly similar, but the implementation logic is completely different. So there’s no historical baggage. In general, HSF is less historical burden than Taobao, and more lightweight than Dubbo. It also supports virtual machine rooms, which can save a lot of bandwidth costs and reduce remote call times for products deployed in multiple machine rooms.

Although RSF is not different from the two predecessors in function, the most intuitive feeling of using RSF is simple and convenient, less configuration, less dependence, and powerful function.

The characteristics of

The great feature of RSF is that it can be maintained with great functionality: the simplest and the lightest. Let’s start by understating the characteristics of RSF.

Simple and easy (three ones) : one line of code to publish the service, one line of code to subscribe to the service, one line of code to use the service

Lightweight: RSF is built on Hasor and relies on Netty and Groovy as well. So the total number of jars introduced including RSF is only five, of which RSF is only about 700KB in size.

The working principle of

RSF is a distributed RPC service framework designed for clustering and high availability systems. A service provider can be a cluster, a service consumer can be a cluster, and mixing the two together in a cluster is ok. The RSF registry also supports clustering to enhance disaster recovery.

So there is no single point of problem with a service system built on RSF.

Framework of hierarchical

The ARCHITECTURE of RSF follows a clear hierarchy from top to bottom, with each layer having focused responsibilities. It can be divided into 9 levels. They look like this: you can also understand that this is the architectural design of RSF.

Review images

The first layer is the service in the business system. The state of a service can be Provider, Customer, or both. In this layer, either the service interface or the implementation of the service’s interface appears.

Layer 2: is an application access layer to the framework. It is divided into two parts: Provider and Customer.

For providers, this layer is the framework’s interaction API, which extracts the service interface information for the RSF framework to identify. For the Customer, the purpose of this layer is to dynamically proxy the service interface. Intercepting all remote method calls through a proxy is similar to AOP.

Layer 3: In this layer, all interface calls from the dynamic proxy are uniformly converted to RsfRequest, and the return value of the method is encapsulated as RsfResponse. This layer is designed specifically for extensibility, where developers can extend around the RsfFilter, RsfRequest, and RsfResponse interfaces.

Layer 4: This is a typical chain of responsibilities that begins with invocation requests and ends with method invocation. Developers can do almost anything they want in the chain of responsibility. You can interrupt the entire RPC and mock the data yourself. You can also call another service and return the result.

Layer 5: This layer is the exclusive design of the Customer. This layer is a relatively important place, which is responsible for maintaining and managing the IP address of the service. For example: We have a service that has 10 service providers. Then the service address and port information of the 10 service providers are maintained in this layer. This layer provides IP addresses when remote calls are made.

The operation of providing an IP address needs to be expanded a bit. To QoS flow control, call across machine room, service routing. These very important functions are supported by this layer. This layer is expressed in one sentence: it is the address manager.

Level 6: This level is best summed up with “scheduler”.

For providers, this layer provides a Server protection barrier based on queues. This protective barrier ensures that when the Client encounters a crazy call request, it can be reasonably rejected to ensure that the Server itself is not overwhelmed. In the case of the Customer, a request manager is provided at this layer and a controller for maximum request concurrency is provided.

This layer is the central nerve of RSF, as the scheduler is the ultimate implementation of the RSF threading model. The threading model will be covered in a later article.

Level 7: Provides serialization functionality, and developers want to customize the serialization rules. It is also supported by this layer. The default RSF uses Hessian 4.0.7 as the default serialization library. At the same time, the framework built-in Java, Json two strategies can be selected.

If you use Hessian when requesting the data, you want to use JSON for the response. It can be supported.

Layer 8: This layer is the lowest layer and is responsible for the transmission of network data. Therefore, a relatively complete RSF data transmission protocol is built into RSF at this layer. The article here: my.oschina.net/u/1166271/b…

The ninth layer: is the computer Socket network communication. This layer can be TCP or UDP if you want. However, RSF uses TCP long links.