For a long time, I haven't figured out the difference between RPC (i.e. Remote Procedure Call) and HTTP calls. Please allow me to laugh here~Naive! This article briefly introduces the two forms of C/S architecture, first of all, their most essential difference, that is, RPC is mainly based on TCP/IP protocol, while HTTP service is mainly based on 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 services and HTTP services in detail.
OSI network seven-layer model
Before talking about the difference between RPC and HTTP, I feel it is necessary to understand OSI's seven-layer network structure model (although it is basically five layers in practice), which can be divided into the following layers: (from top to bottom)
- The first layer: application layer. Interfaces for communication and data transmission in the network are defined;
- The second layer: the representation layer. Define the transmission format, encoding and decoding specifications of data in different systems, etc.;
- The third layer: the conversation layer. Manage user sessions and control the establishment and interruption of logical connections between users.
- The fourth layer: the transport layer. It manages end-to-end data transmission in the network;
- Layer 5: Network layer. Define how data is transferred between network devices;
- Sixth layer: link layer. The data packets of the network layer above are encapsulated into data frames to facilitate the transmission of the physical layer.
- Layer 7: Physical layer. This layer is mainly about transmitting this binary data.
In practical application, there is no presentation layer and session layer in the five-layer protocol structure. It should be said that they merge with the application layer. We should focus on the application layer and the transport layer. Because HTTP is an application layer protocol, while TCP is a transport layer protocol. Well, now that we know the network layering model, we can better understand why RPC services are nicer than HTTP services!
RPC services
RPC services are introduced from three perspectives: RPC architecture, synchronous asynchronous calls, and popular RPC frameworks.
RPC architecture
Let's talk about the basic architecture of RPC services. Allow me to shamefully steal a picture~ We can clearly see that a complete RPC architecture contains four core components, namely Client, Server, Client Stub and Server Stub, which can be understood as a stub. Let's talk about these components separately:
- Client, the caller of the service.
- Server, the real service provider.
- The client stub stores the address message of the server, and then packages the client's request parameters into a network message, and then sends it to the service party remotely through the network.
- The server-side stub receives messages sent by the client, unpacks the messages, and calls local methods.
RPC is mainly used in large enterprises, because large enterprises have many systems, complex business lines, and efficiency advantages are very important. This is done in actual development, and projects are generally managed using maven. For example, we have a system service that processes orders, first declare all its interfaces (here specifically the interface in Java), and then package the entire project into a jar package. Why do this? The main purpose is to reduce the size of the jar package on the client side, because every time a package is released, too many jar packages will always affect the efficiency. It also decouples the client and server to improve code portability.
Synchronous and asynchronous calls
What is Synchronous Call? What is an asynchronous call? A synchronous call is when the client waits for the call to complete execution and returns the result. Asynchronous calls mean that the client does not wait for the call to execute 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 outcome, it can turn into a one-way call. This process is somewhat similar to the callable and runnable interfaces in Java, when we execute asynchronously, if we need to know the result of the execution, we can use the callable interface, and we can obtain the result information of asynchronous execution through the Future class. If you don't care about the execution result, you can just use the runnable interface because it doesn't return the result, of course, callable is also possible, we don't need to get the future.
Popular RPC framework
There are still many popular open source RPC frameworks. Here are three highlights:
- gRPC is a recently announced open-source software by Google, based on the latest HTTP 2.0 protocol, and supports many common programming languages. We know that HTTP 2.0 is an upgraded version of the HTTP protocol based on binary, and major browsers are currently supporting it at a rapid pace. This RPC framework is based on the HTTP protocol, and the underlying uses the support of the Netty framework.
- Thrift is an open-source project for Facebook, primarily a cross-language service development framework. It has a code generator to automatically generate a service code framework for the IDL definition file it defines. Users only need to carry out secondary development before it, and the underlying RPC communication is transparent. However, for users, there is still a certain cost to learn the language of a specific field.
- 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 can be plugged in. The same remote interface is based on the Java Interface and relies on the spring framework for easy development. It can be easily packaged into a single file and run independently, which is consistent with the current concept of microservices.
Secretly tell you that the group doesn't use dubbo much anymore,The one that is more commonly used now is called HSF, also known as "so comfortable". There may be open source later, so let's wait and see.
HTTP service
In fact, a long time ago, I have always characterized the enterprise development model as HTTP interface development, which is what we often call RESTful-style service interfaces. Indeed, it is a communication method often used in the early stage of solving information islands in the case of few interfaces and less interaction between systems; The advantages are simple, direct and easy to develop. Utilize the ready-made HTTP protocol for transmission. We remember that when we were doing background development in the company before, we mainly developed interfaces, and we also had to write a large interface document, strictly indicating what the input and output were. Explain the request method of each interface and the matters that need to be paid attention to in the request parameters. For example, the following example:
POSThttp://www.httpexample.com/restful/buyer/info/share
The interface may return a JSON string or an XML document. The client then processes this returned information, allowing for faster development. However, for large enterprises, when there are many internal subsystems and many interfaces, the advantages of the RPC framework are shown, first of all, it is a long link, and there is no need to shake hands 3 times like http every time, reducing network overhead; secondly, the RPC framework generally has a registration center and rich monitoring and management; Publishing, offline interfaces, dynamic expansion, etc., are non-perceptive and unified operations for the caller.
summary
Generally speaking, RPC services are mainly for large enterprises, while HTTP services are mainly for 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 to evaluate the whole project completely, so as to carefully compare the impact of the two development frameworks on the whole project, and finally decide what is the most suitable for the project. We must not use RPC for every project for the sake of using RPC, but adapt to local conditions and analyze the specific situation.
|
Posted on 4/1/2019 2:02:45 PM
|
|
|
|
