Article Directory
Preface
Here is a brief introduction to the concept of RPC. If you want a deeper understanding of RPC, please see the blog I wrote before [Custom RPC has source code]
Portal:
Custom RPC source implementation
Seven-layer network model
Before talking about the difference between RPC and HTTP, I feel it is necessary to understand the seven-layer network structure model of OSI
The first layer: application layer. Defines the interface used for communication and data transmission in the network; the
second layer: the presentation layer. Define the transmission format, encoding and decoding specifications of data in different systems; the
third layer: session layer. Manage user sessions, control the establishment and interruption of logical connections between users; the
fourth layer: transport layer. Manage the end-to-end data transmission in the network; the
fifth layer: the network layer. Define how to transmit data between network devices; the
sixth layer: link layer. Encapsulate the upper network layer data packets into data frames to facilitate physical layer transmission; the
seventh layer: physical layer. This layer mainly transmits these binary data.
Focus:
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 application layer and the transport layer. Because HTTP is an application layer protocol, and TCP is a transport layer protocol.
Here is a brief explanation of load balancing based on each layer. In fact, as everyone knows, nginx does load balancing, but on which layer is it based? See the following snippet for this problem
Layer 2 load: MAC address, VIP (virtual VIP. This virtual VIP needs to be understood by everyone. It can be simply understood that the virtual VIP is a constant. The user accesses the configured virtual VIP (that is, the ip address) and then depends on the load balancing route. The real host IP, generally virtual VIP corresponds to multiple IP) The mac address of each machine is different, the IP address is the same
Three-tier load: IP, VIP is provided externally, and each machine in the cluster uses a different IP address.
Four-layer load: the load of the transport layer, including IP and port number, modify the IP address or port address.
Seven-layer load: the application layer, the requested URL, http request packets to carry out the load, the host name
HTTP load balancing, that is, we usually all "seven-layer load balancing" work in the seventh "application layer". And TCP load balancing is what we usually call "four-layer load balancing", which works at the "network layer" and "transport layer." For example, LVS (Linux Virtual Server, Linux virtual service) and F5 (a hardware load balancing device) also belong to the "four-layer load balancing". Nginx generally our configuration is based on IP load, which is the seven-layer load, but later version upgrades can also do TCP load
RPC architecture
Let me talk about the basic architecture of the RPC service. Allow me to steal a picture shamelessly~ We can clearly see that a complete RPC architecture contains four core components, namely Client, Server, Client Stub and Server Stub. This Stub can be understood as 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, then packages the client's request parameters 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 large enterprises have many systems, complex business lines, and efficiency advantages are very important. At this time, the advantages of RPC are more obvious. This is done in actual development, and the project is generally managed by maven.
For example, we have a system service that processes orders. First declare all its interfaces (here specifically refers to the interface in Java), and then package the entire project into a jar package. The server side introduces this second-party library and then implements it. Corresponding functions, the client side only needs to import 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 every time it is packaged and released, too many jar packages will always affect efficiency. In addition, it also decouples the client and server to improve the portability of the code.
Speaking of remote calls, you have to understand asynchronous synchronization
Synchronous and asynchronous calls
What is a synchronous call? What is an asynchronous call? Synchronous call is the client waiting for the call to complete and return the result. Asynchronous call means that the client does not wait for the completion of the call to return the result, but it can still receive the notification of the return result through the callback function. If the client does not 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 perform asynchronous execution, if we need to know the result of the execution, we can use the callable interface, and the result information of the asynchronous execution can be obtained through the Future class. If you don't care about the result of execution, you can use the runnable interface directly, because it does not return a result. Of course, callable is also possible, we just don't get the Future. . (Future, if I remember correctly, is that the internal while loop is actually used to query whether it is completed. If the callback method of the implementation of the Future object is completed to fill in the data, it is actually quite simple, I suggest you take a look)
Generally speaking, RPC is fast, but due to various underlying serialization languages, various systems have to be compatible with various languages, so there are also underlying layers that use HTTP, after all, small and flexible, cross-platform
HTTP
In fact, a long time ago, my mode of enterprise development has been characterized as HTTP interface development, which is what we often call RESTful style service interface. Indeed, when there are not many interfaces and less interaction between the system and the system, a communication method often used in the initial stage of solving information islands; the advantages are simple, direct, and convenient to develop.
Use the ready-made http protocol for transmission. We remember that when the undergraduate internship was doing back-end development in the company, the main thing was to develop the interface, and also to write a large interface document, which strictly marked the input and output? Explain clearly the request method of each interface and the matters needing attention in the request parameters.
The interface may return a JSON string or an XML document. The client then processes the returned information, so that development can be carried out relatively quickly (a agreed serialization protocol).
But for large enterprises, when there are many internal subsystems and many interfaces, the benefits of the RPC framework are revealed. The first is the long link, and there is no need to go to the three-way handshake like http for each communication. Reduced network overhead;
secondly, the RPC framework generally has a registry and rich monitoring and management; release, offline interfaces, dynamic expansion, etc., are non-perceptive and unified operations for the caller (zk, eurka, nacos) and many more).
to sum up
There are still many differences between RPC service and HTTP service. Generally speaking, RPC service is mainly for large enterprises, while HTTP service is mainly for small enterprises, because RPC is more efficient and HTTP service development iterations will be faster .
In short, what framework to choose is not determined according to 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 project. You must not use RPC for every project in order to use RPC. Instead, you must adapt to local conditions and analyze the specific conditions.