preface

GRPC has appeared more and more frequently in recent years, and more and more projects have introduced gRPC, such as Dubbo3.0, Nacos, RocketMQ5.0. So what is gRPC in the end we will analyze from the following aspects

1. What is gRPC?

GRPC is a modern open source high-performance remote procedure call (RPC) framework that can run in any environment. It effectively connects services within and across data centers, supporting load balancing, tracking, health checks, and authentication. It is also suitable for distributed computing, connecting devices, mobile applications and browsers to back-end services – that is the official description. GRPC features:

So what is gRPC?

  • A high-performance RPC framework, a cross-language RPC framework.
  • Use Protocol Buffers for binary serialization
  • Use HTTP/2 for data transfer

GRPC clients and servers can run and communicate with each other in a variety of environments. C++ implementation used by the server. The client can be Ruby, Java, Go, and other languages. This reflects the cross – flat gRPC.

2. GRPC and Protocol Buffers

2.1 What is Protocol Buffers?

Protocol Buffers website: developers.google.com/protocol-bu…

A language – and platform-independent extensible protocol for serializing structured data (e.g., XML, JSON) defined by Google. But smaller, faster and simpler. You only need to define how the data is structured, and then you can easily write and read structured data to various data streams using specially generated source code, and it can be used by a variety of languages.

Data transfer between Akka nodes can be customized based on Protocol Buffers serialization processing.

2.2 gRPC uses Protocol Buffers to serialize structured data

// 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;
}
Copy the code

Service and Message are defined by defining the proto file. The Service provides the service, and Message provides the serialization of structured data.

GRPC and Protocol Buffers

Protocol Buffers are responsible for serializing structured data for gRPC

3. The gRPC and HTTP2

HTTP/2

Let’s take a closer look at how the gRPC concept relates to the HTTP/2 concept. GRPC introduces three new concepts :channel, RPC, and Message. The relationship between the three is simple: each Channel may have many RPCS, and each RPC may have many messages.

3.1 How does gRPC Associate HTTP/2

Streams in HTTP/2 allow multiple concurrent sessions over a single connection, while gRPC extends this concept by supporting multiple streams over multiple concurrent connections.

Channel: represents a virtual link to a terminal

There may actually be multiple HTTP/2 connections behind a Channel. From the diagram above, an RPC is associated with an HTTP/2 connection, and RPC is actually pure HTTP/2 flow. Message is associated with RPC and is sent as an HTTP/2 data frame.

Messages are layered on top of data frames. A data frame may have many gRPC messages, or if a gRPC message is very large, it may span multiple data frames.

3.2 Parsers and load balancers

To keep connections alive, Healthy, and utilized, gRPC uses a number of components, the most important of which are name resolvers and load balancers.

  • The parser translates the names into addresses, which are then handed to the load balancer.
  • The load balancer is responsible for creating connections from these addresses and load balancing RPCS between connections.

3.3 Connection Management

When configured, gRPC keeps the connection pool (defined by the parser and the balancer) in a normal, active, and used state.

When the connection fails, the load balancer begins to reconnect using the last known address list. At the same time, the parser will begin attempting to reparse the host name list. This is useful in many scenarios. For example, if the proxy is no longer reachable, we want the parser to update the address list so that it does not contain the address of the proxy. Another example :DNS entries may change over time, so the address list may need to be updated regularly. In this and other ways, gRPC aims to achieve long-term resilience.

Once the parsing is complete, the load balancer is informed of the new address. If an address changes, the load balancer may close a connection to an address that does not exist in the new list, or create a connection to an address that did not exist before.

Connections are also pooled

3.4 Identification of Failed Connections

The effectiveness of gRPC connection management depends on its ability to identify failed connections. There are two types of failed connections:

  • Cleared failed connection – communication failure (e.g., failed connection)

    Clearing failures can occur when an endpoint intentionally terminates a connection. For example, the endpoint may have gracefully closed, or the timer may have expired, prompting the endpoint to close the connection. TCP semantics are sufficient when the connection is cleanly closed: closing the connection causes a FIN handshake. This terminates the HTTP/2 connection and thus the gRPC connection. GRPC will begin reconnecting immediately. No additional HTTP/2 or gRPC semantics are required.

  • Failed Connections that cannot be cleared (complex network environment)

    The endpoint dies or hangs without notifying the client. In this case, TCP may retry for up to 10 minutes before considering the connection to have failed. Of course, not realizing that the connection has been dead for 10 minutes is unacceptable. GRPC solves this problem using HTTP/2 semantics: When KeepAlive is configured, gRPC periodically sends HTTP/2 PING frames. These frames bypass flow control and are used to establish whether the connection is valid. If the PING response is not returned in time, the gRPC considers the connection failed, closes the connection, and starts reconnecting

In this way, gRPC maintains the health of the connection pool and periodically uses HTTP/2 to determine the health of the connection.

3.5 the Alive

Periodically check the health of the connection by sending HTTP/2 pings to determine if the connection is still alive

GRPC’s relationship to HTTP/2: HTTP/2 provides the foundation for long-connected, real-time communication flows. GRPC builds on this foundation, with connection pooling, healthy semantics, efficient use of data frames and multiplexing, and KeepAlive. The communication cornerstone of gRPC is HTTP/2

4. Application of gRPC

GRPC is now used in many projects

  • Nacos(2.x)
  • Dubbo(3.x)
  • Apache RocketMQ (5.x)

Interested can study the corresponding project source code

5. To summarize

  • GRPC is a highly available cross-platform RPC framework
  • GRPC data serialization is through Protocol Buffers, and data transmission is based on HTTP/2
  • The semantics of HTTP/2 provide gRPC with long connections and real-time communication, as well as other HTTP/2 features