Why do you need RPC when you have HTTP?

Picture

It can be divided into the following layers: (from top to bottom)

? The first layer: application layer. The interface used to communicate and transmit data in the network is defined.

? The second layer: the presentation layer. Define the transmission format, encoding and decoding specifications of data in different systems.

? The third layer: the conversation layer. Manage user sessions and control the establishment and interruption of logical connections between users.

? The fourth layer: the transport layer. Manages the end-to-end data transmission in the network.

? Layer 5: network layer. Define how data is transferred between network devices.

? The sixth layer: link layer. The packets of the network layer above are encapsulated into data frames to facilitate the transmission of the physical layer.

? The seventh layer: the physical layer. This layer is mainly used to transmit these binary data.

Picture

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 the transport layer. Because HTTP is an application layer protocol and TCP is a transport layer protocol.

Well, knowing the hierarchical model of the network, we can better understand why RPC services are Nice compared to HTTP services!

RPC service

RPC services are introduced from three perspectives, which are:

? RPC architecture

? Synchronous asynchronous invocation

? Popular RPC framework

RPC architecture

Let's start with the basic architecture of RPC services. We can clearly see that a complete RPC architecture contains four core components.

They are:

? Client

? Server

? Client Stub

? Server Stub (this Stub can be understood as a stub)

Picture

Talk about these components separately:

? Client (Client), caller of the service.

? The Server, the real service provider.

? The client stub stores the address message of the server, and then packages 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.

RPC is mainly used in large enterprises, because there are many systems, complex lines of business, and efficiency advantages are very important in large enterprises. At this time, the advantage of RPC is more obvious. This is done in actual development, and projects are generally managed using Maven.

For example, if we have a system service for processing orders, first declare all its interfaces (here, it refers to Interface in Java), then package the whole project into a jar package, introduce this second-party library to the server, and then implement the corresponding function. The client side only needs to introduce this second-party library to call.

Why would you do that? The main purpose is to reduce the jar package size on the client side, because every time the package is released, too many jar packages will always affect efficiency. In addition, the client and server are decoupled to improve the portability of the code.

Synchronous and asynchronous invocation

What is a synchronous call? What is an asynchronous call? Synchronous invocation means that the client waits for the call to complete and returns the result.

An asynchronous call means that the client does not wait for the call to complete and return the result, but it can still receive the notification of the return result through callback functions and so on. If the client does not care about the result, it can become an one-way call.

This process is somewhat similar to the Callable and Runnable interfaces in Java. When we execute asynchronously, if we need to know the result of the execution, we can use the Callable interface, and the result information of asynchronous execution can be obtained through the Future class.

If you don't care about the result of the execution, you can just use the Runnable interface, because it doesn't return the result. Of course, Callable is fine, and we don't have to get the Future.

Popular RPC framework

At present, there are still many popular open source RPC frameworks. The following focuses on three categories:

1gRPC? Google is a recently released open source software based on the latest HTTP2.0 protocol and supports many common programming languages.

We know that HTTP2.0 is an upgraded version of the HTTP protocol based on binary, which is now supported by major browsers.

The RPC framework is based on the HTTP protocol, and the underlying layer uses the support of the Netty framework.

2Thrift? 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 files it defines.

Users only need to carry out secondary development before it, and it is transparent for the underlying RPC communication. However, there is a cost for users to learn domain-specific languages.

3Dubbo? Is a very famous open source RPC framework of Ali Group, which is widely used in many Internet companies and enterprise applications. Both the protocol and the serialization framework can be plugged and plugged.

The same remote interface is based on Java Interface and relies on the 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 microservices.

HTTP service

In fact, a long time ago, my pattern for enterprise development has always been defined as HTTP interface development, which is what we often call RESTful-style service interfaces.

Indeed, in the case of few interfaces and less interaction between the system and the system, it is a common means of communication to solve the information isolated island at the initial stage; the advantage is simple, direct and convenient to develop.

Make use of the ready-made HTTP protocol for transmission. We remember that before the undergraduate internship in the company to do background development, mainly to carry out interface development, but also to write a large interface document, strictly indicating what the input and output are? State clearly the request method of each interface, as well as the matters needing attention in the request parameters.

For example, the following example:

POST? http://www.httpexample.com/restful/buyer/info/shar??

The interface may return a JSON string or an XML document. The client then processes the returned information so that it can be developed more quickly.

But for large enterprises, when there are many internal subsystems and interfaces, the benefits of RPC framework are shown. First of all, long links do not have to go to three handshakes like HTTP every time, which reduces the network overhead.

Secondly, RPC frameworks generally have a registration center and rich monitoring and management; release, offline interface, dynamic expansion and so on, are imperceptible and unified operations for callers.

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 services development iterations are faster.

In short, the choice of framework is not determined by what is popular in the market, but by a complete evaluation of the entire project, in order to carefully compare the impact of the two development frameworks on the entire project, and finally decide what is best for the project.

Be sure not to use RPC for every project in order to use RPC, but to analyze the specific situation according to local conditions.