Shulou(Shulou.com)06/01 Report--

This article mainly introduces RPC and RESTful which is better related knowledge, the content is detailed and easy to understand, the operation is simple and fast, and it has certain reference value. I believe everyone will gain something after reading this RPC and RESTful article. Let's take a look at it together.

RPC is mainly based on TCP/IP protocol, while HTTP service is mainly based on HTTP protocol. We all know that HTTP protocol is above TCP protocol, so RPC is of course better in terms of efficiency! Let's talk about RPC services and HTTP services in detail.

OSI Seven-Layer Model

Before I talk about the difference between RPC and HTTP, I think it is necessary to understand OSI's seven-layer network architecture model (although in practice it is basically five layers), which can be divided into the following layers: (top to bottom)

Level 1: Application Level. defines interfaces for communicating and transmitting data in the network;

Second layer: presentation layer. Define data transmission formats, coding and decoding specifications for different systems;

Level 3: Conversation Level. Manage user sessions and control the establishment and interruption of logical connections between users;

Level 4: Transport Layer. manages end-to-end data transmission in the network;

Level 5: Network layer. Define how data is transmitted between network devices;

Level 6: Link layer. encapsulating the data packets of the upper network layer into data frames for physical layer transmission;

Level 7: Physical layer. This layer is mainly used to transmit 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. HTTP is an application-layer protocol and TCP is a transport-layer protocol. Now that we know the hierarchical model of the network, we can better understand why RPC services are nicer than HTTP services!

RPC service

RPC services are introduced from three perspectives: RPC architecture, synchronous asynchronous invocation, and 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, namely Client ,Server,Client Stub and Server Stub. Tell us about these components:

Client: The caller of the service.

Server, the real service provider.

The client stub stores the address message of the server, 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 in large enterprises, the business line is complex, and the efficiency advantage is very important. At this time, the advantages of RPC are obvious. This is done in actual development, and projects are generally managed using maven. For example, we have a system service for processing orders, first declare all its interfaces (here specifically, the interface in Java), and then package the whole project into a jar package. The server side introduces this binary library, and then implements the corresponding functions. The client side only needs to introduce this binary library to invoke it. Why would you do that? This is mainly to reduce the jar package size on the client side, because too many jars will always affect efficiency every time you package and publish. It also decouples client and server to improve portability of code.

Synchronous versus asynchronous invocation

What is synchronous invocation? What is asynchronous invocation? A synchronous call is when the client waits for the call to complete and returns the result. Asynchronous call means that the client does not wait for the call to complete the execution and return the result, but can still receive the notification of the return result through the callback function. If the client doesn't care about the result, it can become a one-way call. This process is a bit similar to the callable and runnable interfaces in Java. When we execute asynchronously, 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 execution, you can use the runnable interface directly, because it doesn't return results. Of course, callable is also possible. We don't need to get Future.

Popular RPC frameworks

There are still a lot of popular RPC frameworks. Three are highlighted below:

gRPC is Google's recently announced open source software, based on the latest HTTP 2.0 protocol and supporting many common programming languages. We know that HTTP 2.0 is an upgraded version of the HTTP protocol based on binary, and currently all major browsers are rushing 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 for Facebook, primarily a cross-language service development framework. It has a code generator to automatically generate service code frameworks for IDL definition files it defines. As long as the user carries out secondary development before it, it is transparent to the underlying RPC communication. However, for users, it is necessary to learn this feature of a specific domain language, or there is a certain cost.

Dubbo is a well-known RPC framework open source by Alibaba Group, which is widely used in many Internet companies and enterprise applications. Both protocols and serialization frameworks are pluggable and feature prominently. The same remote interface is based on Java Interface and relies on the Spring framework for ease of development. It can be easily packaged into a single file and run independently, consistent with the current concept of microservices.

HTTP service

In fact, a long time ago, my pattern for enterprise development has been characterized as HTTP interface development, which is often referred to as RESTful style service interface. Indeed, in the case of few interfaces and less interaction between systems, it is a communication means often used in the early stage of solving information islands; the advantages are simple, direct and convenient development. Use the existing http protocol for transmission. We remember that before the undergraduate internship in the company to do background development, mainly for interface development, but also to write a large interface document, strictly indicate what the input and output is? Clarify the request method for each interface, as well as matters needing attention for request parameters.

An interface may return a JSON string or an XML document. The client then processes the returned information, allowing for faster development. However, for large enterprises, there are many internal subsystems and many interfaces. The benefits of RPC framework are shown. First, long links do not have to be shaken three times like http every time, reducing network overhead. Secondly, RPC frameworks generally have a registry and rich monitoring management. Publishing, offline interfaces, dynamic extensions, etc. are non-aware and unified operations for callers.

About "RPC or RESTful which is better" The content of this article is introduced here, thank you for reading! I believe everyone has a certain understanding of "RPC or RESTful which is better" knowledge. If you still want to learn more knowledge, please pay attention to the industry information channel.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.