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 ：https://github.com/yeecode/Ea...github.com/yeecode/EasyRPC
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
source ： You know
The copyright belongs to the author . Commercial reprint please contact the author for authorization , Non-commercial reprint please indicate the source .