Source: CSDN, Author: wangyunpeng0319
Link: https://blog.csdn.net/wangyunpeng0319/article/details/78651998
For a long time, I haven’t really clarified the differences between RPC (Remote Procedure Call) and HTTP calls. Aren’t they just about writing a service and calling it from the client? Please allow me to chuckle at my naivety! This article briefly introduces the two forms of C/S architecture, starting with their fundamental difference: RPC is primarily based on the TCP/IP protocol, while HTTP services are based on the HTTP protocol. We know that the HTTP protocol operates on top of the transport layer protocol TCP, so in terms of efficiency, RPC certainly has the upper hand! Let’s discuss RPC services and HTTP services in detail.
OSI Seven-Layer Network Model
Before discussing the differences between RPC and HTTP, I think it’s necessary to understand the OSI seven-layer network model (although in practical applications, it is mostly five layers). It can be divided into the following layers (from top to bottom):
- Layer 1: Application Layer. Defines the interface for communication and data transmission over the network;
- Layer 2: Presentation Layer. Defines the data transmission format, encoding, and decoding standards between different systems;
- Layer 3: Session Layer. Manages user sessions and controls the establishment and termination of logical connections between users;
- Layer 4: Transport Layer. Manages end-to-end data transmission across the network;
- Layer 5: Network Layer. Defines how data is transmitted between network devices;
- Layer 6: Link Layer. Encapsulates the data packets from the network layer into data frames for physical layer transmission;
- Layer 7: Physical Layer. This layer is primarily responsible for transmitting binary data.
In practical applications, the five-layer protocol structure does not include the presentation and session layers. They are generally merged with the application layer. We should focus on the application layer and transport layer, as HTTP is an application layer protocol, while TCP is a transport layer protocol. Now that we understand the layered model of the network, we can better comprehend why RPC services are generally more efficient than HTTP services!
RPC Services
Let’s introduce RPC services from three perspectives: RPC architecture, synchronous and asynchronous calls, and popular RPC frameworks.
RPC Architecture
First, let’s discuss the basic architecture of RPC services. Allow me to shamelessly borrow a diagram~ We can clearly see that a complete RPC architecture consists of four core components: Client, Server, Client Stub, and Server Stub. You can think of this Stub as a placeholder. Let’s discuss these components:
- Client: The caller of the service.
- Server: The actual service provider. The client stub holds the address message of the server and packages the client’s request parameters into network messages, which are then sent to the server over the network. The server stub receives the messages sent by the client, unpacks them, and calls the local methods.
RPC is mainly used in large enterprises because they have numerous systems and complex business lines, where efficiency is crucial. In actual development, projects typically use Maven for management.For example, we have a service for processing orders. First, we declare all its interfaces (specifically referring to interfaces in Java), then package the entire project into a JAR file. The server side imports this library and implements the corresponding functionality, while the client side only needs to import this library to make calls.Why do we do this? Mainly to reduce the size of the JAR file on the client side, as having too many JAR files can affect efficiency during each packaging and release. Additionally, it decouples the client and server, improving code portability.
Synchronous and Asynchronous Calls
What is a synchronous call? What is an asynchronous call? A synchronous call means the client waits for the call to complete and return a result. An asynchronous call means the client does not wait for the call to complete but can still receive notifications of the returned result through callback functions. 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 execution result, we can use the callable interface and obtain the result information through the Future class. If we do not care about the execution result, we can directly use the runnable interface, as it does not return a result. Of course, callable can also be used if we do not retrieve the Future.
Popular RPC Frameworks
Currently, there are several popular open-source RPC frameworks. Here are three key ones:gRPC is an open-source software recently released by Google, based on the latest HTTP/2.0 protocol and supports many common programming languages. We know that HTTP/2.0 is a binary-based upgrade of the HTTP protocol, and major browsers are rapidly adopting it. This RPC framework is implemented based on the HTTP protocol and uses the Netty framework at its core.Thrift is an open-source project from Facebook, primarily a cross-language service development framework. It has a code generator that automatically generates service code frameworks from its defined IDL files. Users only need to perform secondary development on it, as the underlying RPC communication is transparent. However, this requires users to learn a specific domain language, which has some associated costs.Dubbo is a well-known RPC framework open-sourced by Alibaba Group, widely used in many internet companies and enterprise applications. Its distinctive feature is the pluggable protocol and serialization framework. The remote interface is based on Java Interface and relies on the Spring framework for easy development. It can be conveniently packaged into a single file and run as an independent process, aligning with the current microservices concept.
HTTP Services
In the past, I always characterized enterprise development patterns as HTTP interface development, commonly known as RESTful style service interfaces. Indeed, for cases with few interfaces and limited system interactions, this was a communication method often used to solve information silos in the early stages; its advantages are simplicity, directness, and ease of development.Using the existing HTTP protocol for transmission, I remember during my undergraduate internship when I was doing backend development, I mainly focused on interface development and had to write a large interface document, clearly specifying the inputs and outputs, detailing each interface’s request methods, and noting important considerations for request parameters.
For example, the following:POST http://www.httpexample.com/restful/buyer/info/shar
The interface might return a JSON string or an XML document. The client then processes this returned information, allowing for relatively quick development.However, for large enterprises with many internal subsystems and numerous interfaces, the benefits of RPC frameworks become apparent. First, long connections eliminate the need for the three-way handshake like HTTP, reducing network overhead;Secondly, RPC frameworks generally have a registration center with rich monitoring and management capabilities; publishing, decommissioning interfaces, and dynamic expansion are all perceived as unified operations by the caller.
Conclusion
RPC services and HTTP services have many differences. Generally, RPC services are aimed at large enterprises, while HTTP services are more suited for small businesses, as RPC is more efficient, while HTTP service development iterations are faster.In summary, the choice of framework should not be based on what is popular in the market, but rather on a comprehensive evaluation of the entire project, carefully comparing the impact of the two development frameworks on the project before deciding which is most suitable. One should not use RPC for every project simply because it exists; instead, one should adapt to the specific situation and analyze it accordingly.—END—