Why do you need RPC instead of simple HTTP?

1. Seven-layer network structure model:

Let's first understand the seven-layer network structure model of OSI (although it is basically five layers in practical applications), it can be divided into the following layers: (from top to bottom)

• The first layer: application layer. Defines the interfaces used to communicate and transmit data in the network;
• The second layer: presentation layer. Define data transmission formats, encoding and decoding specifications, etc. in different systems;
• The third layer: session layer. Manage user sessions, control the establishment and interruption of logical connections between users;
• The fourth layer: transport layer. Manages end-to-end data transmission in the network;
• The fifth layer: the network layer. Define how to transmit data between network devices;
• The sixth layer: link layer. Encapsulate the data packets of the above network layer into data frames to facilitate physical layer transmission;
• Seventh layer: physical layer. This layer is mainly to transmit these binary data.

In the actual application process, 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 two levels of application layer and transport layer. Because HTTP is an application layer protocol, while TCP is a transport layer protocol. Well, after knowing the layered model of the network, we can better understand why RPC services are nicer than HTTP services!

2. HTTP service:

In fact, a long time ago, my mode of enterprise development has always been defined as HTTP interface development, which is what we often call RESTful-style service interfaces. Indeed, when there are not many interfaces and less interaction between systems and systems, it is a communication method that is often used in the initial stage of solving information islands; the advantages are simple, direct, and convenient development. Use the ready-made http protocol for transmission. We remember that when we were doing background development in the company as an intern, the main thing was to develop the interface, and we had to write a large interface document to strictly indicate what the input and output were? Explain clearly the request method of each interface and the matters needing attention for the request parameters. For example, the following example:

POST http://www.test.com/restful/user/info

The interface may return a JSON string or an XML document. Then the client will process the returned information, so that development can be carried out relatively quickly. But for large enterprises, when there are many internal subsystems and many interfaces, the benefits of the RPC framework are revealed. The first is long links. It is not necessary to shake hands three times like HTTP every time. Reduced network overhead; secondly, the RPC framework generally has a registration center with rich monitoring and management; release, offline interface, dynamic expansion, etc., are non-perceptual and unified operations for the caller.

3. RPC architecture:

A complete RPC architecture contains four core components, namely Client, Server, Client Stub and Server Stub. This Stub can be understood as a stub. Let’s talk about these components separately:

• Client (Client), the caller of the service.
• Server (Server), the real service provider.
• The client stub stores the address information of the server, and then packs the request parameters of the client into a network message, and then sends 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.
  
  4. When PRC is needed:

Let's take a look at what happens when there is no RPC:

This was the case in the past, and it may be the case for many enterprise services now, only one package is deployed in the web server.

At that time, there were no scenarios that needed to use RPC.

And what about when the number of users is large? Gradually there is load balancing. It is roughly like this:

load balancing can solve many problems, but it is not good enough. For example, only a certain functional module (assuming it is the user center) is accessed very frequently. Can I take this part out separately? ? The machine in the user center is independent, give it a separate bandwidth, give him a separate server, and give him a separate database?
If you don't do this, other functional modules can't go on.

Take the school cafeteria as an example:

The school restaurant can accommodate 500 people to eat at the same time, but there is a noodle restaurant, the business is particularly good, every time there are 2,000 people who come to eat, occupying the table, and the queue is hundreds of meters. The other stalls in the restaurant are definitely not happy. right?

For example, the dumpling seller, although dozens of people come to eat every day. That's money too. You have so many people, people who want to eat at my place can’t squeeze in,

Probably the situation is like this:
can you understand it like this?

What should I do in such a situation? It is impossible not to let the noodle shop open for business, so the best way is:

"Can you move out?"

If you don't want to move, we can move! (Crying face, anyway, we will never open with your noodle shop again, we must give us an explanation)

So, it might look like this after the move.

Hmm. The points are separated, and the meal cards and the like are still together, and they are still the same as other windows, providing everyone with the function of dining. This is divide and conquer. Even if your noodle shop is closed, it will not affect me. This is also called distributed. (“Distributed” is highlighted)

When it comes to distributed, the problem comes.
Can they call each other? In fact, subdividing it down, buying vegetables, cutting vegetables, and checking out are all independent processes. Can we separate them all?
Of course it is possible, but the question is, how to communicate? Everyone is not in the same process.
This method of communication is called RPC. Today, RPC is not just remote. To be precise, remote means that it is not in a process and can only be completed through other protocols, usually TCP or Http.
Well, now that RPC is clear, let's see what the point of RPC is.
Can't be too slow, right? What if it's too slow?
To what extent should this performance requirement be achieved? I hope it is a consistent experience with being in the same process.
Can Http do this?
no. The three-way handshake protocol of Http (TCP) itself will bring a delay of about 1MS (emmm, I am actually a little uncertain about this data, it may be a few microseconds, and I did a test a long time ago).
Every time a request is sent, there will be a process of establishing a connection. In addition to the huge size of the Http message itself and the huge size of Json, some optimization is required.
In general scenarios, there is no problem, but for a company of Google's level, they cannot accept it.
A delay of a few MS may lead to tens of thousands of extra servers, so they try their best to optimize. Where should the optimization start?
1. Reduce the amount of transmission.
2. Simplify the protocol.
3. Use a long connection instead of re-going through the three-way handshake process for every request.
The Http protocol is doomed. Under the high performance requirements, it is not suitable for use as a communication protocol for mutual use between online distributed services.

V. Summary

There are still many differences between RPC services and HTTP services. Generally speaking, RPC services are mainly aimed at large enterprises, while HTTP services are mainly aimed at small enterprises, because RPC is more efficient, and HTTP service development iterations will be faster. . In short, what kind of framework to choose is not determined by what is popular in the market, but a complete evaluation of the entire project, so as to carefully compare the impact of the two development frameworks on the entire project, and finally decide what is the most suitable for this item. Be sure not to use RPC for every project in order to use RPC, but to adapt measures to local conditions and analyze specific situations.