[gRPC] The first chapter fully explains the principle of RPC (must be collected)

Table of contents

1. What is RPC

 2. Why use RPC 

3. Commonly used RPC frameworks

4. RPC call process

---

1. What is RPC

RPC (Remote Procedure Call Protocol) remote procedure call protocol , the goal is to make remote service calls easier and more transparent.

The RPC framework is responsible for shielding the underlying transmission method (TCP or UDP), serialization method (XML/Json/binary) and communication details. The service caller can call the remote service provider like a local interface without caring about the underlying communication Details and calling process.

 2. Why use RPC 

When our business is increasing and applications are increasing, we will naturally find that some functions cannot be simply divided or cannot be divided.

At this time, the public business logic can be extracted and formed into an independent service application, and the original and newly added applications can interact with those independent service applications to complete the complete business function.

So we urgently need an efficient means of communication between applications to fulfill this requirement, and the time has come for RPC to show its talents!

3. Commonly used RPC frameworks

gRPC : Originally developed by Google, it is a language-neutral, platform-neutral, open source remote procedure call (RPC) system.

Thrift : thrift  is a software framework for the development of scalable and cross-language services. It combines a powerful software stack and code generation engine to build on C++, Java, Python, PHP, Ruby, Erlang, Perl, Haskell, C#, Cocoa, JavaScript, Node.js, Smalltalk, and OCaml programming languages Seamlessly integrated and efficient service.

Dubbo : Dubbo is a distributed service framework and SOA governance solution. Dubbo has been used by many non-Alibaba companies since it was open sourced in 2011.

Spring Cloud : Spring Cloud consists of many sub-projects, such as Spring Cloud Config, Spring Cloud Netflix, Spring Cloud Consul, etc., which provide common tools for building distributed systems and microservices.

4. RPC call process

To make network communication details transparent to users, we need to encapsulate the communication details. Let's first look at the communication details involved in the next RPC call process:

1. The service consumer (client) calls to call the service locally;

2. After receiving the call, the client stub is responsible for assembling methods, parameters, etc. into a message body that can be transmitted over the network;

3. The client stub finds the service address and sends the message to the server;

4. The server stub decodes the message after receiving it;

5. The server stub calls the local service according to the decoding result;

6. The local service executes and returns the result to the server stub;

7. The server stub packs 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.

The goal of RPC is to encapsulate steps 2~8 so that users are transparent about these details. Here is another picture on the Internet, which feels clear at a glance: