18如何通過(guò)grpc實(shí)現(xiàn)高效遠(yuǎn)程過(guò)程調(diào)用

18|如何通過(guò)gRPC2020-06-15 HTTP/2ProtoBuf直接操作網(wǎng)絡(luò)協(xié)議編程，容易讓業(yè)務(wù)開(kāi)發(fā)過(guò)程陷入復(fù)雜的網(wǎng)絡(luò)處理細(xì)節(jié)。RPC其中，Google推出的gRPC是性能最好的RPC框架之一，它支持Java、Javascript、Python、GoLang、C++、Object-C、Android、Ruby證等特性，得到了廣泛的應(yīng)用，比如微服務(wù)中的Envoy、分布式機(jī)器學(xué)習(xí)中的Tensorflow，NewIPgRPC然而，網(wǎng)絡(luò)上教你使用gRPC框架的教程很多，卻很少去談gRPC是如何編碼消息的。這樣， 主機(jī)、進(jìn)程中時(shí)，你就會(huì)毫無(wú)頭緒。即使我們掌握了HTTP/2和Protobuf協(xié)議，但若不清楚gRPC的編碼規(guī)則，還是無(wú)法分析抓取到的gRPC報(bào)文。而且，gRPC支持單向、雙向的流式RPC調(diào)用，編程相對(duì)復(fù)雜一些，定位流式RPC調(diào)用引發(fā)的bug時(shí)，更需要我們掌握gRPC的編碼原理。這一講，我就將以gRPC官方提供的example：data_transmisstion為例，介紹的編碼流程。在這一過(guò)程中，會(huì)順帶回顧HTTP/2和Protobuf協(xié)議，加深你對(duì)它們的理解。雖然這個(gè)示例使用的是Python語(yǔ)言，但基于gRPC框架，你可以輕松地將它們轉(zhuǎn)換為其他gRPC我們先來(lái)簡(jiǎn)單地看下gRPCRPC的全稱是eProcedel，即遠(yuǎn)程過(guò)程調(diào)用，它通過(guò)本地函數(shù)調(diào)用，封裝了跨網(wǎng)絡(luò)、跨平臺(tái)、跨語(yǔ)言的服務(wù)訪問(wèn)，大大簡(jiǎn)化了應(yīng)用層編程。其中，函數(shù)的入?yún)⑹钦?qǐng)求，而函數(shù)的返回值則是響應(yīng)。gRPC就是一種RPC框架，在你定義好消息格式后，針對(duì)你選擇的編程語(yǔ)言，gRPC為客RPCStubRPCService（服務(wù)器只需要繼承、實(shí)現(xiàn)類中處理請(qǐng)求的函數(shù)即可）。如下圖所示，很明顯，gRPCgRPC支持QUIC、HTTP/1等多種協(xié)議，但鑒于HTTP/2協(xié)議性能好，應(yīng)用場(chǎng)景又廣泛，因此HTTP/2是gRPC的默認(rèn)傳輸協(xié)議。gRPC也支持JSON節(jié)的RPC調(diào)用中，高效的Protobuf才是最佳選擇！因此，這一講僅基于HTTP/2和Protobuf，介紹gRPC的用法。gRPC可以簡(jiǎn)單地分為三層，包括底層的數(shù)據(jù)傳輸層，中間的框架層（框架層又包括C語(yǔ)言實(shí)現(xiàn)的核心功能，以及上層的編程語(yǔ)言框架），以及最上層由框架層自動(dòng)生成的Stub和Service類，如下圖所示：接下來(lái)我們以官網(wǎng)上的 為例，先看看如何使用gRPC構(gòu)建Python語(yǔ)言的gRPCQuickStart使用gRPC前，先要根據(jù)Protobuf語(yǔ)法，編寫定義消息格式的proto文件。在這個(gè)例子中只有1種請(qǐng)求和1種響應(yīng)，且它們很相似，各含有1個(gè)整型數(shù)字和1個(gè)字符串，如下所packagepackagemessageRequestint64client_id=1;stringrequest_data=2;message{int64server_id stringresponse_data=demo1、2gRPC接著定義service，所有的RPC方法都要放置在service中，這里將它取名為GRPCDemo。GRPCDemo43看簡(jiǎn)單的一元訪問(wèn)模式SimpleMethod方法，它定義了1個(gè)請(qǐng)求對(duì)應(yīng)1個(gè)響應(yīng)的訪問(wèn)形式。其中，SimpleMethod的參數(shù)Request是請(qǐng)求，返回值Response是響應(yīng)。注意，分析報(bào)文時(shí)會(huì)用到這里的類名GRPCDemo以及方法名SimpleMethod。serviceserviceGRPCDemorpcSimpleMethod(Request)returns3用grpc_tools中的protoc命令，就可以針對(duì)剛剛定義的service，生成含有GRPCDemoStub類和GRPCDemoServicer類的demo_pb2_grpc.py文件（實(shí)際上還包括完成Protobuf編解碼的demo_pb2.py），應(yīng)用層將使用這兩個(gè)類完成RPC訪問(wèn)。我簡(jiǎn)化了官網(wǎng)上的Python客戶端代碼，如下所示：withwithgrpc.insecure_channel("localhost:23333")aschannel:stub=demo_pb2_grpc.GRPCDemoStub(channel)request=request_data="calledbyPythonresponse=23333stub的SimpleMethod方法完成了RPC訪問(wèn)。而服務(wù)器端的實(shí)現(xiàn)也很簡(jiǎn)單，只需要實(shí)現(xiàn)GRPCDemoServicer父類的SimpleMethod方法，返回response響應(yīng)即可：defSimpleMethod(self,request,context):response=demo_pb2.Response(response_data="PythonserverSimpleMethodOk!!!!")returnresponse可見(jiàn)，gRPCRPCgRPC定位復(fù)雜的網(wǎng)絡(luò)問(wèn)題，都需要抓取、分析網(wǎng)絡(luò)報(bào)文。如果你在Windows上抓取網(wǎng)絡(luò)報(bào)文，可以使用Wireshark工具（可參考《Web協(xié)議詳解與抓包實(shí)戰(zhàn)》第37課），果在Linux上抓包可以使用tcpdump工具（可參考 第87課）。當(dāng)然，你也可以從 里下載我抓取好的網(wǎng)絡(luò)報(bào)文，用Wireshark打開(kāi)它。需要注意，23333不是HTTP常用鍵點(diǎn)擊報(bào)文，選擇“解碼為”（Decodeas），將23333端口的報(bào)文設(shè)置為HTTP/2解碼圖中藍(lán)色方框中，TCP連接的建立過(guò)程請(qǐng)參見(jiàn)[第9講]，而HTTP/2會(huì)話的建立可參見(jiàn)《Web協(xié)議詳解與抓包實(shí)戰(zhàn)》第52課（還是比較簡(jiǎn)單的，如果你都清楚就可以直略過(guò)）。我們重點(diǎn)看紅色方框中的gRPCHTTP/22HTTP，path為“/demo.GRPCDemo/SimpleMethod”，通過(guò)“/包名.服務(wù)名/方法名”的形式確定了RPC方法。content-type的值為“application/grpc”，確定消息編碼使用Protobuf格式。如果你對(duì)其他頭部的含義感興趣，可以看下這個(gè)文檔，注意這里使用了ABNF元數(shù)據(jù)定義語(yǔ)言（如果你還不了解ABNF，可以看下 《Web協(xié)議詳解與抓包實(shí)戰(zhàn)》第4HTTP/2包體并不會(huì)直接存放Protobuf消息，而是先要添加5個(gè)字節(jié)的Length-PrefixedMessage頭部，其中用4個(gè)字節(jié)明確Protobuf消息的長(zhǎng)度（1個(gè)字節(jié)表示消息是否做過(guò)壓縮），即上圖中的桔色方框。為什么要多此一舉呢？這是因?yàn)?，gRPC支持流式消息，即在HTTP/2的1條Stream中，通過(guò)DATA幀發(fā)送多個(gè)gRPC消息，而Length-PrefixedMessage就可以將不同的消息分離開(kāi)。關(guān)于流式消息，我們?cè)诮榻B完一元模式后，再加以最后分析Protobuf消息，這里僅以client_id字段為例，對(duì)上一講的內(nèi)容做個(gè)回顧。在proto文件中client_id字段的序號(hào)為1，因此首字節(jié)00001000中前5位表示序號(hào)為1的client_id字段，后3位表示字段的值類型是varint格式的數(shù)字，因此隨后的字節(jié)00000001表示字段值為1。序號(hào)為2的request_data字段請(qǐng)你結(jié)合上一講的內(nèi)容，試著做一下解析，看看字符串“calledbyPythonclient”是怎樣編碼的。再來(lái)看服務(wù)器發(fā)回的響應(yīng)，點(diǎn)開(kāi)Wireshark其中DATA幀同樣包括Length-PrefixedMessage和Protobuf，與RPC請(qǐng)求如出一轍，這里就不再贅述了，我們重點(diǎn)看下HTTP/2頭部。你可能留意到，響應(yīng)頭部被拆成了2個(gè)部分，其中g(shù)rpc-status和grpc-message是在DATA幀后發(fā)送的，這樣就允許服務(wù)器在發(fā)送完消息后再給出錯(cuò)誤碼。關(guān)于gRPC的官方錯(cuò)誤碼以及message描述信息是如何取值的，你可以參考這個(gè)文檔。這種將部分HTTP頭部放在包體后發(fā)送的技術(shù)叫做Trailer，RFC7230文檔對(duì)此有詳介紹。其中，RPC請(qǐng)求中的TE:trailers頭部，就說(shuō)明客戶端支持Trailer頭部。在RPC響應(yīng)中，grpc-status頭部都會(huì)放在最后發(fā)送，因此它的幀flags的EndStream標(biāo)志位為1可以看到，gRPCHTTPHTTP網(wǎng)中各種七層負(fù)載均衡，這使得gRPC可以輕松地跨越公網(wǎng)使用。gRPC說(shuō)完一元模式，我們?cè)賮?lái)看流模式RPC所謂流模式，是指RPC通訊的一方可以在1次RPC調(diào)用中，持續(xù)不斷地發(fā)送消息，這對(duì)訂閱、推送等場(chǎng)景很有用。流模式共有3種類型，包括客戶端流模式、服務(wù)器端流模式，以及兩端雙向流模式。在data_transmisstion 官方示例中，對(duì)這3種流模式都定義了RPC方法，如下所示：serviceserviceGRPCDemorpcClientStreamingMethod(streamRequest)returnsResponse);rpcServerStreamingMethod(Request)returns(streamResponse);rpcBidirectionalStreamingMethod(streamRequest)returns(stream編碼是一樣的，而且很簡(jiǎn)單。這是因?yàn)?，HTTP/2協(xié)議中每個(gè)Stream就是天然的1次RPC請(qǐng)求，每個(gè)RPC消息又已經(jīng)通過(guò)Length-PrefixedMessage頭部確立了邊界，這StreamDATARPC。我畫了一張示意這一講介紹了gRPC怎樣使用HTTP/2和Protobuf在定義好消息格式，以及service類中的RPC方法后，gRPC框架可以為編程語(yǔ)言生成StubService發(fā)起RPC調(diào)用后，我們可以這么分析抓取到的網(wǎng)絡(luò)報(bào)文。首先，分析應(yīng)用層最外層的HTTP/2StreamIDRPCHTTPpathservice和RPC方法名，而content-type則指明了消息的編碼格式。服務(wù)器端的HTTP2DATAgrpc-statusStreamLength-PrefixedMessageDATA幀中含有多少個(gè)消息，因此可以確定這是一元模式還是流式調(diào)用。在Length-PrefixedMessage頭部后，則是Protobuf消息，按照上一講的內(nèi)容進(jìn)行分析即可。最后，留給你一道練習(xí)題。gRPC默認(rèn)并不會(huì)壓縮字符串，你可以通過(guò)在獲取channel對(duì)象時(shí)加入grpc.default_compression_algorithm參數(shù)的形式，要求gRPC