(defragment 4) Simple description of RPC service and HTTP service

It's been a long time since the difference between RPC (that is, remote Procedure call, remoting procedure calls) and HTTP calls, not all 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 certainly 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;
• Layer Fourth: Transport layer. Manage the end-to-end data transfer in the network;
• Layer Fifth: Network layer. Define how data is transferred between network devices;
• Layer Sixth: 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 a little nicer than 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), a true service provider.
• The client stub, which stores the address message on the server, then packages the client's request parameters into a network message and sends it to the service provider remotely over the network.
• A service-side stub that receives a message sent by the client, unpacking the message, and calling 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 in 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 did you do this? Mainly to reduce the size of the client side of the jar package, because each time the package jar is released, too many packages will always affect efficiency. 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? 同步调用is that the client waits for the call to finish and returns the result. 异步调用is that the client does not wait for the call execution 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 Java callable and runnable interface, when we execute asynchronously, if we need to know the result of execution, we can use the callable interface, and can Future get the result information of asynchronous execution through the class. If you do not care about the results of the implementation, the direct use of the runnable interface can be, because it does not return the results, of course, it callable is also possible, we do not have to get Future on it.

The popular RPC framework

The current popular open source RPC framework is still much more. Here are three ways to focus:

1. 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.
2. 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 is a certain cost for the user to learn the specific domain language.
3. 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.

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 is 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.

Summarize

RPC services and HTTP services 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 whole project to be fully evaluated, thus carefully comparing the impact of the two development frameworks on the whole 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 local conditions, specific analysis.

(defragment 4) Simple description of RPC service and HTTP service