How to implement a distributed RPC framework _ implementation

Remote Procedure Call (Sqlremote Procedure CALL,RPC) is a computer communication protocol. This protocol allows programs running on one computer to invoke subroutines on another computer, and programmers do not need to programmatically program this interaction. The main goal of RPC is to make it easier to build distributed applications, while providing powerful remote invocation capabilities without losing the simplicity of the semantics of local calls.

Before the internship in this spare time, I realized a lightweight distributed RPC framework, called Buddha, the code is small, but though small is spite. This article will step through the design of the Buddha, the disassembly of the framework components, and the factors to consider. Serialization and deserialization

In the network, all data will be converted to byte for transmission, so at the code level, an RPC framework needs to implement the transformation between the data in a particular format and the byte array. Java has already provided the default serialization method, but if it is in a high concurrency scenario, using Java native serialization may encounter performance bottlenecks. As a result, there are many open source, efficient serialization frameworks: such as Kryo, Fastjson, and Protobuf. Buddha currently supports the Kryo and Fastjson two serialization frameworks. TCP Unpacking, sticky packs

Because TCP only cares about byte streams, it is not aware of upper-level data formats. If the client application tier is sending too much data at once, TCP will decompose the data for transmission, so it is necessary to carry out sticky packets (TCP to ensure the order of data), and if the client sends the data at a very small amount of time, TCP does not send the data immediately, but stores it in the buffer. When a threshold is reached, it is sent again, so the work of unpacking is required on the server side.

Through the above analysis, we understand the reasons for TCP sticky or unpacking, the key to solve this problem is to add boundary information to the packet, commonly used methods are as follows three. The sender adds the package header to each packet, and the header contains at least the length of the packet, so that when the receiver receives the data, the length of the packet's valid data is obtained by reading the header's length information. The sender encapsulates each packet as a fixed length (extra 0 padding) so that the receiving end reads each packet's data according to the agreed fixed length after receiving the data. A special symbol is used to differentiate each packet, and the receiving end is also the boundary of the packet that is delimited by the special symbol.

Buddha the first way to solve the problem of TCP unpacking and sticky packets. Bio and NiO

The bio is often used for the classic each threading model per connection, multiple threads are used because functions such as accept (), read (), and write () are blocked synchronously, which means that when a thread is applied to a single-threaded and IO operation, the application will inevitably go into a dead state, But in fact, the CPU is idle at this point. With multiple threads open, the CPU can be used to service more threads, increasing CPU utilization. However, when the number of active threads is high, multithreading model is used to bring the following problems. The creation and destruction of threads is costly, and in a Linux operating system, threads are essentially a process, and creating and destroying threads is a heavyweight operation. In the JVM, each thread consumes a fixed amount of stack space, and the JVM's memory space is limited, so if the number of threads is too high, the thread itself takes up too much resources. Thread switching costs are high, and each thread switch involves saving and restoring the context, as well as switching between user and kernel states. If there are too many threads, a larger proportion of CPU time will be spent on thread switching.

The first two problems are solved by using a thread pool, but the overhead of thread switching is still there. So in a high concurrency scenario, the traditional bio is powerless. The important features of NIO are: Read, write, register and receive functions, in the wait-ready phase is non-blocking, can be returned immediately, which allows us not to use multithreading to make full use of the CPU. If a connection is not read or write, you can log the event and switch to a different ready connection for data reading and writing. In Buddha, Netty is used to write more clearly structured NIO programs. Service Registration and Discovery

In practical applications, the providers of RPC services often need to use clusters to ensure the stability and reliability of the service. It is therefore necessary to implement a service registration center, the service provider registers the currently available service address information to the registry, and when the client makes a remote call, it obtains the currently available list of services through the service registry and then gets the address information for the specific service provider (which can be load balanced). Initiates a call to a service provider based on the address information. Clients can cache the list of available services and need to notify the client when a registry's list of services has changed. Also, when a service provider becomes unavailable, you need to notify the Registry service that it is not available. Buddha uses zookeeper to implement service registration and discovery functions. Code implementation

Buddha is a lightweight distributed RPC framework that was born during my learning to validate RPC, and the code was placed in GitHub. Conceptual model and implementation analysis of reference RPC NETTYRPC from:  http://www.importnew.com/26604.html