grpc [d1aefdfd]
Tags: kubernetes (k8s)
1. gRPC communication patterns
1. gRPC communication patterns
- contract first, protobuf IDL, binary messaging on the wire w/ HTTP2, duplex
1.1. rpc flow
1.1. rpc flow
- take message
- encode message
- add message headers
- send message across network
1.2. http2 level
1.2. http2 level
-
once the HTTP 2 connection has been created, this is a grpc channel
- each rpc call is a single stream
-
message frames
- headers and data frames
-
request messages
-
contains
- header frame
- framed message that spans one or more data frames
- eos flag in the last data frame
-
-
response emssages
- same structure, except with trailers
1.3. rpc types
1.3. rpc types
-
simple rpc
- single request/single response
- the stub sends to the server, one block of headers, message, and eos (end of stream) for request
-
server streaming
- one request, multiple response
- multiple data frames being sent back
-
client streaming
- multiple request, single response
-
bidirectional streaming
- each request is length prefixed! there is one header in the request, and one eos, but each mmessage in between is a length-prefixed value
1.4. request/response headers
1.4. request/response headers
-
two types of headers
-
call definition headers
- predefined headers supported by http/2
- headers starting with `:` are reserved headers
-
custom metadata
- any other header, arbitrary set of kv pairs
- use metadata to share info about RPC calls that are not related to business context
- `grpc-` is a reserved metadata header
-
1.5. length prefixed message
1.5. length prefixed message
- 4 bytes are allocated to send the size of the image -> uses big endian integer
- 1 byte is used to talk about the compressed flag
- compression algo is defined in the request headers
1.6. encoding of binary messages
1.6. encoding of binary messages
- default is protobuf
- encoded binary message consists of tag-value pairs and message ends with 0
- each message field value is represented by tag-value in binary format
1.7. error handling
1.7. error handling
- first class concept
- github.com/grpc/grpc/blob/master/doc/statuscodes.md
- status code and status message
- uses the headers `grpc-status` and `grpc-message`, sent in the trailing headers in the response
- do not include error details in response payloads
1.8. deadlines
1.8. deadlines
- allows both client and services when to abort
- clients are responsible for setting deadlines
- normally set as an absolute time
- deadlines are propagated to other services
1.9. inteceptors
1.9. inteceptors
- mechanism to execute common logic before/after the execution of remote function
- unary inteceptors or streaming inteceptors
- useful for logging, authetnication, metrics
1.10. extending service definition
1.10. extending service definition
- service level, method level, and field level options in the service definition, allows you to access those options at runtimemoder