rpc和protobuf
1.RPC（Remote Procedure Call）远程程序调用，像调用本地方法一样去调用远程方法，通过网络从远程计算机上请求服务。RPC跨语言，服务端一门语言（把服务封装成rpc约定的固定格式即可，哪种语言实现无所谓），客户端可以是另一门语言，去调用该服务的一端。
gRPC（google 远程服务调用），谷歌的rpc服务项目。
网络传输
在TCP网络连接时，传输的数据基本形式都是二进制流，1和0；一般编程语言或网络框架的API中，传输的数据基本形式都是字节Bytes(一个字节==8个二进制位==8个Bits)。二进制流和字节流本质上是一样的。
编写网络通信相关代码时，传输的数据需要是结构化的数据，比如：一条命令、一段文本、一条消息，需要是结构化的，比如用一个类、一个结构体表示的固定格式。大家约定俗称的一个标准，通过序列化(发送时序列化为二进制，按照固定协议拼成二进制，可以落盘，解析不方便，不会丢失)和反序列化(接收时反序列化为固定格式，方便再次读取使用)，就可以实现方便地跨平台互相调用网络通信服务。
常用编程语言都有内置的序列化实现，比如Java Go语言；也有一些开源的序列化框架实现，比如Google的Protobuf、Kryo、Hessian(二进制序列化，存储空间小，处理速度快，可读性低)等；还有标准的XML、Json等数据格式，都可以作为序列化实现来使用。当然，也可以自己实现一套私有化的序列化方式。
序列化需要考虑的因素：(1)存储空间越小越好；(2)序列化和反序列化的速度越快越好；(3)序列化后的数据方便阅读；(4)实现起来足够简单。
xml: 在webservice服务中使用广泛，相比于json，数据更加冗余，占用空间很大，必须要有成对的标签。
不同场景下，结合实际需求选择用哪种序列化方式。强业务系统中，业务复杂，需求变化快，对性能要求没那么高，一般用JSON，（JSON可读性很好，接口调试排查问题都很方便，缺点：占用存储空间大，处理速度慢一点）json相比xml压缩了存储空间，只需要键值对即可，目前开源库支持的很多。
消息队列：解决通信问题的中间件，可以自己实现高性能的专有序列化和反序列化（固定内容顺序，不必考虑通用性，减少字段长度，提高性能）
protobuf
protobuf是后起之秀，是二进制数据格式，适合性能要求高，响应速度有要求的场景（目前项目里基本都是protobuf），protobuf本身不具有可读性，但是反序列化后可读性很强。(1)体积很小，是json的1/10，xml的1/20,二进制序列化的1/10。体积小，传输性能自然高很多。
protobuf已经成为大型项目基础库，分布式系统中，大量不同业务直接互相消息传递，用protobuf高效简洁的表示，效率、数据大小、易用性综合下来很好的一种选择。
protobuf使用：
1.接口更新方便(方便地修改接口)、google本身优化效率；(2)固定语法定义消息接口格式，工具自动生成相关类，将这些类包含在相关项目中便可方便使用。
页:
[1]