protobuf learning (1): first getting to know protobuf

Overview

Since protobuf needs to be combined in the process of learning Netty, "last resort" expand the study.

What is protobuf

protobuf is short for google protocol buffers, and is an RPC framework launched by Google in the early years . Simply put, protobuf can be regarded as a protocol, which can "encode" and "decode" data in a better and smaller size , which is essentially the process of serialization and deserialization. It is a technology in the same field as gRPC launched by Google and Thrift open sourced by Facebook. ProtoBuf is a data expression method. According to G's own description, it should be called a data exchange format . Note that the  word exchange is used here  , which means it focuses on data transmission.

The principle of using the RPC library

When it comes to RPC, I have to mention a technology-RMI (remote method invocation), as the name implies, remote method invocation, which supports communication between program-level objects stored in different address spaces to achieve seamless communication between remote objects Remote call, speaking human is to support remote call without perception on different machines. JAVA RMI supports communication between different virtual machines. These virtual machines can be on different hosts or on the same host; objects in one virtual machine call methods of objects in another virtual machine, but it is allowed The remotely called object must be identified by some signs. It means that the program on machine A calls a method x(). In fact, the method x() is a method in machine B, but it is called on machine A as if calling a local method in this program. Perception", since it is a cross-machine call, it is essentially that the A machine serializes the method description, parameters and other elements that need to be called into the form of bytecode, and transmits it to the B machine, and the B machine restores the received bytecode to the source The method call describes the execution and returns the result to the A machine . There is a limitation of this form of remote call, that is, the A and B machines must be Java code, and there are language restrictions . The advantage is that the implementation of this form of call is shielded from the developer, which means that the developer only needs to care about how to use it. This technology does not need to be related to how to implement it, but in this remote call process, there must be the action of code generation , which is called: stub on the calling side, and called: skeleton on the server side, when the call occurs , The caller serializes the "call description" and passes it to the callee through the socket. The callee deserializes the data into an understandable method call and executes it, and then returns the result to the caller after serialization . So it can be seen from the call process that serialization and deserialization are important parts of RMI calls .

 

I said so much about RMI in order to better understand RPC (remote procedure call) remote procedure call, the principle is very similar to RMI.

  • The advantages of RPC over RMI-cross-language, the caller and the server can be written in different languages, the caller can be java, and the server can be python.
  • The writing modes of many RPC frameworks are similar, as follows:
  1. Define an interface description file (call description), which describes a series of information such as objects (structures), object members, interfaces, etc. This description file is language-independent and is a text file
  2. Through the compiler provided by the RPC framework, the interface specification file is compiled into a specific language file. For example, if you want to generate java language on the client side and C language on the server side, it can help you through some parameter settings.
  3. Introduce the compiled files generated by the RPC compiler on the client and server respectively to call the remote server on the client as if calling a local method

From the above process, it can be seen that the use of RPC is a bit similar to webservice, but it is different:

  1. Due to the efficiency of encoding and decoding (serialization and deserialization), the xml description file data transmission of webservice is too large
  2. Webservice transmits data through http, and RPC through socket, the efficiency must be high in socket mode

Especially in large-scale systems that require high timely transmission efficiency, the advantages of RPC are self-evident. There are a large number of back-end calls in the form of distributed and microservices, which are more obvious.

Basic understanding of protobuf

Official website https://developers.google.com/protocol-buffers

Protocol buffers is a language-neutral and platform-neutral extensible mechanism for serializing structured data

Seeing the three pieces of code on the homepage, the first paragraph belongs to the interface description. For the data types of the interface description, the more languages ​​supported by the RPC framework, the fewer the data types, because the data types supported by the RPC framework are its support The intersection of all language data types . The 1, 2, and 3 behind each field do not refer to the value of the field, but represent the order of the field, which can also be said to be an identification.

Write the object described by the interface to the output stream through the second code (another language).

The third code (C language) will receive the data in the stream and deserialize it into self-readable data

Guess you like

Origin blog.csdn.net/qq_25805331/article/details/108328907