“

For a long time, there was no clear distinction between RPC (Remote Procedure Call) and HTTP calls. You write a service and invoke it on the client side. Here please allow me one of the fans to laugh ~Naive!

This article briefly introduces the two forms of C/S architecture. The most essential difference between them is that RPC is mainly based on TCP/IP, while HTTP services are mainly based on HTTP protocol.

We all know that HTTP is on top of TCP, so when it comes to efficiency, RPC is definitely better. Let’s talk more specifically about RPC services and HTTP services.

OSI network seven-layer model

Before I talk about the difference between RPC and HTTP, I think it’s worth looking at the OSI’s seven-tier network architecture model (although in practice it’s almost always five-tier).

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

  • The first layer: application layer. Defines the interfaces used to communicate and transfer data over the network.
  • The second layer: presentation layer. Define data transmission format, encoding and decoding specifications for different systems.
  • The third layer: the session layer. Manage users’ sessions and control the establishment and interruption of logical connections between users.
  • Fourth layer: transport layer. Manages end-to-end data transfer over the network.
  • Layer 5: the network layer. Define how data is transferred between network devices.
  • Sixth layer: link layer. The data 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 basically just transferring the binary data.

In practical application, there is no presentation layer and session layer in the five-layer protocol structure. I should say they merge with the application layer.

We should focus on the application layer and the transport layer. Because HTTP is the application layer protocol and TCP is the transport layer protocol.

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

The RPC service

RPC services are introduced from three perspectives, namely:

  • * * * * the RPC architecture
  • ** Synchronize asynchronous calls **
  • The 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.

Respectively is:

  • **Client

    **
  • **Server

    **
  • **Client Stub

    **
  • Server Stub (Stub) Server Stub (Stub)

Talk about each of these components:

  • The Client, the caller of the service.
  • The Server, the true service provider.
  • The client stub stores the server’s address message, and then packages the client’s request parameters 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 the efficiency advantage is very important. At this time, the advantage of RPC is relatively obvious. This is done in real development, and projects are typically managed using Maven.

For example, we have an order processing system services, to declare all of its Interface (here is the specific refers to the Interface in Java), then the whole project packaged as a jar package, the server side to introduce the two party libraries, and then realize the corresponding function, the client side and you just need to introduce the second party libraries call.

Why do you do that? The main reason is to reduce the size of the JAR package on the client side, because too many JARs are always inefficient in each package release. In addition, the client and server are decoupled to improve the portability of the code.

Synchronous invocation versus asynchronous invocation

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

Asynchronous invocation is when 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 the callback function, etc. If the client does not care about the result, it can become a one-way call.

This process is a little similar to the Callable and Runnable interfaces in Java. When we conduct asynchronous execution, if we need to know the result of execution, we can use the Callable interface, and we can get the result information of asynchronous execution through the Future class.

If you don’t care about the result of the execution, you can simply use the Runnable interface, because it doesn’t return the result. Of course, Callable is also possible, so we don’t need to fetch the Future.

The popular RPC framework

There are many popular open source RPC frameworks. Three are highlighted below:

① GRPC is Google recently announced open source software, based on the latest HTTP2.0 protocol, and supports many common programming languages.

As we all know, HTTPS 2.0 is an updated version of the HTTP protocol based on the binary protocol, and browsers are working fast to support it.

This RPC framework is based on HTTP protocol implementation, the underlying use of Netty framework support.

Thrift is an open source project of Facebook that is primarily a cross-language service development framework. It has a code generator that automatically generates a service code skeleton for the IDL definition file it defines.

As long as the user does secondary development before it, it is transparent to the underlying RPC communication and so on. But there is a cost to the user of learning the domain-specific language feature.

Dubbo is a famous open source RPC framework of Ali Group, which is widely used in many Internet companies and enterprise applications. Its distinctive feature is that both the protocol and the serialization framework can be pluggable.

The same remote Interface is based on the Java Interface and relies on the Spring framework for easy development. It can be conveniently packaged into a single file and run by independent processes, which is consistent with the current concept of micro-services.

The HTTP service

In fact, a long time ago, my model for enterprise development was defined as HTTP interface development, or what we call RESTful style service interfaces.

Indeed, in the case of few interfaces and fewer system-to-system interactions, it is a communication method often used to solve the problem of information island in the early stage. The advantages are simplicity, directness, and ease of development.

Use the existing HTTP protocol for the transport. We remember that when I was an undergraduate intern doing backstage development in the company, my main task was to develop interfaces, and I had to write a large document of interfaces, which clearly indicated what the input and output were. Explain the request method of each interface and the matters needing attention to request parameters.

Take the following example:

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

The interface might return a JSON string or an XML document. The client can then process the returned information so that development can proceed relatively quickly.

But for large enterprises, internal subsystems more, interface is very many cases, the benefits of RPC framework is shown, the first is long link, do not have to be like HTTP every communication to go to 3 times what handshake, reduce network overhead.

Secondly, RPC framework generally has a registry, there is a wealth of monitoring management; Publishing, offline interfaces, dynamic extensions, etc., are nonsensical, unified operations to callers.

conclusion

There are a number of differences between RPC services and HTTP services. In general, RPC services are targeted at large enterprises, while HTTP services are targeted at small businesses because RPC is more efficient and HTTP service development is more iterative.

In short, the choice of the framework is not based on what is popular in the market, but 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 the most suitable for the project.

It is important not to use RPC on every project just to use RPC, but rather to adapt it on a case-by-case basis.