37|Thrift编码方法:为什么RPC往往不采用JSON作为网络传输格式?
黄清昊
该思维导图由 AI 生成,仅供参考
你好,我是微扰君。今天我们来聊聊 RPC 的网络传输编码方式。
如果你有过几年后端服务的开发经验,对 RPC,也就是远程过程调用,应该不会陌生。随着互联网应用的发展,我们的服务从早期流行的单体架构模式,逐步演进成了微服务架构的模式,而微服务之间通信,最常见的方式就是基于 RPC 的通信方式。
因此微服务的 RPC 框架也逐步流行开来,我们比较耳熟能详的框架包括阿里的 Dubbo、Google 的 gRPC、Facebook 的 Thrift 等等,这些系统的核心模块之一就是传输内容的序列化反序列化模块,它能让我们可以像调用本地方法一样,调用远程服务器上的方法。
具体来说,我们会将过程调用里的参数对象转化成网络中可传输的二进制流,从客户端发送给服务端,然后在服务端按照同样的协议规范,从二进制流中反序列化并组装出调用方法中的入参对象,进行本地方法调用。
当然最后,要用类似的方式,将方法的返回值对象传回给发起调用的客户端,这里也会经过序列化和反序列化的过程。
整个调用的过程大概就是图片这个样子,从原理上来说非常直观,相信你一看就能明白。
为什么要经过序列化和反序列化过程,本质上是因为网络传输的是二进制,而方法调用的参数和返回值是编程语言中定义的对象,要实现远程过程调用,序列化和反序列化过程是不可避免的环节。
公开
同步至部落
取消
完成
0/2000
荧光笔
直线
曲线
笔记
复制
AI
- 深入了解
- 翻译
- 解释
- 总结
Thrift编码方法为什么RPC往往不采用JSON作为网络传输格式?本文深入探讨了RPC的序列化反序列化实现方式,以及为何RPC往往不采用JSON作为网络传输格式。文章首先介绍了JDK原生序列化的实现方式,通过`java.io.ObjectOutputStream`实现了Java对象到二进制的序列化和反序列化。然后对比了不同序列化方式的差异,指出了JSON作为RPC框架中的序列化反序列化方式的跨语言支持优势,但也指出了其编码空间利用率低、性能较差的缺点。接着,文章提出了对JDK编码方式的问题所在,并介绍了Facebook的Thrift编码方法。Thrift通过为每个成员变量设置编号,在网络中传输数据时只传输编号和对应的内容,从而大大减少了整体的传输数据量,提升了传输效率。总的来说,本文通过对JDK原生序列化、JSON序列化以及Thrift编码方法的比较,深入探讨了RPC的序列化反序列化实现方式及其优劣势,为读者提供了对RPC网络传输编码方式的全面了解。 JSON序列化采用了文本而非二进制的传输方式,并且在序列化过程中引入了冗长的成员变量名等数据,空间利用率就很差;加上使用方还需要对JSON文本进行解析和转化,很耗费CPU资源,因此,即使JSON本身非常流行,也并没有成为主流的RPC序列化协议。而Thrift或者Protobuf的协议,采用二进制编码,并引入了schema文件,去掉了许多冗余的成员变量信息,直接采用字段编号进行成员标识,效率很高,得到了广泛的应用。
仅可试看部分内容,如需阅读全部内容,请付费购买文章所属专栏
《业务开发算法 50 讲》,新⼈⾸单¥59
《业务开发算法 50 讲》,新⼈⾸单¥59
立即购买
© 版权归极客邦科技所有,未经许可不得传播售卖。 页面已增加防盗追踪,如有侵权极客邦将依法追究其法律责任。
登录 后留言
全部留言(1)
- 最新
- 精选
- 奕Json在传输的时候,不是也会序列化为二进制吗?2022-07-191
收起评论