Comparison of RPC service and HTTP service

It's been a long time since there's been no way to figure out the difference between RPC (that is, the remote Procedure call, the long-distance procedure calls) and the HTTP call, not all of them writing a service and calling it on the client. Here please allow me to be fascinated by one laugh ~naive. This article briefly introduces the two forms of C/S architecture, first of all, their most essential difference is that RPC is mainly based on TCP/IP protocol, and HTTP service is mainly based on HTTP protocol, we know that the HTTP protocol is on the Transport Layer protocol TCP, so efficiency, RPC is, of course, a better one. Here's a concrete talk about RPC services and HTTP services. OSI Network seven layer model

Before I say the difference between RPC and HTTP, I think it's important to understand the OSI seven-layer network architecture model (although it's basically five-tier in practice), it can be divided into the following layers: (Top to bottom)
* First layer: Application layer. Defines an interface for communicating and transmitting data in a network;
* Second Layer: Presentation layer. Define the transmission format, encoding and decoding specifications of the data in different systems;
* Third layer: Session layer. Manage user's sessions and control the creation and interruption of logical connections between users;
* Fourth layer: Transport layer. Manage the end-to-end data transfer in the network;
* Layer Fifth: Network layer. Define how data is transferred between network devices;
* Sixth layer: Link layer. The packet of the above network layer is encapsulated into a data frame, which facilitates the transfer of the physical layer;
* Layer Seventh: Physical layer. This layer is primarily the transfer of these binary data.

In the actual application process, there is no representation layer and session layer in the five layer protocol structure. It should be said that they merged with the application layer. We should focus on the application layer and the transport layer of the two levels. Because HTTP is an application-layer protocol, TCP is the transport-layer protocol. Well, knowing the hierarchical model of the network, we can better understand why the RPC service is nice compared to the HTTP service. RPC Service

The RPC service is described in three ways: RPC schema, synchronous asynchronous invocation, and popular RPC framework. RPC Schema

Let's talk about the basic architecture of the RPC service. Allow me to steal a picture with shame. We can clearly see that a complete RPC architecture contains four core components, namely the Client, the server,client stub, and the Server stub, which you can understand as stubs. Say these components separately:
* Client, the caller of the service.
* Service-side (Server), true service provider.
* Client stubs, store address messages on the server, and then package the client's request parameters into a network message and send it remotely to the service party over the network.
* Server stub, receive the message sent by the client, unpack the message, and invoke the local method.

RPC is mainly used in large enterprises, because large enterprises inside a wide range of systems, business lines complex, and efficiency advantages of a very important piece, this time the advantages of RPC is more obvious. This is done in real-world development, and projects are typically managed using MAVEN. For example, we have a system service for processing orders, declare all of its interfaces (this is specifically referred to as Java interface), and then package the entire project as a jar package, the server side to introduce this two-party library, and then implement the corresponding functions, The client side also needs only to introduce this two-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 of each package release. In addition, the client and the server are decoupled to improve the portability of the code. synchronous calls and asynchronous calls

What is a synchronous call. What is an asynchronous call. The synchronous call is when the client waits for the call to finish and returns the result. The asynchronous call is that the client does not wait for the call to complete the return result, but can still receive a 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 like the callable and Runnable interfaces in Java, when we execute asynchronously, if we need to know the result of execution, we can use the callable interface, and we can get the result information of asynchronous execution through the future class. If you do not care about the results of execution, the direct use of the Runnable interface can be, because it does not return the results, of course, callable is also possible, we do not go to get the future on it. the popular RPC framework

The

Currently popular open source RPC framework is still relatively many. Here are three kinds of highlights: Grpc is Google's latest open source software, based on the newest HTTP2.0 protocol, and supports many common programming languages. We know that HTTP2.0 is a binary-based version of the HTTP protocol upgrade that is currently being supported by major browsers. This RPC framework is implemented based on the HTTP protocol, and the underlying use of the Netty framework is supported. Thrift is an open source project for Facebook, primarily a cross-language service development framework. It has a code generator that automatically generates a service code framework for the IDL definition file it defines. As long as the user two times before the development of the line, for the underlying RPC communication, etc. are transparent. However, this has a certain cost for the user to learn the characteristics of specific domain language. Dubbo is an extremely well-known RPC framework for Alibaba Group's Open source, which is widely used in many Internet companies and enterprise applications. Both the Protocol and the serialization framework can be pluggable and distinct features. The same remote interface is based on Java Interface and is easy to develop with the spring framework. It can be conveniently packaged into a single file, run independently, and be consistent with the current microservices concept.
secretly tell you the group has not how to use Dubbo, now with more than the name of HSF, also known as "good comfortable." There may be open source behind, and we'll wait and see. HTTP Service

In fact, a long time ago, my model for enterprise development has been defined as the development of HTTP interfaces, which is what we often call the RESTful style of service interface. Indeed, for a small number of interfaces, systems and systems with less interaction, the solution of the early days of information is often used in a means of communication, the advantages are simple, direct, easy to develop. Transfer using the ready-made HTTP protocol. We remember before the undergraduate internship in the background development of the company, the main is to develop the interface, but also to write a large portion of the interface document, strictly indicate what the input and output. Make clear the request method for each interface, as well as the things to be aware of when requesting parameters. For example, the following:
POST Http://www.httpexample.com/restful/buyer/info/share
The interface may return a JSON string or an XML document. The client then processes the returned information so that it can be developed in a relatively rapid manner. But for large enterprises, the internal subsystem is more, the interface is very large, the benefits of the RPC framework is shown, the first is the long link, do not have to each communication like HTTP to 3 times to shake a handshake or something, reduce the network overhead; Next is the RPC framework generally has a registration center, has a wealth of monitoring and management , release, downline interface, dynamic expansion, etc., is a non-aware, unified operation for the caller. Summary

The RPC service and HTTP service still have a lot of different points, in general, the RPC service is mainly for large enterprises, and the HTTP service is mainly for small enterprises, because RPC is more efficient, and HTTP service development iterations will be faster. In short, the choice of what kind of framework is not based on what is popular in the market, but the entire project to be fully evaluated, so that in careful comparison of the two development frameworks for the overall impact of the project, and finally decide what is the most suitable for this project. Be sure not to use RPC for each project with RPC, but to adapt to local conditions, specific analysis.