For a long time, I haven’t figured out the difference between RPC (remote procedure call) and HTTP call. Isn’t it that a service is written and called on the client? Here, please allow one of my fans to laugh ~ naive!
This paper briefly introduces the two forms of C / S architecture. First, the most essential difference between them is that RPC is mainly based on TCP / IP protocol, while HTTP service is mainly based on HTTP protocol.
We all know that HTTP protocol is above the transport layer protocol TCP, so in terms of efficiency, RPC is certainly better! Let’s talk about RPC services and HTTP services.
OSI network seven layer model
Before talking about the difference between RPC and HTTP, I think it is necessary to understand the seven layer network structure model of OSI (although it is basically five layers in practical application).
It can be divided into the following layers: (from top to bottom)
- Layer 1: application layer.The interface for communication and data transmission in the network is defined.
- Second layer: represents the layer.Define the data transmission format, encoding and decoding specifications in different systems.
- The third layer: session layer.Manage user sessions and control the establishment and interruption of logical connections between users.
- Layer 4: transport layer.Manage the end-to-end data transmission in the network.
- Layer 5: network layer.Defines how data is transferred between network devices.
- Layer 6: link layer.The data packets of the above network layer are encapsulated into data frames to facilitate physical layer transmission.
- Layer 7: physical layer.This layer mainly transmits these binary data.
In practical application, there is no presentation layer and session layer in the five layer protocol structure. It should be said that they are merged with the application layer.
We should focus on the application layer and transport layer. Because HTTP is an application layer protocol and TCP is a transport layer protocol.
OK, after knowing the layered model of the network, we can better understand why RPC services are nice compared with HTTP services!
RPC services are introduced from three perspectives:
- **RPC architecture
- **Synchronous asynchronous call
- Popular RPC framework
Let’s talk about the basic architecture of RPC service first. We can clearly see that a complete RPC architecture contains four core components.
- **Client Stub
- Server stub (this stub can be understood as stub)
Talk about these components:
- Client,The caller of the service.
- Server,A real service provider.
- Client stub,Store the address message of the server, package the request parameters of the client into a network message, and then send it to the server remotely through the network.
- The server stub receives the message sent by the client, unpacks the message, and calls the local method.
RPC is mainly used in large enterprises, because large enterprises have many systems, complex business lines and very important efficiency advantages. At this time, the advantages of RPC are more obvious. This is done in the actual development. The project is generally managed by Maven.
For example, we have a system service for processing orders. We first declare all its interfaces (specifically, the interface in Java), and then package the whole project into a jar package. The server side introduces the second-party library, and then implements the corresponding functions. The client side only needs to introduce the second-party library to call.
Why? The main purpose is to reduce the size of jar packages on the client side, because too many jar packages will always affect the efficiency when packaging and publishing. In addition, the client and server are decoupled to improve the portability of the code.
Synchronous call and asynchronous call
What is a synchronous call? What is an asynchronous call? Synchronous call means that the client waits for the call to complete and return the result.
Asynchronous call means that the client does not wait for the return result after the call is completed, but can still receive the notification of the return result through callback functions. If the client does not care about the result, it can become a one-way call.
This process is somewhat similar to the callable and runnable interfaces in Java. When we perform asynchronous execution, if we need to know the execution result, we can use the callable interface and obtain the result information of asynchronous execution through the future class.
If you don’t care about the execution results, just use the runnable interface directly, because it doesn’t return results. Of course, callable is also OK. We don’t need to get the future.
Popular RPC framework
At present, there are many popular open source RPC frameworks. The following focuses on three types:
①gRPCIt is an open source software recently released by Google, based on the latest HTTP 2 0 protocol and supports many common programming languages.
We know http2 0 is an upgraded version of HTTP protocol based on binary. At present, major browsers are speeding up to support it.
This RPC framework is implemented based on HTTP protocol, and the underlying layer uses the support of netty framework.
②ThriftIt is an open source project of Facebook, mainly a cross language service development framework. It has a code generator to automatically generate the service code framework for the IDL definition file it defines.
As long as the user carries out secondary development before it, it is transparent to the underlying RPC communication. However, for users, they need to learn domain specific languages, which still has a certain cost.
③DubboIt is a well-known open source RPC framework of Alibaba group, which is widely used in many Internet companies and enterprise applications. Protocol and serialization framework are pluggable, which is its distinctive feature.
The same remote interface is based on java interface and relies on spring framework to facilitate development. It can be easily packaged into a single file and run independently, which is consistent with the current concept of microservice.
In fact, a long time ago, my model for enterprise development was always characterized as HTTP interface development, that is, what we often call restful service interface.
Indeed, in the case of few interfaces and less interaction between systems, it is a communication means often used in the early stage of solving information island; The advantages are simple, direct and convenient development.
Use the ready-made HTTP protocol for transmission. We remember that when the undergraduate internship was doing background development in the company, it was mainly to develop the interface, and write a large interface document to strictly indicate what the input and output are? Explain clearly the request method of each interface and the matters needing attention to the request parameters.
For example, the following example:
The interface may return a JSON string or an XML document. Then the client can process the returned information, so that the development can be carried out more quickly.
However, for large enterprises, when there are many internal subsystems and interfaces, the benefits of RPC framework are shown. The first is long links. It is not necessary to shake hands three times every time, like HTTP, which reduces network overhead.
Secondly, RPC framework generally has a registry and rich monitoring management; Publishing, offline interface, dynamic extension, etc. are insensitive and unified operations for the caller.
There are still many differences between RPC services and HTTP services. Generally speaking, RPC services are mainly for large enterprises, while HTTP services are mainly for small enterprises, because RPC is more efficient and HTTP service development iteration will be faster.
In short, what kind of framework is selected is not determined according to what is popular in the market, but to conduct a complete evaluation of the whole project, so as to carefully compare the impact of the two development frameworks on the whole project, and finally decide what is most suitable for the project.
You must not use RPC for every project in order to use RPC. Instead, you should make specific analysis according to local conditions.