1. gRPC客戶端創建流程

1.1. 背景

gRPC是在HTTP/2之上實現的RPC框架，HTTP/2是第7層（應用層）協議，它運行在TCP（第4層 - 傳輸層）協議之上，相比于傳統的REST/JSON機制有諸多的優點：

• 基于HTTP/2之上的二進制協議（Protobuf序列化機制）
• 一個連接上可以多路復用，并發處理多個請求和響應
• 多種語言的類庫實現
• 服務定義文件和自動代碼生成（.proto文件和Protobuf編譯工具）

此外，gRPC還提供了很多擴展點，用于對框架進行功能定制和擴展，例如，通過開放負載均衡接口可以無縫的與第三方組件進行集成對接（Zookeeper、域名解析服務、SLB服務等）。

一個完整的RPC調用流程示例如下：

(點擊放大圖像)

圖1-1 通用RPC調用流程

gRPC的RPC調用與上述流程相似，下面我們一起學習下gRPC的客戶端創建和服務調用流程。

1.2. 業務代碼示例

以gRPC入門級的helloworld Demo為例，客戶端發起RPC調用的代碼主要包括如下幾部分：

1) 根據hostname和port創建ManagedChannelImpl

2) 根據helloworld.proto文件生成的GreeterGrpc創建客戶端Stub，用來發起RPC調用

3) 使用客戶端Stub（GreeterBlockingStub）發起RPC調用，獲取響應。

相關示例代碼如下所示：

(點擊放大圖像)

1.3. RPC調用流程

gRPC的客戶端調用主要包括基于Netty的HTTP/2客戶端創建、客戶端負載均衡、請求消息的發送和響應接收處理四個流程。

gRPC的客戶端調用總體流程如下圖所示：

(點擊放大圖像)

圖1-2 gRPC總體調用流程

gRPC的客戶端調用流程如下：

1) 客戶端Stub(GreeterBlockingStub)調用sayHello(request)，發起RPC調用

2) 通過DnsNameResolver進行域名解析，獲取服務端的地址信息（列表），隨后使用默認的LoadBalancer策略，選擇一個具體的gRPC服務端實例

3) 如果與路由選中的服務端之間沒有可用的連接，則創建NettyClientTransport和NettyClientHandler，發起HTTP/2連接

4) 對請求消息使用PB（Protobuf）做序列化，通過HTTP/2 Stream發送給gRPC服務端

5) 接收到服務端響應之后，使用PB（Protobuf）做反序列化

6) 回調GrpcFuture的set(Response)方法，喚醒阻塞的客戶端調用線程，獲取RPC響應

需要指出的是，客戶端同步阻塞RPC調用阻塞的是調用方線程（通常是業務線程），底層Transport的I/O線程（Netty的NioEventLoop）仍然是非阻塞的。

ManagedChannel是對Transport層SocketChannel的抽象，Transport層負責協議消息的序列化和反序列化，以及協議消息的發送和讀取。ManagedChannel將處理后的請求和響應傳遞給與之相關聯的ClientCall進行上層處理，同時，ManagedChannel提供了對Channel的生命周期管理（鏈路創建、空閑、關閉等）。

ManagedChannel提供了接口式的切面ClientInterceptor，它可以攔截RPC客戶端調用，注入擴展點，以及功能定制，方便框架的使用者對gRPC進行功能擴展。

ManagedChannel的主要實現類ManagedChannelImpl創建流程如下：

(點擊放大圖像)

圖1-3 ManagedChannelImpl創建流程

流程關鍵技術點解讀：

使用builder模式創建ManagedChannelBuilder實現類NettyChannelBuilder，NettyChannelBuilder提供了buildTransportFactory工廠方法創建NettyTransportFactory，最終用于創建NettyClientTransport。

初始化HTTP/2連接方式：采用plaintext協商模式還是默認的TLS模式，HTTP/2的連接有兩種模式：h2（基于TLS之上構建的HTTP/2）和h2c（直接在TCP之上構建的HTTP/2）。

創建NameResolver.Factory工廠類，用于服務端URI的解析，gRPC默認采用DNS域名解析方式。

ManagedChannel實例構造完成之后，即可創建ClientCall，發起RPC調用。

完成ManagedChannelImpl創建之后，由ManagedChannelImpl發起創建一個新的ClientCall實例。ClientCall的用途是業務應用層的消息調度和處理，它的典型用法如下：

__Fri Sep 15 2017 09:46:36 GMT+0800 (CST)____Fri Sep 15 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 15 2017 09:46:36 GMT+0800 (CST)____Fri Sep 15 2017 09:46:36 GMT+0800 (CST)__

ClientCall實例的創建流程如下所示：

(點擊放大圖像)

圖1-4 ClientCallImpl創建流程

流程關鍵技術點解讀：

ClientCallImpl的主要構造參數是MethodDescriptor和CallOptions，其中MethodDescriptor存放了需要調用RPC服務的接口名、方法名、服務調用的方式（例如UNARY類型）以及請求和響應的序列化和反序列化實現類。CallOptions則存放了RPC調用的其它附加信息，例如超時時間、鑒權信息、消息長度限制和執行客戶端調用的線程池等。

設置壓縮和解壓縮的注冊類（CompressorRegistry和DecompressorRegistry），以便可以按照指定的壓縮算法對HTTP/2消息做壓縮和解壓縮。

ClientCallImpl實例創建完成之后，就可以調用ClientTransport，創建HTTP/2 Client，向gRPC服務端發起遠程服務調用。

gRPC客戶端底層基于Netty4.1的HTTP/2協議棧框架構建，以便可以使用HTTP/2協議來承載RPC消息，在滿足標準化規范的前提下，提升通信性能。

gRPC HTTP/2協議棧（客戶端）的關鍵實現是NettyClientTransport和NettyClientHandler，客戶端初始化流程如下所示：

(點擊放大圖像)

圖1-5 HTTP/2 Client創建流程

流程關鍵技術點解讀：

1.NettyClientHandler的創建：級聯創建Netty的Http2FrameReader、Http2FrameWriter和Http2Connection，用于構建基于Netty的gRPC HTTP/2客戶端協議棧。

2.HTTP/2 Client啟動：仍然基于Netty的Bootstrap來初始化并啟動客戶端，但是有兩個細節需要注意：

• NettyClientHandler（實際被包裝成ProtocolNegotiator.Handler，用于HTTP/2的握手協商）創建之后，不是由傳統的ChannelInitializer在初始化Channel時將NettyClientHandler加入到pipeline中，而是直接通過Bootstrap的handler方法直接加入到pipeline中，以便可以立即接收發送任務。
• 客戶端使用的work線程組并非通常意義的EventLoopGroup，而是一個EventLoop：即HTTP/2客戶端使用的work線程并非一組線程（默認線程數為CPU內核 * 2），而是一個EventLoop線程。這個其實也很容易理解，一個NioEventLoop線程可以同時處理多個HTTP/2客戶端連接，它是多路復用的，對于單個HTTP/2客戶端，如果默認獨占一個work線程組，將造成極大的資源浪費，同時也可能會導致句柄溢出（并發啟動大量HTTP/2客戶端）。

3. WriteQueue創建：Netty的NioSocketChannel初始化并向Selector注冊之后（發起HTTP連接之前），立即由NettyClientHandler創建WriteQueue，用于接收并處理gRPC內部的各種Command，例如鏈路關閉指令、發送Frame指令、發送Ping指令等。

HTTP/2 Client創建完成之后，即可由客戶端根據協商策略發起HTTP/2連接。如果連接創建成功，后續即可復用該HTTP/2連接，進行RPC調用。

HTTP/2在TCP連接之初通過協商的方式進行通信，只有協商成功，才能進行后續的業務層數據發送和接收。

HTTP/2的版本標識分為兩類：

• 基于TLS之上構架的HTTP/2, 即HTTPS，使用h2表示（ALPN）：0x68與0x32
• 直接在TCP之上構建的HTTP/2,即HTTP，使用h2c表示

HTTP/2連接創建，分為兩種：通過協商升級協議方式和直接連接方式。

假如不知道服務端是否支持HTTP/2，可以先使用HTTP/1.1進行協商，客戶端發送協商請求消息（只含消息頭），報文示例如下：

__Fri Sep 15 2017 09:46:36 GMT+0800 (CST)____Fri Sep 15 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 15 2017 09:46:36 GMT+0800 (CST)____Fri Sep 15 2017 09:46:36 GMT+0800 (CST)__

服務端接收到協商請求之后，如果不支持HTTP/2，則直接按照HTTP/1.1響應返回，雙方通過HTTP/1.1進行通信，報文示例如下：

__Fri Sep 15 2017 09:46:36 GMT+0800 (CST)____Fri Sep 15 2017 09:46:36 GMT+0800 (CST)__HTTP/1.1 200 OK Content-Length: 28 Content-Type: text/cssbody...__Fri Sep 15 2017 09:46:36 GMT+0800 (CST)____Fri Sep 15 2017 09:46:36 GMT+0800 (CST)__

如果服務端支持HTTP/2,則協商成功，返回101結果碼，通知客戶端一起升級到HTTP/2進行通信，示例報文如下：

__Fri Sep 15 2017 09:46:36 GMT+0800 (CST)____Fri Sep 15 2017 09:46:36 GMT+0800 (CST)__HTTP/1.1 101 Switching Protocols Connection: Upgrade Upgrade: h2c[ HTTP/2 connection...__Fri Sep 15 2017 09:46:36 GMT+0800 (CST)____Fri Sep 15 2017 09:46:36 GMT+0800 (CST)__

101響應之后，服務需要發送SETTINGS幀作為連接序言，客戶端接收到101響應之后，也必須發送一個序言作為回應，示例如下：

__Fri Sep 15 2017 09:46:36 GMT+0800 (CST)____Fri Sep 15 2017 09:46:36 GMT+0800 (CST)__PRI * HTTP/2.0\r\n\r\nSM\r\n\r\n SETTINGS幀__Fri Sep 15 2017 09:46:36 GMT+0800 (CST)____Fri Sep 15 2017 09:46:36 GMT+0800 (CST)__

客戶端序言發送完成之后，可以不需要等待服務端的SETTINGS幀，而直接發送業務請求Frame。

假如客戶端和服務端已經約定使用HTTP/2,則可以免去101協商和切換流程，直接發起HTTP/2連接，具體流程如下所示：

(點擊放大圖像)

圖1-6 HTTP/2 直接連接過程

幾個關鍵點：

• 如果已經明確知道服務端支持HTTP/2，則可免去通過HTTP/1.1 101協議切換方式進行升級。TCP連接建立之后即可發送序言，否則只能在接收到服務端101響應之后發送序言
• 針對一個連接，服務端第一個要發送的幀必須是SETTINGS幀，連接序言所包含的SETTINGS幀可以為空
• 客戶端可以在發送完序言之后發送應用幀數據，不用等待來自服務器端的序言SETTINGS幀

gRPC支持三種Protocol Negotiator策略：

• PlaintextNegotiator：明確服務端支持HTTP/2，采用HTTP直接連接的方式與服務端建立HTTP/2連接，省去101協議切換過程。
• PlaintextUpgradeNegotiator：不清楚服務端是否支持HTTP/2，采用HTTP/1.1協商模式切換升級到HTTP/2。
• TlsNegotiator：在TLS之上構建HTTP/2，協商采用ALPN擴展協議，以”h2”作為協議標識符。

下面我們以PlaintextNegotiator為例，了解下基于Netty的HTTP/2連接創建流程：

(點擊放大圖像)

圖1-7 基于Netty的HTTP/2直連流程

總體上看，RPC的負載均衡策略有兩大類：

• 服務端負載均衡（例如代理模式、外部負載均衡服務）
• 客戶端負載均衡（內置負載均衡策略和算法，客戶端實現）

外部負載均衡模式如下所示：

(點擊放大圖像)

圖1-8 代理負載均衡模式示意圖

以代理LB模式為例：RPC客戶端向負載均衡代理發送請求，負載均衡代理按照指定的路由策略，將請求消息轉發到后端可用的服務實例上。負載均衡代理負責維護后端可用的服務列表，如果發現某個服務不可用，則將其剔除出路由表。

代理LB模式的優點是客戶端不需要實現負載均衡策略算法，也不需要維護后端的服務列表信息，不直接跟后端的服務進行通信，在做網絡安全邊界隔離時，非常實用。例如通過Ngix做L7層負載均衡，將互聯網前端的流量安全的接入到后端服務中。

代理LB模式通常支持L4（Transport）和L7（Application)層負載均衡，兩者各有優缺點，可以根據RPC的協議特點靈活選擇。L4/L7層負載均衡對應場景如下：

L4層：對時延要求苛刻、資源損耗少、RPC本身采用私有TCP協議

L7層：有會話狀態的連接、HTTP協議簇（例如Restful）

客戶端負載均衡策略由客戶端內置負載均衡能力，通過靜態配置、域名解析服務（例如DNS服務）、訂閱發布（例如Zookeeper服務注冊中心）等方式獲取RPC服務端地址列表，并將地址列表緩存到客戶端內存中。每次RPC調用時，根據客戶端配置的負載均衡策略由負載均衡算法從緩存的服務地址列表中選擇一個服務實例，發起RPC調用。

客戶端負載均衡策略工作原理示例如下：

(點擊放大圖像)

圖1-9 客戶端負載均衡策略示意圖

gRPC默認采用客戶端負載均衡策略，同時提供了擴展機制，使用者通過自定義實現NameResolver和LoadBalancer，即可覆蓋gRPC默認的負載均衡策略，實現自定義路由策略的擴展。

gRPC提供的負載均衡策略實現類如下所示：

• PickFirstBalancer：無負載均衡能力，即使有多個服務端地址可用，也只選擇第一個地址。
• RoundRobinLoadBalancer：“RoundRobin”負載均衡策略。

gRPC負載均衡流程如下所示：

(點擊放大圖像)

圖1-10 gRPC客戶端負載均衡流程圖

流程關鍵技術點解讀：

1.負載均衡功能模塊的輸入是客戶端指定的hostName、需要調用的接口名和方法名等參數，輸出是執行負載均衡算法后獲得的NettyClientTransport。通過NettyClientTransport可以創建基于Netty HTTP/2的gRPC客戶端，發起RPC調用。

2.gRPC系統默認提供的是DnsNameResolver，它通過InetAddress.getAllByName(host)獲取指定host的IP地址列表（本地DNS服務）。

對于擴展者而言，可以繼承NameResolver實現自定義的地址解析服務，例如使用Zookeeper替換DnsNameResolver，把Zookeeper作為動態的服務地址配置中心，它的偽代碼示例如下：

第一步：繼承NameResolver，實現start(Listener listener)方法：

__Fri Sep 15 2017 09:46:36 GMT+0800 (CST)____Fri Sep 15 2017 09:46:36 GMT+0800 (CST)__void start(Listener listener) {//獲取ZooKeeper地址，并連接//創建Watcher，并實現process(WatchedEvent event)，監聽地址變更//根據接口名和方法名，調用getChildren方法，獲取發布該服務的地址列表 //將地址列表加到List中 // 調用NameResolver.Listener.onAddresses(),通知地址解析完成__Fri Sep 15 2017 09:46:36 GMT+0800 (CST)____Fri Sep 15 2017 09:46:36 GMT+0800 (CST)__

第二步：創建ManagedChannelBuilder時，指定Target的地址為Zookeeper服務端地址，同時設置nameResolver為Zookeeper NameResolver,示例代碼如下所示：

__Fri Sep 15 2017 09:46:36 GMT+0800 (CST)____Fri Sep 15 2017 09:46:36 GMT+0800 (CST)__ this(ManagedChannelBuilder.forTarget(zookeeperAddr).loadBalancerFactory(RoundRobinLoadBalancerFactory.getInstance()).nameResolverFactory(new ZookeeperNameResolverProvider()).usePlaintext(false));__Fri Sep 15 2017 09:46:36 GMT+0800 (CST)____Fri Sep 15 2017 09:46:36 GMT+0800 (CST)__

3. LoadBalancer負責從nameResolver中解析獲得的服務端URL中按照指定路由策略，選擇一個目標服務端地址，并創建ClientTransport。同樣，可以通過覆蓋handleResolvedAddressGroups實現自定義負載均衡策略。

通過LoadBalancer + NameResolver，可以實現靈活的負載均衡策略擴展。例如基于Zookeeper、etcd的分布式配置服務中心方案。

gRPC默認基于Netty HTTP/2 + PB進行RPC調用，請求消息發送流程如下所示：

(點擊放大圖像)

圖1-11 gRPC請求消息發送流程圖

流程關鍵技術點解讀：

ClientCallImpl的sendMessage調用，主要完成了請求對象的序列化（基于PB）、HTTP/2 Frame的初始化。

ClientCallImpl的halfClose調用將客戶端準備就緒的請求Frame封裝成自定義的SendGrpcFrameCommand，寫入到WriteQueue中。

WriteQueue執行flush()將SendGrpcFrameCommand寫入到Netty的Channel中，調用Channel的write方法，被NettyClientHandler攔截到，由NettyClientHandler負責具體的發送操作。

NettyClientHandler調用Http2ConnectionEncoder的writeData方法，將Frame寫入到HTTP/2 Stream中，完成請求消息的發送。

gRPC客戶端響應消息的接收入口是NettyClientHandler，它的處理流程如下所示：

(點擊放大圖像)

圖1-12 gRPC響應消息接收流程圖

流程關鍵技術點解讀：

NettyClientHandler的onHeadersRead(int streamId, Http2Headers headers, boolean endStream)方法會被調用兩次，根據endStream判斷是否是Stream結尾。

請求和響應的關聯：根據streamId可以關聯同一個HTTP/2 Stream，將NettyClientStream緩存到Stream中，客戶端就可以在接收到響應消息頭或消息體時還原出NettyClientStream，進行后續處理。

RPC客戶端調用線程的阻塞和喚醒使用到了GrpcFuture的wait和notify機制，來實現客戶端調用線程的同步阻塞和喚醒。

客戶端和服務端的HTTP/2 Header和Data Frame解析共用同一個方法，即MessageDeframer的deliver()。

2. 客戶端源碼分析

gRPC客戶端調用原理并不復雜，但是代碼卻相對比較繁雜。下面圍繞關鍵的類庫，對主要功能點進行源碼分析。

2.1. NettyClientTransport功能和源碼分析

NettyClientTransport的主要功能如下：

• 通過start(Listener transportListener) 創建HTTP/2 Client，并連接gRPC服務端
• 通過newStream(MethodDescriptor<?, ?> method, Metadata headers, CallOptions callOptions) 創建ClientStream
• 通過shutdown() 關閉底層的HTTP/2連接

以啟動HTTP/2客戶端為例進行講解：

(點擊放大圖像)

根據啟動時配置的HTTP/2協商策略，以NettyClientHandler為參數創建ProtocolNegotiator.Handler。

創建Bootstrap，并設置EventLoopGroup，需要指出的是，此處并沒有使用EventLoopGroup，而是它的一種實現類EventLoop，原因在前文中已經說明，相關代碼示例如下：

(點擊放大圖像)

創建WriteQueue并設置到NettyClientHandler中，用于接收內部的各種QueuedCommand，初始化完成之后，發起HTTP/2連接，代碼如下：

(點擊放大圖像)

2.2. NettyClientHandler功能和源碼分析

NettyClientHandler繼承自Netty的Http2ConnectionHandler，是gRPC接收和發送HTTP/2消息的關鍵實現類，也是gRPC和Netty的交互橋梁，它的主要功能如下所示：

• 發送各種協議消息給gRPC服務端
• 接收gRPC服務端返回的應答消息頭、消息體和其它協議消息
• 處理HTTP/2協議相關的指令，例如StreamError、ConnectionError等。

協議消息的發送：無論是業務請求消息，還是協議指令消息，都統一封裝成QueuedCommand，由NettyClientHandler攔截并處理，相關代碼如下所示：

(點擊放大圖像)

協議消息的接收：NettyClientHandler通過向Http2ConnectionDecoder注冊FrameListener來監聽RPC響應消息和協議指令消息，相關接口如下：

(點擊放大圖像)

FrameListener回調NettyClientHandler的相關方法，實現協議消息的接收和處理：

(點擊放大圖像)

需要指出的是，NettyClientHandler并沒有實現所有的回調接口，對于需要特殊處理的幾個方法進行了重載，例如onDataRead和onHeadersRead。

2.3. ProtocolNegotiator功能和源碼分析

ProtocolNegotiator用于HTTP/2連接創建的協商，gRPC支持三種策略并有三個實現子類：

(點擊放大圖像)

gRPC的ProtocolNegotiator實現類完全遵循HTTP/2相關規范，以PlaintextUpgradeNegotiator為例，通過設置Http2ClientUpgradeCodec，用于101協商和協議升級，相關代碼如下所示：

(點擊放大圖像)

2.4. LoadBalancer功能和源碼分析

LoadBalancer負責客戶端負載均衡，它是個抽象類，gRPC框架的使用者可以通過繼承的方式進行擴展。

gRPC當前已經支持PickFirstBalancer和RoundRobinLoadBalancer兩種負載均衡策略，未來不排除會提供更多的策略。

以RoundRobinLoadBalancer為例，它的工作原理如下：根據PickSubchannelArgs來選擇一個Subchannel：

(點擊放大圖像)

再看下Subchannel的選擇算法：

(點擊放大圖像)

即通過順序的方式從服務端列表中獲取一個Subchannel。

如果用戶需要定制負載均衡策略，則可以在RPC調用時，使用如下代碼：

(點擊放大圖像)

2.5. ClientCalls功能和源碼分析

ClientCalls提供了各種RPC調用方式，包括同步、異步、Streaming和Unary方式等，相關方法如下所示：

(點擊放大圖像)

下面一起看下RPC請求消息的發送和應答接收相關代碼。

請求調用主要有兩步：請求Frame構造和Frame發送，請求Frame構造代碼如下所示：

(點擊放大圖像)

使用PB對請求消息做序列化，生成InputStream，構造請求Frame:

(點擊放大圖像)

Frame發送代碼如下所示：

(點擊放大圖像)

NettyClientHandler接收到發送事件之后，調用Http2ConnectionEncoder將Frame寫入Netty HTTP/2協議棧：

(點擊放大圖像)

響應消息的接收入口是NettyClientHandler，包括HTTP/2 Header和HTTP/2 DATA Frame兩部分，代碼如下：

(點擊放大圖像)

如果參數endStream為True，說明Stream已經結束，調用transportTrailersReceived，通知Listener close，代碼如下所示：

(點擊放大圖像)

讀取到HTTP/2 DATA?Frame之后，調用MessageDeframer的deliver對Frame進行解析，代碼如下：

(點擊放大圖像)

將Frame 轉換成InputStream之后，通知ClientStreamListenerImpl，調用messageRead(final InputStream message)，將InputStream反序列化為響應對象，相關代碼如下所示：

(點擊放大圖像)

當接收到endOfStream之后，通知ClientStreamListenerImpl，調用它的close方法，如下所示：

(點擊放大圖像)

最終調用UnaryStreamToFuture的onClose方法，set響應對象，喚醒阻塞的調用方線程，完成RPC調用，代碼如下：

(點擊放大圖像)

https://juejin.im/entry/59bb30f76fb9a00a616f1b73

總結

以上是生活随笔為你收集整理的gRPC客户端创建和调用原理解析的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。