Hello everyone, I am fried fish, as the beginning of the chapter, today I will introduce some knowledge about gRPC. Simply speaking, gRPC is an RPC framework designed based on HTTP/2 protocol, which uses Protobuf as IDL

Have you ever wondered what they are? This article will introduce some commonly used knowledge and concepts, and more detailed manuals will be given to go further

A, the RPC

What is the RPC

RPC generation refers to Remote Procedure Call, which includes transport protocol, encoding (object sequence number) protocol, and so on. Allows a program running on one computer to call a subroutine on another without the developer having to program for this interaction

Actual scenario:

There are two servers, A and B. Application C on A wants to call application D on server B. Can they call directly locally? The answer is no, but it’s very convenient to use RPC. So RPC is often described as being as simple as calling a function locally

RPC framework

In my opinion, a complete RPC framework should include load balancing, service registration and discovery, service governance and other functions, and be extensible to facilitate access to traffic monitoring systems and so on. Of course, it is complete. Some of the more monolithic RPC frameworks can meet this standard by combining multiple components

What do you think?

Common RPC Frameworks

  • gRPC
  • Thrift
  • Rpcx
  • Dubbo

Compare the

\ cross-language More IDL Service governance The registry Service management
gRPC Square root x x x x
Thrift Square root x x x x
Rpcx x Square root Square root Square root Square root
Dubbo x Square root Square root Square root Square root

Why RPC

Simple, versatile, safe and efficient

Can RPC be based on HTTP

RPC stands for remote procedure call and can be based on HTTP protocol

I can tell you that it’s based on HTTP/1.1. HTTP/2 optimizes a lot of issues (as well as new ones), so you see gRPC as the subject of this article

Second, the Protobuf

introduce

Protocol Buffers are a language-independent, platform-independent, extensible method of serializing structured data, often used for communication protocols, data storage, and more. Compared to JSON and XML, it is smaller, faster, simpler, and therefore more popular with developers

grammar

syntax = "proto3";

service SearchService {
    rpc Search (SearchRequest) returns (SearchResponse);
}

message SearchRequest {
  string query = 1;
  int32 page_number = 2;
  int32 result_per_page = 3;
}

message SearchResponse {
    ...
}
Copy the code

1. The first line (non-empty non-comment line) declares using proto3 syntax. If not, the proto2 syntax is used by default. I also recommend using v2 or v3, which version should be declared

2. Define the SearchService RPC service, which contains the RPC method Search with the input parameter as the SearchRequest message and the output parameter as the SearchResponse message

3. Define SearchRequest and SearchResponse messages. The former defines three fields, each containing three attributes: type, field name, and field number

The Protobuf compiler will generate Service Interface Code and Stubs for the chosen language

Finally, here is a simple syntax introduction, please turn right for detailed Language Guide (Proto3)

The data type

.proto Type C++ Type Java Type Go Type PHP Type
double double double float64 float
float float float float32 float
int32 int32 int int32 integer
int64 int64 long int64 integer/string
uint32 uint32 int uint32 integer
uint64 uint64 long uint64 integer/string
sint32 int32 int int32 integer
sint64 int64 long int64 integer/string
fixed32 uint32 int uint32 integer
fixed64 uint64 long uint64 integer/string
sfixed32 int32 int int32 integer
sfixed64 int64 long int64 integer/string
bool bool boolean bool boolean
string string String string string
bytes string ByteString []byte string

The main differences between V2 and V3

  • There is a field logic to remove the original value field
  • Delete required field
  • Delete the optional field, which is the default
  • Delete default field
  • Remove the extension feature and replace it with Any type
  • Delete support for the unknown field
  • New JSON Mapping
  • Added support for Map type
  • Repair the unknown type of enum
  • Repeated is encoded as Packed by default
  • New language implementations introduced (C #, JavaScript, Ruby, Objective-C)

Protobuf Version 3.0.0 is available for more details

Why not use XML instead of Protobuf?

  • More simple
  • The data description file is only 1/10 to 1/3 of the original size
  • Parsing is 20 to 100 times faster
  • It reduces ambiguity
  • Easier to use data access classes are generated

Third, gRPC

introduce

GRPC is a high-performance, open source, and generic RPC framework designed for mobile and HTTP/2

multilingual

  • C++
  • C#
  • Dart
  • Go
  • Java
  • Node.js
  • Objective-C
  • PHP
  • Python
  • Ruby

The characteristics of

1, HTTP / 2

2, Protobuf

3. The client and server are based on the same IDL

4. Good support of mobile network

5. Support multiple languages

An overview of

Interpretation of the

1. The client (gRPC Sub) invokes method A to initiate RPC call

2. Object serialization compression (IDL) using Protobuf for request information

3. After receiving the request, the Server (gRPC Server) decodes the request body, conducts business logic processing and returns it

4. Object serialization compression (IDL) using Protobuf for response results

5. The client receives the response from the server and decodes the request body. The callback to the called A method wakes up the client call waiting for A response (blocking) and returns the response result

The sample

In this section, WE will briefly show you the gRPC client and server side of the sample code, I hope you have a basic impression, will be introduced in detail in the next section 🤔

Build and start the server

lis, err := net.Listen("tcp", fmt.Sprintf(":%d", *port))
iferr ! = nil { log.Fatalf("failed to listen: %v", err)
}

grpcServer := grpc.NewServer()
...
pb.RegisterSearchServer(grpcServer, &SearchServer{})
grpcServer.Serve(lis)
Copy the code

1. Listen on the specified TCP port to accept client requests

2. Create an instance object of the gRPC Server

3. Register gRPC Server internal services and routes

4. Serve() calls the server to perform blocking wait until the process is terminated or called by Stop()

Creating a Client

var opts []grpc.DialOption
...
conn, err := grpc.Dial(*serverAddr, opts...)
iferr ! = nil { log.Fatalf("fail to dial: %v", err)
}

defer conn.Close()
client := pb.NewSearchClient(conn)
...
Copy the code

1. Create gRPC Channel to communicate with gRPC Server (Server address and port are required as parameters)

2, set DialOptions credentials (e.g., TLS, GCE credentials, JWT credentials)

3. Create the Search Client Stub

4. Invoke the corresponding service method

To consider

1. When is it not appropriate to use Protobuf instead of JSON or XML?

2. What is the Packed code mentioned in the Protobuf section?

conclusion

In the opening content, I used as short a description as possible to introduce you to the next must, necessary knowledge points hope you can gain, I suggest to the reference for in-depth study, is the best

?

If you have any questions or mistakes, welcome to raise questions or give correction opinions on issues. If you like or are helpful to you, welcome Star, which is a kind of encouragement and promotion for the author.

My official account

The resources

  • Protocol Buffers
  • gRPC