For a long time, I didn’t quite understand the difference between RPC (Remote Procedure Call) and HTTP calls. Aren’t they just about writing a service and calling it from the client? Allow me to chuckle at my naivety!
Image from Pexels
This article briefly introduces two forms of C/S architecture, starting with their fundamental differences: RPC is primarily based on the TCP/IP protocol, while HTTP services are based on the HTTP protocol.
We all know that the HTTP protocol operates on top of the transport layer protocol TCP, so in terms of efficiency, RPC is certainly superior! Let’s discuss RPC services and HTTP services in detail.
OSI Network Layer 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 across 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: Data Link Layer. Encapsulates the packets from the network layer into 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 network layering model, we can better comprehend why RPC services are generally more efficient than HTTP services!
RPC Services
RPC services can be introduced from three perspectives:
-
RPC Architecture
-
Synchronous and Asynchronous Calls
-
Popular RPC Frameworks
RPC Architecture
Let’s first discuss the basic architecture of RPC services. We can clearly see that a complete RPC architecture consists of four core components.
They are:
-
Client
-
Server
-
Client Stub
- Server Stub (this Stub can be understood as a placeholder)
Let’s discuss these components:
-
Client, the caller of the service.
-
Server, the actual service provider.
-
Client Stub, stores the address message of the server and packages the client’s request parameters into a network message, which is then sent to the server remotely.
-
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. The advantages of RPC become apparent in such scenarios. In actual development, projects typically use Maven for management.
For example, if we have a system service for processing orders, we first declare all its interfaces (specifically referring to Java interfaces), 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? The main reason is 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 and return a result, 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; we just won’t retrieve the Future.
Popular RPC Frameworks
Currently, there are quite a few 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 same remote interface is based on Java interfaces and relies on the Spring framework for easy development. It can be conveniently packaged into a single file, run as an independent process, and aligns with the current microservices concept.
HTTP Services
Actually, a long time ago, I characterized the enterprise development model as HTTP interface development, which is what we commonly refer to as RESTful style service interfaces.
Indeed, in cases where there are not many interfaces and system interactions are limited, it is 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, strictly specifying the inputs and outputs, clarifying each interface’s request methods, and noting the important aspects of 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 evident. Firstly, they maintain long connections, eliminating the need for the three-way handshake required by HTTP for each communication, thus reducing network overhead.
Secondly, RPC frameworks generally have a registration center with rich monitoring and management capabilities; publishing, taking down interfaces, and dynamic expansion are all perceived as unified operations by the caller.
Conclusion
RPC services and HTTP services have many differences. Generally speaking, RPC services are mainly for 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 both development frameworks on the project before deciding which is most suitable.
One should not use RPC for every project just because it exists; rather, one should adapt to the specific situation and analyze it accordingly.
Author:Fu Sheng Yi Meng
Editor: Tao Jialong
Source: https://tinyurl.com/y4o875zm
Recommended Articles:
Performance optimization not done on the online system, and it crashed…How impressive is Taobao’s high availability multi-active architecture?Another “delete database and run away”: Programmer angrily deleted code, sentenced to 5 months