18如何通过grpc实现高效远程过程调用

18|如何通过gRPC2020-06-15 HTTP/2ProtoBuf直接操作网络协议编程，容易让业务开发过程陷入复杂的网络处理细节。RPC其中，Google推出的gRPC是性能最好的RPC框架之一，它支持Java、Javascript、Python、GoLang、C++、Object-C、Android、Ruby证等特性，得到了广泛的应用，比如微服务中的Envoy、分布式机器学习中的Tensorflow，NewIPgRPC然而，网络上教你使用gRPC框架的教程很多，却很少去谈gRPC是如何编码消息的。这样， 主机、进程中时，你就会毫无头绪。即使我们掌握了HTTP/2和Protobuf协议，但若不清楚gRPC的编码规则，还是无法分析抓取到的gRPC报文。而且，gRPC支持单向、双向的流式RPC调用，编程相对复杂一些，定位流式RPC调用引发的bug时，更需要我们掌握gRPC的编码原理。这一讲，我就将以gRPC官方提供的example：data_transmisstion为例，介绍的编码流程。在这一过程中，会顺带回顾HTTP/2和Protobuf协议，加深你对它们的理解。虽然这个示例使用的是Python语言，但基于gRPC框架，你可以轻松地将它们转换为其他gRPC我们先来简单地看下gRPCRPC的全称是eProcedel，即远程过程调用，它通过本地函数调用，封装了跨网络、跨平台、跨语言的服务访问，大大简化了应用层编程。其中，函数的入参是请求，而函数的返回值则是响应。gRPC就是一种RPC框架，在你定义好消息格式后，针对你选择的编程语言，gRPC为客RPCStubRPCService（服务器只需要继承、实现类中处理请求的函数即可）。如下图所示，很明显，gRPCgRPC支持QUIC、HTTP/1等多种协议，但鉴于HTTP/2协议性能好，应用场景又广泛，因此HTTP/2是gRPC的默认传输协议。gRPC也支持JSON节的RPC调用中，高效的Protobuf才是最佳选择！因此，这一讲仅基于HTTP/2和Protobuf，介绍gRPC的用法。gRPC可以简单地分为三层，包括底层的数据传输层，中间的框架层（框架层又包括C语言实现的核心功能，以及上层的编程语言框架），以及最上层由框架层自动生成的Stub和Service类，如下图所示：接下来我们以官网上的 为例，先看看如何使用gRPC构建Python语言的gRPCQuickStart使用gRPC前，先要根据Protobuf语法，编写定义消息格式的proto文件。在这个例子中只有1种请求和1种响应，且它们很相似，各含有1个整型数字和1个字符串，如下所packagepackagemessageRequestint64client_id=1;stringrequest_data=2;message{int64server_id stringresponse_data=demo1、2gRPC接着定义service，所有的RPC方法都要放置在service中，这里将它取名为GRPCDemo。GRPCDemo43看简单的一元访问模式SimpleMethod方法，它定义了1个请求对应1个响应的访问形式。其中，SimpleMethod的参数Request是请求，返回值Response是响应。注意，分析报文时会用到这里的类名GRPCDemo以及方法名SimpleMethod。serviceserviceGRPCDemorpcSimpleMethod(Request)returns3用grpc_tools中的protoc命令，就可以针对刚刚定义的service，生成含有GRPCDemoStub类和GRPCDemoServicer类的demo_pb2_grpc.py文件（实际上还包括完成Protobuf编解码的demo_pb2.py），应用层将使用这两个类完成RPC访问。我简化了官网上的Python客户端代码，如下所示：withwithgrpc.insecure_channel("localhost:23333")aschannel:stub=demo_pb2_grpc.GRPCDemoStub(channel)request=request_data="calledbyPythonresponse=23333stub的SimpleMethod方法完成了RPC访问。而服务器端的实现也很简单，只需要实现GRPCDemoServicer父类的SimpleMethod方法，返回response响应即可：defSimpleMethod(self,request,context):response=demo_pb2.Response(response_data="PythonserverSimpleMethodOk!!!!")returnresponse可见，gRPCRPCgRPC定位复杂的网络问题，都需要抓取、分析网络报文。如果你在Windows上抓取网络报文，可以使用Wireshark工具（可参考《Web协议详解与抓包实战》第37课），果在Linux上抓包可以使用tcpdump工具（可参考 第87课）。当然，你也可以从 里下载我抓取好的网络报文，用Wireshark打开它。需要注意，23333不是HTTP常用键点击报文，选择“解码为”（Decodeas），将23333端口的报文设置为HTTP/2解码图中蓝色方框中，TCP连接的建立过程请参见[第9讲]，而HTTP/2会话的建立可参见《Web协议详解与抓包实战》第52课（还是比较简单的，如果你都清楚就可以直略过）。我们重点看红色方框中的gRPCHTTP/22HTTP，path为“/demo.GRPCDemo/SimpleMethod”，通过“/包名.服务名/方法名”的形式确定了RPC方法。content-type的值为“application/grpc”，确定消息编码使用Protobuf格式。如果你对其他头部的含义感兴趣，可以看下这个文档，注意这里使用了ABNF元数据定义语言（如果你还不了解ABNF，可以看下 《Web协议详解与抓包实战》第4HTTP/2包体并不会直接存放Protobuf消息，而是先要添加5个字节的Length-PrefixedMessage头部，其中用4个字节明确Protobuf消息的长度（1个字节表示消息是否做过压缩），即上图中的桔色方框。为什么要多此一举呢？这是因为，gRPC支持流式消息，即在HTTP/2的1条Stream中，通过DATA帧发送多个gRPC消息，而Length-PrefixedMessage就可以将不同的消息分离开。关于流式消息，我们在介绍完一元模式后，再加以最后分析Protobuf消息，这里仅以client_id字段为例，对上一讲的内容做个回顾。在proto文件中client_id字段的序号为1，因此首字节00001000中前5位表示序号为1的client_id字段，后3位表示字段的值类型是varint格式的数字，因此随后的字节00000001表示字段值为1。序号为2的request_data字段请你结合上一讲的内容，试着做一下解析，看看字符串“calledbyPythonclient”是怎样编码的。再来看服务器发回的响应，点开Wireshark其中DATA帧同样包括Length-PrefixedMessage和Protobuf，与RPC请求如出一辙，这里就不再赘述了，我们重点看下HTTP/2头部。你可能留意到，响应头部被拆成了2个部分，其中grpc-status和grpc-message是在DATA帧后发送的，这样就允许服务器在发送完消息后再给出错误码。关于gRPC的官方错误码以及message描述信息是如何取值的，你可以参考这个文档。这种将部分HTTP头部放在包体后发送的技术叫做Trailer，RFC7230文档对此有详介绍。其中，RPC请求中的TE:trailers头部，就说明客户端支持Trailer头部。在RPC响应中，grpc-status头部都会放在最后发送，因此它的帧flags的EndStream标志位为1可以看到，gRPCHTTPHTTP网中各种七层负载均衡，这使得gRPC可以轻松地跨越公网使用。gRPC说完一元模式，我们再来看流模式RPC所谓流模式，是指RPC通讯的一方可以在1次RPC调用中，持续不断地发送消息，这对订阅、推送等场景很有用。流模式共有3种类型，包括客户端流模式、服务器端流模式，以及两端双向流模式。在data_transmisstion 官方示例中，对这3种流模式都定义了RPC方法，如下所示：serviceserviceGRPCDemorpcClientStreamingMethod(streamRequest)returnsResponse);rpcServerStreamingMethod(Request)returns(streamResponse);rpcBidirectionalStreamingMethod(streamRequest)returns(stream编码是一样的，而且很简单。这是因为，HTTP/2协议中每个Stream就是天然的1次RPC请求，每个RPC消息又已经通过Length-PrefixedMessage头部确立了边界，这StreamDATARPC。我画了一张示意这一讲介绍了gRPC怎样使用HTTP/2和Protobuf在定义好消息格式，以及service类中的RPC方法后，gRPC框架可以为编程语言生成StubService发起RPC调用后，我们可以这么分析抓取到的网络报文。首先，分析应用层最外层的HTTP/2StreamIDRPCHTTPpathservice和RPC方法名，而content-type则指明了消息的编码格式。服务器端的HTTP2DATAgrpc-statusStreamLength-PrefixedMessageDATA帧中含有多少个消息，因此可以确定这是一元模式还是流式调用。在Length-PrefixedMessage头部后，则是Protobuf消息，按照上一讲的内容进行分析即可。最后，留给你一道练习题。gRPC默认并不会压缩字符串，你可以通过在获取channel对象时加入grpc.default_compression_algorithm参数的形式，要求gRPC