current position:Home>[forward] RPC and HTTP requests

[forward] RPC and HTTP requests

2021-08-23 10:53:31 Front end skilled worker

HTTP and RPC Not the concept of equivalence .

RPC Is a complete remote call scheme , It includes : The interface specification + Serialization and deserialization specification + Communication protocol, etc .
and HTTP It's just a communication protocol , Working in OSI The seventh floor , Not a complete remote invocation scheme .

therefore , To answer this question , It should be leveled as an equivalent concept . for example ,HTTP+Restful standard + Serialization and deserialization , Constitute a complete remote call scheme , And again RPC Compare . and pure HTTP, It's just a communication protocol , Nature cannot and RPC Compare .

It's like a cow (HTTP) Not with the carriage (RPC) Compare . To compare , We should make up the cattle for the ox cart , Then compare it with the carriage .
The main feeling question should be to ask : be based on HTTP The remote call scheme of ( Contains the interface specification 、 Serialization, deserialization, etc ) and Use RPC The remote call scheme of What's the difference . With the former , Why the latter .

Let's answer this question .

Let's start with the introduction based on HTTP The remote call scheme of .

HTTP+Restful, It has a lot of advantages . it Good readability , And can get Firewall support 、 Cross language support . and , In the reports of recent years ,Restful Much more than RPC The trend of .

However, using this scheme also has its disadvantages , This corresponds to its advantages :

  • First, less useful information , After all HTTP Working on the seventh floor , It contains a lot of HTTP First class information .
  • Secondly, it's inefficient , Or because of the seventh layer , Must follow HTTP The protocol is encapsulated layer by layer .
  • also , Its readability seems unnecessary , Because we can introduce gateway to increase readability .
  • Besides , Use HTTP Protocol calls remote methods are complex , To encapsulate various parameter names and parameter values .

and RPC Then with HTTP complementary , Let's introduce in detail .

After reading this answer , Can make you right RPC The birth of 、 principle 、 The implementation code has a clear understanding . such , It can also be in business systems , stay RPC and HTTP Make a choice between .

But I need to say one more thing , Not to say that RPC good , Is not to say that HTTP good , Each has its own merits , Still in competition .

Ask me who I stand ? I follow the business scenario , Flexible station ……

There was some debate in the comment area , I will explain it here . The debate mainly took place on two points :

1、HTTP and RPC Same level , Or was RPC contain ?
2、Restful Also belong to RPC Well ?

For the above two points , I draw pictures to illustrate them one by one .

The figure above is a relatively complete diagram , And then we found out HTTP( Blue box in the picture ) It appears twice . One of them is and RPC Side by side , Both are solutions for cross application calling methods ; The other is being RPC Contains , yes RPC One of the optional protocols for the communication process .

therefore , The answer to the first question is all right . See which blue box you mean . From the question of the subject , Since the subject is tangled with the two , It should refer to and RPC Side by side blue box . therefore , As described in the title HTTP Request should mean : be based on HTTP The remote call scheme of ( Contains the interface specification 、 Serialization, deserialization, etc ). such , It is and RPC Same level concept .

The second question is about remote procedure calls ( Red box ) Does it include Restful( Yellow box ), The key to this understanding is to RPC The understanding of the .

RPC It is literally a remote procedure call , That is to call another application in one application. . that Restful Is satisfied , Through it, you can achieve another application in one application. .

however , The above understanding makes RPC The definition of is too broad .RPC Usually refers to the remote call implemented in one application calling the interface of another application. , That is, the range indicated by the red box . such ,RPC It doesn't include Restful Of .

therefore , The answer to the second question is Restful Do not belong to RPC, Unless it's right RPC Has an unconventional broad understanding .

RPC Our English full name is Remote Procedure Call, It's called “ Remote procedure call ”. What is a little obscure is “ The process ”, The process is the method . therefore , You can put RPC Understood as a “ Remote method call ”.

Learn about remote procedure calls , Understand procedure call first . It's simple , Here's the picture , Call a method . It's so common , Not much to explain .

In a distributed system , Because the boundaries of each service are very small , It is possible to call methods provided by other services . So there's the service A Call the service B The requirements of the method in , Remote procedure call .

If you want service A Call the service B The method in , The first thing I think about is through HTTP Request to implement . Yes , This is very common , For example, service B expose Restful Interface , Then let the service A Call its interface . be based on Restful Because of its good readability ( service B What is exposed is Restful Interface , Readability is certainly good ) and HTTP Requests can pass through various firewalls , So it's very good .

However , As described above , be based on Restful Remote procedure calls have obvious disadvantages , The main reason is low efficiency 、 Encapsulation call complexity . When there are a large number of inter service calls , These shortcomings become more prominent .

service A Call the service B The process of is an internal process between applications , Improve efficiency at the expense of readability 、 Ease of use is desirable . Based on this idea ,RPC Produced .

Usually ,RPC The interface that requires the called method to be placed in the caller . As long as the caller calls these interfaces , It is equivalent to calling the actual method of the callee , Very easy to use . therefore , Callers can call remote methods just as they call internal interfaces , Instead of encapsulating operations such as parameter names and parameter values .

What should we do to achieve this process ? Don't worry. , Let's go step by step .

First , The caller calls the interface , You must construct a fake implementation for the interface . obviously , To use a dynamic proxy . such , The caller's call is received by the dynamic proxy .

second , After the dynamic agent receives the call , You should find a way to call the actual implementation of the remote . This includes the following steps : Identify the specific remote method to call IP、 The port serializes the input parameters of the calling method and sends the request to the remote method through communication

such , The remote service receives the caller's request . It should :

  • Deserialize individual call parameters
  • Navigate to the actual method to call , Then enter the parameters , Execution method
  • Returns the result of the call according to the path of the call

The whole process is as follows .

such ,RPC The operation is finished .

The caller calls an internal method , But be RPC A method of changing frame beam to column for remote . Communication data between Readability does not need to be good , It only needs RPC The frame can be read , therefore More efficient . Usually use UDP perhaps TCP As a communication protocol , You can also use it HTTP. For example, in the following example , To ensure the simplest implementation , Just used it. HTTP communicate .

Here we are. ,RPC Causes of 、 The principle should be clear . To make everyone really understand , I wrote a really The simplest RPC Realization . Put it in :​

It contains a client , A server . The client just calls its own internal interface , Through this small RPC The implementation calls the method of the server .

Here is the client code , There are a lot of classes , In fact, the code is not long . Among them RPC Code completion dynamic agent 、 Remote call parameter serialization 、 Remote call initiation 、 Deserialization of remote call results .

RPC Below the client is the code of the server , Less code , Complete remote call reception 、 Call parameter deserialization 、 Call actual trigger 、 Work of calling result serialization .

such , One RPC The small frame is finished , Is not complicated . therefore , Don't be RPC Scared , It is an implementation way for one application to call methods in another application . It is not very different from calling a remote interface , All roads lead to Rome .

Say it again , Not to say that RPC good , Is not to say that HTTP good , Each has its own merits . Essentially , The two are the choice between readability and efficiency , Choice between versatility and ease of use . Who can develop better in the end , It's hard to say. .

Ask me who I stand ? I follow the business scenario , Flexible station ……

If there's anything else I don't know , You can leave a message to discuss . Why do I know RPC Implementation details , Because I read it dubbo Source code , ha-ha

author : Yi Ge
link :
source : You know
The copyright belongs to the author . Commercial reprint please contact the author for authorization , Non-commercial reprint please indicate the source .

copyright notice
author[Front end skilled worker],Please bring the original link to reprint, thank you.

Random recommended