- uses HTTP/2 as the underlying multiplexed transport: requests are multiplexed over a single TCP connection; explicitly allow for full-duplex streaming.
- pluggable transport layer: gRPC/HTTP/2, gRPC/QUIC, internally gRPC/LOAS2.
- high-performance, compact, lightweight: uses binary rather than text; header compression to reduce the sie of request and response.
- uses static paths for performance reasons during call dispatch as parsing call parameters from paths, query parameters and payload body adds latency and complexity. Paths encodes method name.
- utilize protobuf
- for microservices
- used by Docker/Kubernetes, etcd
- from Google
Channel vs Stub:
- Stub: a single client.
- Channel: a single TCP connection. Can be multiplexed(usd by multiple stubs).
gRPC encourages sharing channels; channels are relatively expensive, stubs for different services at the same server can share the same channel.
2 Parts of a Request:
- Payload: a sequence of bytes opaque to the transport protocol
- Metadata/Side Channel (Optional): e.g. client max waiting time, authentication info, etc. Sidechannel is represented with the Metadata class, which models the sidechannel as an untyped key-value map. Keys are ASCII characters, values are bytes, to be compatible with shipping over HTTP headers. (gRPC sidechannel is effectively a map from string to bytes)
RPC System (Extension) Patterns:
- hardcoded(no control): logic hardcoded in the RPC system, cannot be customized.
- interceptors/filters(partial control): RPC system controls the bulk of the handling of the event; users can registered interceptors (or filters), RPC system will run the interceptors, apply the side-effects, and continue the execution of the event.
- handlers(full control): user implement "handlers" to fully handle an event.
gRPC and LOAS
- ALTS, Application Layer Transport Security(LOAS2); a replacement for SSL/TLS
- TLS: from external to Google.
- ALTS: for service-to-service communications within Google's infrastructure.
- gRPC: a replacement for Google's internal only Stubby, on top of TLS or ALTS.
gRPC Load Balancing
gRPC breaks the standard connection-level load balancing: gRPC is built on HTTP/2, and HTTP/2 is designed to have a single long-lived TCP connection, across which all requests are multiplexed—meaning multiple requests can be active on the same connection at any point in time. Once the connection is established, there's no more balancing to be done. All requests will get pinned to a single destination pod.
In contrast to HTTP/2, HTTP/1.1 cannot multiplex requests. Only one HTTP request can be active at a time per TCP connection.
gRPC load balancing on Kubernetes with Linkerd.