This article briefly introduces the two forms of C/S architecture. First, let's talk about their most essential difference, that is, RPC is mainly based on the TCP/IP protocol, while HTTP services are mainly based on the HTTP protocol.
We all know that the HTTP protocol is on top of the transport layer protocol TCP, so in terms of efficiency, RPC is of course better! Let's talk about RPC service and HTTP service in detail.
OSI network seven layer model
Before talking about the difference between RPC and HTTP, I think it is necessary to understand the seven-layer network structure model of OSI (although it is basically five layers in practical applications).
picture
It can be divided into the following layers: (from top to bottom)
- The first layer: application layer. Defines the interfaces used to communicate and transfer data in the network.
- The second layer: presentation layer. Define data transmission formats, encoding and decoding specifications, etc. in different systems.
- The third layer: session layer. Manage user sessions and control the establishment and termination of logical connections between users.
- The fourth layer: transport layer. Manages end-to-end data transmission in the network.
- The fifth layer: the network layer. Defines how data is transmitted between network devices.
- The sixth layer: link layer. Encapsulate the data packets of the upper network layer into data frames to facilitate physical layer transmission.
- Seventh layer: physical layer. This layer is mainly to transmit these binary data.
picture
In the actual application process, there is no presentation layer and session layer in the five-layer protocol structure. It should be said that they are merged with the application layer.
We should focus on the two levels of application layer and transport layer. Because HTTP is an application layer protocol, while TCP is a transport layer protocol.
Well, after knowing the layered model of the network, we can better understand why RPC services are nicer than HTTP services!
RPC service
Introduce the RPC service from three perspectives, namely:
- RPC architecture
- synchronous asynchronous call
- Popular RPC Frameworks
RPC architecture
Let's talk about the basic structure of RPC service first. We can clearly see that a complete RPC architecture contains four core components.
They are:
- Client
- Server
- Client Stub
- Server Stub (this Stub can be understood as a stub)
picture
Let’s talk about these components separately:
- Client (Client), the caller of the service.
- Server (Server), the real service provider.
- The client stub stores the address information of the server, and then packs 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 and complex business lines in large enterprises, and the efficiency advantage is very important. At this time, the advantages of RPC are more obvious. This is done in actual development, and projects are generally managed using Maven.
For example, if we have a system service for processing orders, first declare all its interfaces (here specifically refers to the Interface in Java), and then package the entire project into a jar package, import this second-party library on the server side, and then implement For the corresponding functions, the client only needs to introduce this second-party library to call.
Why do you do this? The main purpose is to reduce the size of the jar package on the client side, because too many jar packages will always affect the efficiency every time it is packaged and released. In addition, it also decouples the client and server to improve the portability of the code.
Synchronous calls and asynchronous calls
What is a synchronous call? What is an asynchronous call? A synchronous call means that the client waits for the call to complete and returns the result.
Asynchronous call means that the client does not wait for the call execution to complete and return the result, but it can still receive the notification of the return result through the callback function and so on. If the client doesn't 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 we can obtain the result information of the asynchronous execution through the Future class.
If you don't care about the execution result, you can just use the Runnable interface directly, because it doesn't return a result. Of course, Callable is also possible, and we don't need to get the Future.
Popular RPC Frameworks
There are still many popular open source RPC frameworks. Three are highlighted below:
① gRPC is an open source software recently released by Google, based on the latest HTTP2.0 protocol, and supports many common programming languages.
We know that HTTP2.0 is an upgraded version of the HTTP protocol based on binary, and currently all major browsers are speeding up their efforts to support it.
This RPC framework is implemented based on the HTTP protocol, and the bottom layer uses the support of the Netty framework.
②Thrift is an open source project of Facebook, mainly a cross-language service development framework. It has a code generator to automatically generate service code skeletons for the IDL definition files it defines.
Users only need to carry out secondary development before it, which is transparent to the underlying RPC communication. However, for users, it is necessary to learn the feature of domain-specific language, which still has a certain cost.
③Dubbo is an extremely well-known RPC framework open sourced by Ali Group, which is widely used in many Internet companies and enterprise applications. Both the protocol and the serialization framework are pluggable and their distinctive features.
The same remote interface is based on Java Interface, and relies on the Spring framework to facilitate development. It can be easily packaged into a single file and run in an independent process, which is consistent with the current concept of microservices.
HTTP service
In fact, a long time ago, my mode of enterprise development has always been defined as HTTP interface development, which is what we often call RESTful-style service interfaces.
Indeed, when there are not many interfaces and less interaction between systems and systems, it is a communication method that is often used in the initial stage of solving information islands; the advantages are simple, direct, and convenient development.
Use the ready-made HTTP protocol for transmission. We remember that when the undergraduate internship was doing background development in the company, the main thing was to develop the interface, and to write a large interface document to strictly indicate what the input and output are? Explain clearly the request method of each interface and the matters needing attention for the request parameters.
For example, the following example:
POST http://www.httpexample.com/restful/buyer/info/shar
The interface may return a JSON string or an XML document. Then the client will process the returned information, so that development can be carried out relatively quickly.
But for large enterprises, when there are many internal subsystems and many interfaces, the benefits of the RPC framework are revealed. The first is long links. It is not necessary to shake hands three times like HTTP every time. Reduced network overhead.
The second is that the RPC framework generally has a registration center with rich monitoring and management; release, offline interface, dynamic expansion, etc., are imperceptible and unified operations for the caller.
Summarize
There are still many differences between RPC services and HTTP services. Generally speaking, RPC services are mainly aimed at large enterprises, while HTTP services are mainly aimed at small enterprises, because RPC is more efficient, and HTTP service development iterations will be faster .
In short, what kind of framework to choose is not determined by what is popular in the market, but a complete evaluation of the entire project, so as to carefully compare the impact of the two development frameworks on the entire project, and finally decide what is the most suitable for this item.
Be sure not to use RPC for every project in order to use RPC, but to adapt measures to local conditions and analyze specific situations.