Why do we need RPC when we have HTTP?

This article briefly introduces the two forms of C/S architecture. First, let's talk about their most essential difference. RPC is mainly based on TCP/IP protocol, while HTTP service is mainly based on HTTP protocol. We all know that HTTP protocol is based on the transport layer protocol TCP, so in terms of efficiency, RPC is of course better! Let's talk about RPC service and HTTP service in detail.

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 in actual applications it is basically five layers), which can be divided into the following layers: (from top to bottom)

• Layer 1: Application layer. Defines the interface used to communicate and transmit data in the network;
• The second layer: presentation layer. Defines the data transmission format, encoding and decoding specifications in different systems;
• Layer 3: Session layer. Manages user sessions and controls the establishment and interruption of logical connections between users;
• Layer 4: Transport layer. Manages end-to-end data transmission in the network;
• Layer 5: Network layer. Defines how data is transmitted between network devices;
• Layer 6: Link layer. Encapsulates the data packets of the network layer above into data frames for transmission at the physical layer;
• Layer 7: Physical layer. This layer is mainly used to transmit these binary data.

In actual 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, after knowing the layered model of the network, we can better understand why RPC service is nicer than HTTP service!

RPC Service

This paper introduces RPC services from three perspectives: RPC architecture, synchronous and asynchronous calls, and popular RPC frameworks.

RPC Architecture

Let's talk about the basic architecture of the RPC service first. Allow me to shamelessly steal a picture. We can clearly see that a complete RPC architecture contains four core components, namely Client, Server, Client Stub and Server Stub. Stub can be understood as a stub. Let's talk about these components separately:

• Client, the caller of the service
• Server, the real service provider

The client stub stores the server's address information, packages the client's request parameters into a network message, and then sends it remotely to the service provider through the network.

The server stub receives messages sent by the client, unpacks the messages, and calls local methods.

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

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

Why do this? Mainly to reduce the size of the jar package on the client side, because every time you package and publish, too many jar packages will always affect efficiency. In addition, it is also to decouple the client and the server to improve the portability of the code.

Synchronous and asynchronous calls

What is a synchronous call? What is an asynchronous call? A synchronous call is when the client waits for the call to complete and return a result. An asynchronous call is when the client does not wait for the call to complete and return a result, but can still receive notification of the return result through a callback function. 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 result of the execution, we can use the callable interface, and we can get the result information of the asynchronous execution through the Future class. If we don't care about the result of the execution, we can directly use the runnable interface, because it does not return the result. Of course, callable is also possible, and we don't need to get Future.

Popular RPC Frameworks

There are many popular open source RPC frameworks. Here are three of them:

• gRPC is an open source software recently released by Google. It is 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. Currently, major browsers are working hard to support it. This RPC framework is implemented based on the HTTP protocol and uses the support of the Netty framework at the bottom layer.
• Thrift is an open source project of Facebook, mainly a cross-language service development framework. It has a code generator to automatically generate a service code framework for the IDL definition file it defines. Users only need to perform secondary development before it, and the underlying RPC communication is transparent. However, this still has a certain cost for users to learn the feature of a specific domain language.
• Dubbo is a well-known RPC framework open sourced by Alibaba Group and widely used in many Internet companies and enterprise applications. The pluggable protocol and serialization framework are its distinctive features. The same remote interface is based on Java Interface and relies on the spring framework for easy development. It can be easily packaged into a single file and run as an independent process, which is consistent with the current concept of microservices.

HTTP Services

In fact, a long time ago, I have always defined the enterprise development model as HTTP interface development, which is what we often call RESTful style service interface. Indeed, it is a communication method often used to solve the problem of information islands in the early stage when there are not many interfaces and few interactions between systems; its advantages are simplicity, directness and easy development.

Use the existing http protocol for transmission. We remember that when we were doing background development in the company during our undergraduate internship, we mainly developed interfaces and wrote a large interface document to strictly indicate what the input and output are? We also explained the request method of each interface and the matters that need to be paid attention to 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, and the client will then process the returned information, allowing for faster development.

However, for large enterprises with many internal subsystems and interfaces, the advantages of the RPC framework become apparent. The first is long links, which eliminates the need for three handshakes like HTTP for every communication, thus reducing network overhead. Secondly, the RPC framework generally has a registration center with rich monitoring management. Publishing, offline interfaces, dynamic expansion, etc. are all seamless and unified operations for the caller.

Summarize

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 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, so as to carefully compare the impact of the two development frameworks on the entire project, and finally decide which is the most suitable for the project. You must not use RPC for every project just for the sake of using RPC, but should adapt to local conditions and analyze specific situations.