How to implement a distributed RPC framework

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

Before the internship in this part of my spare time, I realized a lightweight distributed RPC framework, called Buddha, the code is not large, but small but perfectly formed. This article takes a step-by-step look at 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 bytes for transmission, so at the code level, an RPC framework needs to implement the conversion between the data in a particular format and the byte array. Like Java already provides the default serialization method, but in high concurrency scenarios, 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 two serialization frameworks of Kryo and Fastjson. TCP unpacking, sticky packets

Because TCP only cares about byte streams, it does not know the data format of the upper layer. If the client application tier is sending too much data at a time, TCP will decompose the data, so it needs to be processed on the server (by TCP to ensure the order of the data); If the amount of data that the client sends at a time is very small, TCP does not send the data immediately, but instead stores it in a buffer. When a certain threshold is reached, it is sent out, so the task of unpacking is required on the server side.

Through the above analysis, we understand the reason of TCP sticky packet or unpacking, the key to solve this problem is to add the boundary information to the packet, the commonly used methods are as follows three. The sender adds a packet header to each packet, at least the length of the packet in the header, so that the length of the packet's valid data is obtained by reading the header's length information when the data is received at the receiving end. The sending side encapsulates each packet as a fixed length (redundant with 0 padding) so that the receiving end reads the data for each packet according to the agreed fixed length after receiving the data. Each packet is distinguished by a special symbol, and the receiving end is also the boundary of the packet that is delimited by the special symbol.

Buddha uses the first approach to solve the problem of TCP unpacking, sticky packets. Bio and NiO

Bio is often used for the classic per-connection per-threading model, with multi-threading because functions such as accept (), read (), and write () are synchronously blocked, which means that when the application is single-threaded and IO-operated, the application will inevitably go into a dead state if the thread is blocked. However, the CPU is actually idle at this time. Turning on multi-threading allows the CPU to serve more threads and increase CPU utilization. However, when the number of active threads is high, the use of multithreaded models brings up the following problems. Threads are expensive to create and destroy, and in a Linux operating system, threads are essentially a process, creating and destroying threads that are heavyweight operations. In the JVM, each thread occupies a fixed-size stack space, and the JVM's memory space is limited, so if the number of threads is too large then the thread itself will occupy too much resources. The switching cost of a thread is high, and each thread switchover requires a context-saving, recovery, and user-state and kernel-state switchover. If the number of threads is too high, then a large percentage of CPU time is spent on thread switching.

The first two problems are solved by using the thread pool, but the overhead of thread switching is still there. So in high concurrency scenarios, the traditional bio is powerless. The important feature of NIO is that the read, write, register, and receive functions, which are non-blocking at the wait-ready stage, can be returned immediately, allowing us to take advantage of the CPU without using multithreading. If a connection cannot be read and written, the event can be logged and then switched to a different ready connection for data read and write. 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 service stability and reliability. It is therefore necessary to implement a service registry where the service provider registers the currently available service address information with the registry, and when the client makes a remote invocation, it first obtains the currently available list of services through the service registry and then obtains the address information of the specific service provider (which can be load balanced). Initiates a call to the service provider based on the address information. The client can cache the list of available services and notify the client when changes occur to the registry's list of services. Also, you need to notify the Registry service to be unavailable when the service provider becomes unavailable. Buddha uses zookeeper to implement service registration and discovery capabilities. Code Implementation

Buddha is a lightweight, distributed RPC framework that I learned to validate the RPC process, with the code on GitHub. Reference The conceptual model of RPC and its implementation analysis NETTYRPC
Reprinted from: Http://www.importnew.com/26604.html http://tinylcy.me/2017/07/04/%E5%A6%82%E4%BD%95%E5%AE%9E%E7%8E%B0%E4%B8 %80%e4%b8%aa%e5%88%86%e5%b8%83%e5%bc%8frpc%e6%a1%86%e6%9e%b6/