Play with grpc - go deep into concepts and principles

This article belongs to an article of knowledge leakage and double disk , The main purpose is to repeat gRPC Related concepts of , And analyze its principle , You can refer to the previous articles for relevant knowledge points and usage ：

• 《 Get along well with gRPC—Go Use gRPC Communication practice 》

• 《 Get along well with gRPC— Communication between different programming languages 》

• 《 I'll take you to understand HTTP and RPC The similarities and differences of the agreement 》

• 《 from 1 Start , Expand Go Language backend business system RPC function 》

The above articles are all about and RPC Agreement related knowledge and Google Open source RPC frame gRPC Knowledge about , But they may be relatively simple and unsystematic , Therefore, I want to use this article to systematically and deeply describe gRPC, Let's start with ：

1  Use gRPC Basic architecture

As can be seen from the figure above , Use gRPC The basic architecture of communication is basically divided into five parts , They are ：

• Service
  ： Services provided

• Client
  ：gRPC client

• gRPC Server
  ：gRPC Server interface

• gRPC Stub
  ：gRPC Client interface

• Proto Request/Proto Response(s)
  ： Intermediate document （ Code / agreement ）

2 Protocol Buffers

2.1  What is? Protocol Buffers？

Protocol Buffers, yes Google A company developed

Data description language

, abbreviation protobuf.

characteristic

：

• Support for multiple programming languages

• Serialized data is small

• Fast deserialization

• Serialization and deserialization code are automatically generated

2.2 Protocol Buffers and gRPC What is the relationship ？

The first thing to say is this gRPC yes RPC A protocol is an implementation , It's a

frame

;Protocol Buffers, yes Google A company developed

Data description language .

gRPC and Protocol Buffers The relationship between browser and HTML The relationship between , Don't depend on each other , But they need to be used together , To achieve the best results .

2.3 Protocol Buffers Basic grammar

Protocol Buffers It's one with

.proto

Ordinary text file with extension .

The protocol buffer data is constructed as

news

, Each message is a small logical record of information , Contains a series of key value pairs called fields . This is a simple example ：

message Person {
 string name = 1;
 int32 id = 2;
 bool has_ponycopter = 3;
}


Once you specify your data structure , You can use the protocol buffer compiler

protoc

Generate data access classes from your prototype definition in your favorite language . These provide a simple accessor for each field , for example

name()

and 

set_name()

, And serializing the entire structure / The method of parsing to the original bytes .

In ordinary  proto  The document defines  gRPC  service , take  RPC  Method parameters and return types

Specify as protocol buffer message

：

// The greeter service definition.
service Greeter {
 // Sends a greeting
 rpc SayHello (HelloRequest) returns (HelloReply) {}
}

// The request message containing the user's name.
message HelloRequest {
 string name = 1;
}

// The response message containing the greetings
message HelloReply {
 string message = 1;
}


gRPC  Use

protoc

special  gRPC  Plug in from  proto  File generation code ： Will get the generated  gRPC  Client and server code , And for filling 、 General protocol buffer code for serializing and retrieving message types .

3 gRPC Four service delivery methods

3.1 Unary RPC

One yuan  RPC, The client sends a single request to the server and obtains a single response , It's like a normal function call .

rpc SayHello(HelloRequest) returns (HelloResponse);


3.2 Server streaming RPC

Server streaming  RPC, The client sends a request to the server and gets the stream to read back a series of messages . The client reads from the returned stream , Until there is no more news .gRPC  Guarantee a single  RPC  The order of messages in the call .

rpc LotsOfReplies(HelloRequest) returns (stream HelloResponse);


3.3 Client streaming RPC

Client streaming  RPC, The client writes a series of messages and sends them to the server , Use the provided stream again . Once the client has finished writing the message , It will wait for the server to read them and return its response .gRPC  Once again, a single  RPC  The order of messages in the call .

rpc LotsOfGreetings(stream HelloRequest) returns (HelloResponse);


3.4 Bidirectional streaming RPC

Two way flow  RPC, Send and write a series of messages using the stream . These two streams run independently , Therefore, clients and servers can read and write in any order they like ： for example , The server can wait to receive all client messages before writing the response , Or it can alternately read messages and then write messages , Or some other combination of read and write . Preserve the order of messages in each flow .

rpc BidiHello(stream HelloRequest) returns (stream HelloResponse)


4 gRPC Life cycle of

4.1  Service delivery

RPC Service provision mainly includes the above four service provision methods .

4.2  Closing date / Overtime

gRPC  Allows the client to specify in  RPC  Before termination due to error , They are willing to wait  RPC  How long will it take to complete

DEADLINE_EXCEEDED

. On the server side , The server can query specific  RPC  Whether it has timed out , Or how much time is left to finish  RPC.

Specifying a deadline or timeout is language specific

： Some languages  API  Work overtime , And some languages  API  Work according to the deadline .

4.3 RPC  End

stay  gRPC  in , Both the client and the server make independent local judgments on whether the call is successful , And their conclusions may not match . It means , for example , There may be one  RPC  Successfully completed on the server side but failed on the client . The server can also decide to complete before the client sends all requests .

4.4  Cancel  RPC

Either the client or the server can cancel at any time  RPC. Cancellation will immediately terminate  RPC, So that no more work can be done .

5 gRPC Communication principle

as everyone knows ,gRPC Is based on HTTP2 Of , and HTTP2 Another relative HTTP1.1 A relatively new concept , So I'm exploring gRPC It is necessary to understand the principle before HTTP2 What is the .

5.1 HTTP2

• HTTP/2  The specification of  2015  year 5  Published in , It aims to solve some scalability problems of its predecessor , Improved in many ways  HTTP/1.1  The design of the , The most important thing is to provide semantic mapping on connections .

• establish  HTTP  The cost of connection is great . You must establish  TCP  Connect 、 Use  TLS  Protect the connection 、 Exchange headers and settings .HTTP/1.1  By treating connections as long-term 、 Reusable objects to simplify this process .HTTP/1.1  The connection remains idle , So that new requests can be sent to the same destination through existing idle connections . Although connection reuse alleviates this problem , But a connection can only process one request at a time —— They are  1:1  Coupled . If you want to send a big message , A new request must either wait for it to complete （ Lead to   Queue blocking ）, Or pay the price of starting another connection more often .

• HTTP/2  By providing a semantic layer above the connection ：
   
  flow
  , This further extends the concept of persistent connections . A stream can be thought of as a series of semantically connected messages , be called  
  frame
  . The flow may be short , For example, a unary flow requesting user status （ stay  HTTP/1.1  in , This may be equivalent to  
  GET /users/1234/status
  ）. As the frequency increases , It has a long life . The recipient may establish a long-term flow , So as to receive user status messages continuously in real time , Not to  /users/1234/status  The endpoint makes a separate request .
  The main advantage of flow is connection concurrency , That is, the ability to interleave messages on a single connection .

• flow control

• However , Concurrent flows contain some subtle pitfalls . Consider the following ： Two streams on the same connection  A  and  B. flow  A  Receive a lot of data , Far more than the data it can process in a short time . Final , The recipient's buffer is filled ,TCP  The receiving window limits the sender . This is for  TCP  It's quite standard behavior , But this situation is unfavorable for flow , Because neither stream will receive more data . Ideally , flow  B  It should be free from flow  A  The impact of slow processing .

• HTTP/2  By providing  
  flow control
    The mechanism solves this problem as part of the flow specification . Flow control is used to limit each flow （ And each connection ） Amount of unfinished data . It operates as a credit system , The receiver assigns a certain “ The budget ”, The sender “ cost ” This budget . More specifically , The receiver allocates some buffer size （“ The budget ”）, The sender fills （“ cost ”） buffer . The receiver uses WINDOW_UPDATE The frame notifies the sender of the available additional buffer  .  When the receiver stops broadcasting additional buffers , The sender must be in the buffer （ Its “ The budget ”） Stop sending messages when exhausted .

• Use flow control , Concurrent streams can guarantee independent buffer allocation .
  Plus polling request sending , All sizes 、 The flow of processing speed and duration can be carried out on a single connection
  Multiplexing
  , There is no need to care about cross flow issues .

• Smarter agents

• HTTP/2  The concurrency attribute of allows agents to have higher performance . for example , Consider a method of accepting and forwarding peak traffic  HTTP/1.1  Load balancer ： When there is a spike , The agent will start more connections to handle the load or queue the request . The former —— new connection —— Usually the first choice is （ In a way ）; The disadvantage of these new connections is not only the time waiting for system calls and sockets , Still in   happen TCP  The connection time is not fully utilized during slow startup .

• by comparison , Consider a configuration for multiplexing each connection  100  A stream of  HTTP/2  agent . Some peak requests will still cause new connections to be started , But with  HTTP/1.1  The corresponding number of connections is only  1/100  A connection . More generally ： If  
  n  individual
   HTTP/1.1  The request is sent to a proxy , be  
  n  individual
   HTTP/1.1  Request must go out ; Each request is a meaningful data request / Payload , The request is  1:1  The connection of . contrary , Use  HTTP/2  Sent to the agent  
  n Request needs n  individual
   
  flow
  , but   Unwanted
  n  individual
    Connect ！

5.2 gRPC And HTTP2

gRPC  Three new concepts are introduced ： passageway 、 Remote procedure call  (RPC)  And news . The relationship between the three is very simple ： Each channel may have many  RPC, And each  RPC  There may be a lot of news .

The channel is  gRPC  A key concept in .

HTTP/2  The flow in supports multiple concurrent sessions on a single connection

;** Channels extend this concept by enabling multiple streams on multiple concurrent connections .** On the face of it , Channel provides a simple interface for users to send messages ; However , Under the hood , A lot of engineering is invested in keeping these connections alive 、 Health and utilization .

Channels represent virtual connections to endpoints , In fact, there may be many  HTTP/2  Connection support .RPC  Associated with a connection （ This association will be further described later ）.RPC  It's actually ordinary  HTTP/2  flow . News and  RPC  Associate and act as  HTTP/2  Data frame transmission . More specifically , The message is above the data frame * A layered .* A data frame may have many  gRPC  news , Or if one  gRPC  The message is very large, and it may span multiple data frames .

6  summary

Okay , To go here about gRPC The explanation of is almost , in the final analysis ,gRPC It's a network protocol , Since it is a network protocol, it is difficult to escape the network I/O, So it is I/O Multiplexing has achieved HTTP2, And then achieved gRPC, Next article , Let's explain the Internet in simple terms I/O Model ！

Reference article ：

https://www.cncf.io/blog/2018/07/03/http-2-smarter-at-scale/

https://grpc.io/blog/grpc-on-http2/