作为一个程序猿，对造轮子这事情可以说是情有独钟，几乎程序猿内心都存在一个梦想是去将开源的技术都实现一遍，所有从本篇开始，我会开一个造轮子系列。

前言

首先，看看这个，想必大家对下面这种简历看得比较多了吧？

精通JAVA，Python，熟练掌握C++ 精通Redis,Memcached,Mysql 精通Nginx配置，模块开发 精通Kafka，ActiveMQ 等消息队列 精通常用数据结构和算法 精通网络编程，多线程编程技术，高性能服务器技术 精通tcp/ip协议栈，熟悉内核网络子系统代码 精通nginx代码及模块开发

上面每一条都涉及好多轮子，每一个都是精通，如果真能做到。那这个人可以说是码农中的战斗机。

那我们现在目标就是去做这个战斗机。而这个方法，就是自己去造轮子，造的目的不是为了在项目中使用自己造的轮子，而是为了去了解轮子的构造，然后自己动手去体会造轮子的过程。

后端的轮子们

说起后端的轮子们，大家都可以说出一大串来，我们大致来数一数啊。

抗在最前面的：LVS，F5，HAProxy这类负载均衡接下来有Nginx，Apache，Lighttpd这类Http服务http服务后则是各种容器，部署着我们的业务逻辑存储这边有Redis，Memcached这一类KV存储器和缓存系统如果是多机部署，肯定还有Kafka，ActiveMQ这种负责解耦的消息队列为了实现集群通信，肯定少不了Thrift这种RPC框架和Protobuf这种序列化技术再高端点，到了分布式领域了，就是更多的轮子了。。zookeeper、raft等等还有大数据系列hadoop。spark。。。。。

本文先开始我们的第一个轮子，服务器通信需要用的数据序列化反序列技术：protobuf。

基础轮子：protobuf

讲基础前，先附上一张极客时间中的一个技术需要从哪些角度来讲的图片，本文也会尽可能从这些个方面来讲。

应用角度问题：”干什么用“技术规范：”怎么用“最佳实践：”怎么能用好“市场应用趋势：“谁用，用在哪”设计角度目标：“做到什么”实现原理：“怎么做到”优劣局限：“做得怎么样”演进趋势：“未来如何” 正文

Protocol buffers

从应用角度看protobuf是干什么用的？

序列化数据用的？什么时候需要序列化？当数据需要存储或者网络传输的时候。为什么呢？

在存储或者传输的时候，我们能看到都是一些二进制数据，即010101……的bit。

假设我们看的一个对象是：

Struct myData {

Int a;

Int b;

}

data = myData {

a:1,

b:2,

}

那我们在网络上收到是一个字节流，我们为了能够从字节流中恢复出数据 data，我们要做的工作是：

正确识别出data在字节流中开始和结束的位置识别出a的值，识别出b的值

一个可能的字节流协议就是：

刚开始是8bit标明后续数据是哪个结构，然后是两个4字节表示a和b。

注意！！！！！上面做出上面这个假设，有几点是我们默认的：

我们认为字节流开始先是8bit标明是哪个数据结构，此处是myData（ps：不同结构之间编号不同）最多能够支持2^8种结构通讯双方都需要拿到myData的定义文件

以下是一个上面实现的示例代码：

可以看到在go中很容易就实现了我们的一个数据结构的序列化反序列化。

设计角度，做到什么？

上面我们只是实现了一个最简单的实现了一个序列化方法，下面我们来看如果要实现一个生产环境中的序列化协议，需要做到哪几点。

通用性：语言、平台无关高性能：序列化和反序列化都要快高压缩：序列化后数据尽可能小，小就意味着网络传输数据少兼容性：数据结构改变了，也能够支持新老版本

下面我们带着这些目标来从应用角度来看下”怎么用“

这个就是官方文档了，里面有详细的说明，另外我自己给了一份使用示例：

讲完使用下面就是设计角度：如何做到的？

首先我们看前文我们自己实现的简易序列化、反序列方法，我们对每个结构进行编码，然后在头部写上该结构是啥，然后后面就是结构中每个字段的具体值，接着我们写了序列化器的目标是：简易、高效、兼容，下面我们从这几个方面来看protobuf有什么改进的地方。

先来个小插曲，protobuf全称是Protocol buffers，其中buffers点名了使用上非常重要的一个点，即我们在反序列化的一段二进制数据的时候，我们要将其先读入到buffer中，然后再识别出单个数据结构的开头和结尾，最后才能正确的反序列化出来。

前面我们设计的时候，还在头部对数据结构进行了编码，那为了能够做到更高效，数据更小，我们是否可以把这个头也去掉呢？

当然是可以的，于是我们的结构就变为了只有对应的字段值了，这么做的一个前提是：！！我们必须清楚知道我们识别出来二进制数据，其对应的具体是哪个数据结构。！！

现在我们去掉了结构描述，那怎么能够做到更小呢？譬如同样是int64，1 和 1<<32没必要都用8字节来表示，譬如我们可以先对数据类型做一个编码，然后紧跟着后续使用的bit，再跟着真正的数据。

每个部分分别用几个bit来表示呢？

数据类型：根据支持的类型进行编码，如果总共能支持16种类型，那就是4bit后续有效字节：这个比较难办，由于我们不确定数据大小，我们就无法固定bit来表示。

那一个解决方法就是：我们去掉有效字节的字段，我们把这个是否有更多数据信息编码进数据本身中，示意图如下：

解决了编码int类型的字段后，如果遇到string类型呢？这种类型首先也是数据类型描述，接着应该要是编码后续有效字节，这是一个int，这可以采用上面的方法来编码，再跟着就是有效数据了。

以上就是protobuf在编码数据时采用编码方式的主要思想，具体可以看。

目前protobuf支持的数据类型

上面有个主意的对于有符号数，我们要单独处理下，因为有符号数的最高位是通过0，1来表示正负的，但是上面编码中最高位却用来表示是否有后续数据了，所以我们要通过ZigZag 编码将有符号转换为无符号。

原理很简单，就是通过下面的编码方式：

解决了编码后，我们来看最后一个问题：兼容性。

如果我们改变了数据结构：新增或者删除了字段怎么办？？？

这个也好解决，那我们就给所有字段加上编号，通过字段来表示这个数据是结构体中哪个字段，protobuf在设计上编码方式如下：

图片来自：高效的数据压缩编码方式 Protobuf

从上图中tag的编码，我们可以发现，如果field_num > 16的话，tag编码出来会使用超过1字节，所有对于我们经常使用的字段，建议将其编码到0-15，减少tag位数。

实现原理小结

下面我们对上面介绍的实现原理做个小结

高效：变长编码，非自描述

兼容：对filed进行编码

下面我们再从应用角度讲下 protobuf 的最佳实践和市场应用趋势。

protobuf刚开始设计出来主要是为了解决接口兼容性问题，目前是主要用在内部服务之间RPC调用和传递数据，目前时候用protobuf作为序列化的rpc框架有gRPC，这也是后续我们会介绍的。

最后我们从设计角度来看下protobuf的优劣局限和演进趋势。

优点

protobuf最大的优点就是前后兼容性，已经部署的使用老数据格式的服务，即使接口升级了也可以继续使用，然后就是性能，当然是快了，具体可以看 序列化 / 反序列化性能

缺点

相比较json来说，可读性差，特别是在调试阶段，相比较json我们无法清晰的知道输入和输出。

最后

总结下本文

Protobuf设计之初主要是为了解决兼容性问题，实现上是对每个字段进行编号，当遇到不存在的字段时，则忽略掉。Protobuf为了能够做到高性能，在编码时采用了Tag - Value (Tag - Length - Value)的方式，使序列化后的数据更紧凑Protobuf为了能够做到高性能，丢弃了自描述信息，即我们只拿到数据，而没有拿到proto文件，我们是无法反序列数据的Protobuf提供了一套编译工具，能够生成不同语言的数据序列化、反序列化方法，极大的提高了易用性

预告

下一篇我们会介绍grpc，来看下rpc框架中是怎么使用protobuf的。

参考

高效的数据压缩编码方式 Protobuf

官方文档