概述

前言

• 在移动互联网时代，手机流量、电量时最为有限的资源，而移动端的即使通讯应用无疑必须的直面这两点
• 解决流量过大的基本方法是使用高度压缩的通信协议，而数据压缩后流量减少带来的自然结果也就是省电：因为大数据量传输必然需要更久的网络操作、、数据序列化及反序列化操作，这些都是电量消耗过快的根源。
• 当前即时通讯应用中最热门的通信协议无疑就是Google的Protobuf了，相比于它的前辈xml、json，它的体量更小，解析速度更快，所以在 IM 这种通信应用中，非常适合将 Protobuf 作为数据传输格式。

Protobuf简介

• Google Protocol Buffer( 简称 Protobuf) 是 Google 公司内部的混合语言数据标准，目前已经正在使用的有超过 48,162 种报文格式定义和超过 12,183 个 .proto 文件。他们用于 RPC 系统和持续数据存储系统。
• Protocol Buffers 是一种轻便高效的结构化数据存储格式，可以用于结构化数据串行化、或者说序列化。它很适合做数据存储或RPC数据交换格式。可以用于即时通讯、数据存储等领域的语言无关、平台无关、可扩展的序列化结构数据格式。目前提供了 C++、Java、Python、Objective-C、C#、JavaNano、JavaScript、Ruby、Go、PHP等语言的 API。github地址：https://github.com/protocolbuffers/protobuf
  

protobuf的核心内容包括：

• 定义消息：消息的结构体，以message标识。
• 定义接口：接口路径和参数，以service标识。

通过protobuf提供的机制，服务端与服务端之间只需要关注接口方法名（service）和参数（message）即可通信，而不需关注繁琐的链路协议和字段解析，极大降低了服务端的设计开发成本。

其工作流程如下：

可以看到，对于序列化协议来说，使用方只需要关注业务对象本身，即 idl 定义，序列化和反序列化的代码只需要通过工具生成即可。

为什么要关注语言，因为它不像 JSON 一样开箱即用，它依赖工具包来进行编译成 java 文件或 go 文件等。

• Protobuf 有两个大版本，proto2 和 proto3，同比 python 的 2.x 和 3.x 版本，如果是新接触的话，同样建议直接入手 proto3 版本。proto3 相对 proto2 而言，简言之就是支持更多的语言（Ruby、C#等）、删除了一些复杂的语法和特性、引入了更多的约定等。

有 Protocol buffer 这种轻便的序列化反序列化工具，Json 为什么还会大量使用？

因为在世界上最大、最成功的分布式系统—Web 中，HTTP + JSON payload大获成功。

至于原因，也很简单，不用写 schema 文件，不用代码生成，从而也就避免了复杂的依赖管理，简单，人类可读，容易调试。

JSON 格式对客户端友好，不仅仅是编程上的，工程上也可以通过在线的示例返回来确定返回的结构，而有 schema 的序列化协议在客户端的分发也是一个问题，虽然理论上最好的情况下，schema 本身就是最好、最重要的文档。

另外，JSON 作为一种模型友好可亲，也有工具在 JSON 上面做 schema 描述、校验等，可以满足各种层次的工程要求。

在性能上，对大部分关注 paylaod 里面具体的语义的应用，请求和响应的序列化和反序列化根本不是问题……如果有问题，可以很方便的改到 bson 或者 messagepack，性能比 protobuf 和 thrift 差的很小。

google protobuf和gRPC的关系？

+protobuf可以把结构体序列化为二进制，也可以把对应二进制反序列化回结构体。说白了pb单纯就是做编解码。你可以把你程序中的一些对象用pb序列化，然后存到本地文件，过一会儿再读取文件，然后恢复出那些对象
grpb是网络通信协议，在网络通信时，你也会发送和接收数据。收发的数据使用protobuf进行编解码（当然它也可以使用其它的编解码方式，比如thrift、JSON，也可以自己造轮子，比如Go的gob）当然grpc作为一个rpc框架，数据的编解码只是其中一小部分，还有很多其它的工作需要处理，参见各种其它框架

看个例子

安装 Google Protocol Buffer

在网站 https://github.com/protocolbuffers/protobuf 上可以下载 Protobuf 的源代码。然后解压编译安装便可以使用它了。

本文由 在线网速测试 整理编辑，转载请注明出处，原文链接：https://www.wangsu123.cn/news/18779.html。