18如何通過grpc實現(xiàn)高效遠程過程調(diào)用

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