For a long time it was difficult to make a clear distinction between Remote Procedure calls (RPC) and HTTP calls. Please allow me to be Naive!

This article briefly introduces the two forms of C/S architecture, starting with the essential differences between them. RPC is primarily based on TCP/IP, while HTTP services are primarily based on HTTP.

We all know that HTTP is superior to TCP, so RPC is definitely superior in terms of efficiency. 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 taking a look at OSI’s seven-tier network architecture (although in practice it’s almost always five-tier).





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

Layer 1: application layer. Defines interfaces for communicating and transferring data over a network. Layer 2: Presentation layer. Define data transmission formats, encoding and decoding specifications in different systems. The third layer: the session layer. Manage user sessions and control the establishment and interruption of logical connections between users. The fourth layer: transport layer. Manages end-to-end data transfer across the network. Layer 5: network layer. Defines how data is transferred between network devices. Layer 6: link layer. Packets at the network layer are encapsulated into data frames for easy transmission at the physical layer. Layer 7: Physical layer. This layer is all about transferring binary data.





In practice, 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 an application layer protocol and TCP is a transport layer protocol.

Now that we know the layered model of the network we can better understand why RPC services are nicer than HTTP services!

The RPC service

RPC services are introduced from three perspectives:

  • RPC architecture
  • Synchronous asynchronous call
  • Popular RPC framework
  • 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
  • The Server Stub (which is known as a Stub)
  • Tell us about these components separately:

A Client is the caller of a service. A Server is a real service provider. Client stubs that store server address messages and package client request parameters into network messages that are sent to the server remotely over the network. The server stub receives the message sent from the client, unpacks the message, and invokes local methods. RPC is mainly used in large enterprises, because large enterprises have many systems and complex business lines, and the efficiency advantage is very important. At this time, THE advantage of RPC is more obvious. This is done in real development, where projects are generally 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 purpose is to reduce the size of the jar packages on the client side, because every time a package is released, too many JARS will always affect efficiency. It also decouples the client and server to improve the portability of the code.

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

An asynchronous call is one in which the client does not wait for the call to complete and return the result, but can still receive notification of the return result through callback functions, etc. If the client doesn’t care about the result, it can become a one-way call.

This process is similar to the Callable and Runnable interfaces in Java. If we need to know the result of an asynchronous execution, we can use the Callable interface and obtain the result of an asynchronous execution through the Future class.

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

Popular RPC frameworks There are quite a few popular open source RPC frameworks. Here are three:

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

We know that HTTP2.0 is a binary based update to the HTTP protocol, which is currently being rapidly supported by browsers.

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

(2) Thrift is an open source project of Facebook, which is primarily 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.

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

③Dubbo is an open source RPC framework of Alibaba Group, which is widely used in many Internet companies and enterprise applications. Pluggable protocols and serialization frameworks 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 as a single file and run as a separate process, consistent with the current concept of microservices.

The HTTP service

In fact, long ago, I defined the mode of enterprise development as HTTP interface development, which is often referred to as RESTful service interface.

Indeed, in the case of few interfaces and less system-to-system interaction, it is a communication means often used to solve the early stage of information islands; The advantages are simplicity, directness and ease of development.

Use the existing HTTP protocol for transport. We remember that when I was doing background development in the company during my undergraduate internship, I was mainly engaged in interface development, and I had to write a large interface document to strictly indicate what the input and output were. Make clear the request method of each interface, and the matters needing attention of request parameters, etc.

Take this example:

POST http://www.httpexample.com/restful/buyer/info/shar
Copy the code

The interface may return a JSON string or an XML document. The returned information is then processed by the client, allowing for faster development.

However, for large enterprises with a large number of internal subsystems and interfaces, the benefits of RPC framework will be shown. The first is the long link, which does not require three handshakes like HTTP for each communication, reducing the network overhead.

Secondly, RPC frameworks generally have registries and rich monitoring management. Publishing, offline interfaces, dynamic extensions, etc., are unaware and unified operations for callers.

conclusion

There are many differences between RPC services and HTTP services. Generally speaking, RPC services are mainly targeted at large enterprises, while HTTP services are mainly targeted 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 overall project, and finally decide what is best for the project.

Make sure you don’t use RPC for every project just to use IT.