The principle and application method of RPC framework

With the transformation from a centralized architecture to a distributed architecture, the problem of service invocation and communication between application systems has become the primary requirement to be solved. The main goal of RPC is to make it easier to build distributed computing (applications) without losing the semantic simplicity of local calls while providing powerful remote calling capabilities. To achieve this goal, the RPC framework needs to provide a transparent call mechanism so that users do not have to explicitly distinguish between local calls and remote calls.
RPC or Remote Procedure Call is an inter-process communication method. The role of RPC mainly has three aspects: inter-process communication, providing the same calling mechanism as local method calls, and shielding programmers from the detailed implementation of remote calls.
The first is the problem of communication between processes. For a distributed environment, rpc can help us solve the problem of communication and data transmission between different servers, that is, to convert method calls to data, and then use the network for data transmission; rpc client to The rpc server initiates a remote service call, through the encapsulation of the request, the encapsulation of parameters, serialization, encoding, agreement protocol transmission, parsing requests, processing requests, encapsulation of returned message data, serialization and encoding of the returned data, and transmission through the network. returned to the client. Furthermore, it provides the same invocation mechanism as the local method invocation. Mr. Chen, the programmer of Shangxuetang Baizhan pointed out that for the business system, we focus more on how to solve the actual business needs, and do not want to spend more The time and thought are related to the network transmission and codec process in the above process, so for RPC, these codecs, protocol conventions, network transmission, etc. need to be encapsulated as a whole, and then only provide the business system with the simplest call method. The last detail implementation of remote calls by shielding programmers is actually the encapsulation of those functions mentioned in the second point. We don’t need to care about how RPC is implemented or how it works. For business development For personnel, it is enough to call the remote service interface in a form similar to the local method call through the agreed method.
So how to achieve transparent remote call?
What kind of internal encapsulation can make us feel like calling a remote service as a local call?
For java it is to use a proxy. There are two ways for java proxy: 1) jdk dynamic proxy (interface proxy); 2) cglib proxy (subclass proxy). Although the proxy implemented by the bytecode generation method is more powerful and efficient, the code is not easy to maintain. Most companies still choose the dynamic proxy method when implementing the RPC framework. This part will also be expanded in subsequent chapters.
From initiating a remote call to receiving a data return result, the general process is:
1) The service consumer (client) calls the service in a local call mode;
2) After the client stub receives the call, it is responsible for assembling methods, parameters, etc. into a network capable of
3) The client stub finds the service address and sends the message to the server; 4
) The server stub decodes the message after receiving the message;
5) The server stub calls the local service according to the decoding result;
6) The local service executes and Return the result to the server stub;
7) The server stub packages the returned result into a message and sends it to the consumer;
8) The client stub receives the message and decodes it;
9) The service consumer gets the final result.
Then rpc is equivalent to encapsulating the steps of step2-step8. Below is a picture from the Internet to help us understand the process.
The RPC server exposes the service interface through RpcServer, and the client obtains the service interface through RpcClient. The client calls the remote interface method just like calling the local method. The RPC framework provides the proxy implementation of the interface, and the actual call will be delegated to the proxy RpcProxy. The proxy encapsulates the call information and forwards the call to the RpcInvoker for actual execution. The RpcInvoker on the client side maintains the channel RpcChannel with the server through the connector RpcConnector, and uses RpcProtocol to perform protocol encoding (encode) and send the encoded request message to the server through the channel. The RPC server receiver RpcAcceptor receives the client's call request, and also uses RpcProtocol to perform protocol decoding (decode).
The decoded call information is passed to RpcProcessor to control the processing call process, and finally delegate the call to RpcInvoker to actually execute and return the call result.
According to the above analysis, it includes the following core components:
RpcServer used to expose service interfaces
RpcClient
remote interface used to discover service interfaces Proxy implementation of RpcProxy
responsible for protocol encoding and decoding RpcProtocol (the actual rpc framework generally provides a variety of different Implementation)
commonly used distributed RPC frameworks are: dubbo, motan, rpcx, gRPC, thrift, etc.
We have also made a basic understanding of common RPC frameworks. For these excellent frameworks, we can learn from some patterns and technologies in these frameworks when implementing our own RPC. Finally, it explains why we use RPC instead of MQ in the distributed architecture. For MQ, processing synchronous calls cannot meet the actual production needs, and RPC is more suitable for the actual needs of distributed applications.