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