GRPC client creation and invocation principle resolution __GRP

1. GRPC Client creation Process 1.1. Background

GRPC is the RPC framework implemented on HTTP/2, HTTP/2 is the 7th layer (Application Layer) protocol, which runs on top of the TCP (Layer 4th-Transport Layer) protocol, and has many advantages over the traditional Rest/json mechanism: based on http/ Binary protocol over 2 (PROTOBUF serialization mechanism) One connection can be multiplexed, concurrent processing multiple requests and responding to many languages of the class Library implementation service definition file and automatic code generation (. Proto files and protobuf compilation tools)

In addition, GRPC provides a number of extension points for customizing and extending the framework, for example, through an open load balancing interface that seamlessly integrates with third party components (zookeeper, domain resolution services, SLB services, etc.).

An example of a complete RPC call process is as follows:

(Click to enlarge image)

Figure 1-1 Common RPC call process

GRPC RPC calls are similar to the above process, let's take a look at the GRPC client-side creation and service invocation processes below. 1.2. Business code example

As an example of the GRPC entry-level HelloWorld demo, the code for a client-initiated RPC call consists of the following parts:

1) Create Managedchannelimpl according to hostname and port

2 Create a client stub based on the GREETERGRPC generated by the Helloworld.proto file to initiate the RPC call

3 Use the client stub (greeterblockingstub) to initiate an RPC call to get the response.

The relevant sample code looks like this:

(Click to enlarge image)

1.3. RPC Call Process

GRPC client calls mainly include four processes based on Netty HTTP/2 client creation, client load Balancing, request message sending, and response receiving processing.

The overall process of GRPC client invocation is shown in the following illustration:

(Click to enlarge image)

Figure 1-2 GRPC Overall call process

The GRPC client invocation process is as follows:

1 the client stub (greeterblockingstub) invokes SayHello (request) to initiate an RPC call

2 through Dnsnameresolver Domain name resolution, get the Address information (list) of the server, then use the default LoadBalancer policy, select a specific GRPC server instance

3 If no connection is available between the server selected by the route, create Nettyclienttransport and Nettyclienthandler, initiate the HTTP/2 connection

4 the request message using PB (Protobuf) to do serialization, through the HTTP/2 stream sent to the GRPC server

5 after receiving the service-side response, use PB (Protobuf) to do the deserialization

6 callback Grpcfuture Set (Response) method, wakeup blocked client call thread, get RPC response

It should be noted that client-side synchronization blocking RPC calls is blocking the caller thread (usually the business thread), and the underlying transport I/O thread (Netty nioeventloop) is still non-blocking.

Managedchannel is an abstraction of the transport layer Socketchannel, the transport layer is responsible for the serialization and deserialization of protocol messages, as well as the sending and reading of protocol messages. Managedchannel passes the processed requests and responses to the associated Clientcall for upper processing, while Managedchannel provides lifecycle management for channel (link creation, idle, shutdown, and so on).

Managedchannel provides an interface-style clientinterceptor that intercepts RPC client calls, injects extension points, and customizes functionality to facilitate the functional extension of GRPC by the user of the framework.

Managedchannel's main implementation class Managedchannelimpl creation process is as follows:

(Click to enlarge image)

Figure 1-3 Managedchannelimpl Create process

Process key technical point interpretation: Create Managedchannelbuilder implementation class Nettychannelbuilder using builder mode. Nettychannelbuilder provides Buildtransportfactory factory method creation Nettytransportfactory, which is ultimately used to create nettyclienttransport. Initialize the HTTP/2 connection mode: In plaintext negotiation mode or the default TLS mode, there are two modes of HTTP/2 connection: H2 (HTTP/2 built on top of TLS) and H2C (HTTP/2 built directly over TCP). Create a nameresolver.factory factory class for resolving server-side URIs, grpc DNS domain name resolution by default.

After the Managedchannel instance construct is complete, you can create the Clientcall and initiate the RPC call.

After the Managedchannelimpl is created, a new Clientcall instance is initiated by Managedchannelimpl. The use of Clientcall is the message scheduling and processing of the business application layer, and its typical usage is as follows:

__fri Sep 2017 09:46:36 gmt+0800 (CST) ____fri Sep 2017 09:46:36 gmt+0800 (CST) __ call = Channel.newcall (Unarymethod, calloptions);
 Call.start (Listener, headers);
 Call.sendmessage (message);
 Call.halfclose ();
 Call.request (1);
 Wait for listener.onmessage () __fri Sep 2017 09:46:36 gmt+0800 (CST) ____fri Sep 2017 09:46:36 gmt+0800 (CST) __

The creation process for the Clientcall instance is as follows:

(Click to enlarge image)

Figure 1-4 Clientcallimpl Create process

Key technical points of process interpretation: the main tectonic parameters of Clientcallimpl are Methoddescriptor and calloptions, where Methoddescriptor store the interface name, method name, and the calling RPC service The way the service is invoked (for example, the unary type) and the serialization and deserialization implementation classes of the request and response. Calloptions stores additional information about RPC calls, such as timeout, authentication information, message length limits, and the thread pool that executes client calls. Set up a compression and decompression registration class (Compressorregistry and Decompressorregistry) so that you can compress and decompress the HTTP/2 message according to the specified compression algorithm.

After the Clientcallimpl instance is created, you can call Clienttransport, create the HTTP/2 Client, and initiate a remote service call to the GRPC server.

GRPC client base based on the Netty4.1 HTTP/2 protocol stack Framework, so that the HTTP/2 protocol can be used to host RPC messages, to meet the standardization of the premise of improving communication performance.

The key implementation of the GRPC HTTP/2 protocol stack (client) is Nettyclienttransport and Nettyclienthandler, and the client initialization process looks like this:

(Click to enlarge image)

Figure 1-5 HTTP/2 Client creation process

Key technical points of process interpretation:

1.NettyClientHandler creation: cascading creates Netty Http2framereader, Http2framewriter, and http2connection for building Netty based Grpc http/ 2 Client protocol stack.

2.HTTP/2 client Startup: Still initialize and start clients based on Netty Bootstrap, but there are two details to note: Nettyclienthandler (actually packaged as Protocolnegotiator.handler, for HTTP/2 handshake negotiation) after the creation, Instead of the traditional Channelinitializer adding Nettyclienthandler to pipeline when initializing channel, it is directly added to bootstrap by handler pipeline method. So that you can receive the send task immediately. The work thread group used by the client is not a common eventloopgroup, but rather a eventloop: The work thread used by the HTTP/2 client is not a set of threads (the default thread count is CPU kernel * 2), but a eventloop thread. It is also easy to understand that a nioeventloop thread can handle multiple HTTP/2 client connections at the same time, it is multiplexed, and for a single HTTP/2 client, if the default exclusive of a work thread group, it will cause great waste of resources, It can also cause a handle overflow (concurrent startup of a large number of HTTP/2 clients).

3. Writequeue creation: Netty Niosocketchannel initialized and registered to selector (before HTTP connection is initiated), Nettyclienthandler is created immediately by Writequeue, Used to receive and process various commands within the GRPC, such as link closing instructions, sending frame instructions, sending ping instructions, and so on.

After HTTP/2 client creation is complete, the client can initiate a HTTP/2 connection based on the negotiation policy. If the connection is created successfully, then the HTTP/2 connection can be reused for subsequent RPC calls.

HTTP/2 communicate through negotiation at the beginning of the TCP connection, and only after the negotiation is successful can the subsequent business layer data be sent and received.

HTTP/2 's version identification is divided into two categories: HTTP/2 based on TLS architecture, that is, HTTPS, using H2 representation (ALPN): 0x68 and 0x32 built directly over TCP, that is, HTTP, using the HTTP/2 representation

The HTTP/2 connection is created in two ways: by negotiating the upgrade protocol and by connecting directly.

If you do not know whether the service side support HTTP/2, you can use http/1.1 to negotiate, the client sent the negotiation request message (with only the message header), the message example is as follows:

__fri Sep 2017 09:46:36 gmt+0800 (CST) ____fri Sep 2017 09:46:36 gmt+0800 (CST) __get/http/1.1
host:127.0.0.1
  connection:upgrade, http2-settings
upgrade:h2c
http2-settings: <base64url encoding of HTTP/2 Settings Payload>__fri Sep 2017 09:46:36 gmt+0800 (CST) ____fri Sep 2017 09:46:36 gmt+0800 (CST) __

When the service side receives the negotiation request, if the HTTP/2 is not supported, it is returned directly according to the http/1.1 response and the two sides communicate through http/1.1, the message example is as follows:

__fri Sep 2017 09:46:36 gmt+0800 (CST) ____fri Sep 2017 09:46:36 gmt+0800 (CST) __http/1.1/OK
content-length:
content-type:text/css

Body...__fri Sep 2017 09:46:36 gmt+0800 (CST) ____fri Sep 2017 09:46:36 gmt+0800 (C ST) __

If the service side supports HTTP/2, the negotiation succeeds, returns a 101 result code, notifies the client to upgrade to HTTP/2 to communicate together, the sample message is as follows:

__fri Sep 2017 09:46:36 gmt+0800 (CST) ____fri Sep 2017 09:46:36 gmt+0800 (CST) __http/1.1-switching >connection:upgrade
upgrade:h2c

[http/2 connection...__fri Sep 2017 09:46:36 gmt+0800 (CST) ____fri Sep 15 20 09:46:36 gmt+0800 (CST) __

101 After the response, the service needs to send the settings frame as a connection preamble, and after the client receives a 101 response, it must also send a preamble in response to the following example:

__fri Sep 2017 09:46:36 gmt+0800 (CST) ____fri Sep 2017 09:46:36 gmt+0800 (CST) __PRI * http/2.0\r\n\r\nsm\r\n\r\n
  
   settings Frame __fri Sep 2017 09:46:36 gmt+0800 (CST) ____fri Sep 2017 09:46:36 gmt+0800 (CST) __
  

After the client preamble is sent, you can send the business request frame directly without waiting for the settings frame of the service side.

If the client and server have agreed to use HTTP/2, you can eliminate the 101 negotiation and switching process, directly initiate HTTP/2 connection, the following process is as follows:

(Click to enlarge image)

Figure 1-6 HTTP/2 Direct Join process

Several key points: