18 | 如何通过gRPC实现高效远程过程调用?
该思维导图由 AI 生成,仅供参考
- 深入了解
- 翻译
- 解释
- 总结
gRPC是一种高效的远程过程调用(RPC)框架,基于HTTP/2和ProtoBuf协议,为业务开发者提供了友好的网络访问能力。它支持多种编程语言,包括Java、JavaScript、Python、GoLang等,并且具有安全验证等特性。本文通过一个实战案例介绍了gRPC的编码流程和消息编码原理。在使用gRPC前,需要根据ProtoBuf语法编写定义消息格式的proto文件,并定义RPC方法。通过grpc_tools中的protoc命令,可以生成含有Stub类和Servicer类的文件,应用层将使用这两个类完成RPC访问。文章还详细分析了gRPC消息的编码过程,包括HTTP/2头部、Length-Prefixed Message和Protobuf消息的解析。此外,还介绍了如何使用Wireshark工具抓取和分析网络报文,以及gRPC中的Trailer技术。总的来说,gRPC具有高效的消息编码格式、流式消息支持以及与普通HTTP请求兼容等特点,使得它在分布式系统和大型网络环境中具有广泛的应用前景。文章还介绍了gRPC的流模式RPC调用的编码方式,以及如何使用HTTP/2和Protobuf协议编码消息。通过分析应用层最外层的HTTP/2帧和包体,读者可以了解发起RPC调用后如何分析抓取到的网络报文。最后,留给读者一道练习题,探讨gRPC消息压缩后的不同之处。
《系统性能调优必知必会》,新⼈⾸单¥59
全部留言(13)
- 最新
- 精选
- 远方的风老师的广度和深度是如何练成的呢,是看书,还是实际工作中都有涉及?一开始搞web开发的,对底层这些研究的就没这么深了
作者回复: 你好远方的风,不用着急,能问出这问题,就表示你在朝这个方向进发,它需要时间。 我建议这么加快速度:在实践中遇到问题时,多问自己几个为什么,就会顺着捋下来。在这个过程中,有些超过自己边界的问题,必须要增加广度,才能搞明白“为什么”。 比如做gRPC应用开发时,如果想搞明白gRPC为什么可以生成stub代码,就得先增加广度去学一学编译原理
2020-06-1520 - 木头发芽公司所有项目(小程序端除外)都选型用了gRPC,不止微服务之间还包括了移动端,web端到服务器的通信. 18年开始使用时还遇到不小的阻力,特别是客户端离开了http+json的舒适区转到gRpc+pb 要研究怎么使用.也遇到了不少坑比如: iOS的protoc编出的代码无法建立tls连接一致卡在证书校验步骤. grpc-web在浏览器http1.1转http2的问题. envoy做代理和负载均衡导致大量连接处于closed状态的问题. 在走完一遍后,后面就用起来非常的爽了. 不过流的用法还没实践,通过这节课又加深了一些,找个版本使用一下流方式的接口.
作者回复: 谢谢木头发芽同学的实战分享!
2020-09-084 - 坤哥陶哥,你的技术真不简单了,买了第二门web协议讲课程,希望能跟随你的步伐成长,你比我老大更牛
作者回复: 谢谢坤哥^_^
2020-07-082 - 🎧重返归途protobuf是属于协议还是文件格式,看到有资料说把protobuf和json和xml作比较?合适么?
作者回复: protobuf是一种编码格式,从这种角度上,把它与json、XML作比较是合适的
2020-06-211 - 唐朝首都基本原理+工具使用,理论结合实践才能把这些协议搞清楚呀!
作者回复: 没错!
2020-06-161 - J.Smile“分析包体时,可以通过 Stream 中 Length-Prefixed Message 头部,确认 DATA 帧中含有多少个消息,因此可以确定这是一元模式还是流式调用” —————————————————— 老师好,Length-Prefixed Message 头部不是只有长度和是否压缩吗?怎么能确认有多少个消息的?2020-07-0711
- 安排client流模式中是不是每一个rpc请求消息的第一个data帧中才有Length-Prefixed Message ,然后下一个data帧只有protobuf数据,直到这个rpc请求消息发完。然后同一个stream上的下一个rpc消息的第一个data帧再加入Length-Prefixed Message 。以此类推。2020-06-1511
- 木几丶老师,从抓包看,grpc三次握手后升级为HTTP2协议,为什么既没有基于TCP的101状态码升级,也没有基于TLS握手升级呢?直接就开始发送MAGIC帧了2022-06-23
- 疯琴老师,我又试了一下,如果消息内容比较大,压缩会缩小尺寸,如果消息内容比较小,压缩反而会增大尺寸。2021-01-09
- 疯琴老师,这两节课受益匪浅,自己实践了一下。我的消息内容只有一个7个字节的字符串,加上序号和类型是9个字节,如果不压缩,消息体就是9个字节,如果压缩,在grpc消息中有这么一条:Message-encoded entity body (gzip): 33 bytes -> 9 bytes,消息体还是一样的,这33字节是怎么来的呢?为什么9个字节的body也没有变化呢?2021-01-09