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

前言

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

精通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

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

应用角度

1. 问题：”干什么用“

2. 技术规范：”怎么用“

3. 最佳实践：”怎么能用好“

4. 市场应用趋势：“谁用，用在哪”

设计角度

1. 目标：“做到什么”

2. 实现原理：“怎么做到”

3. 优劣局限：“做得怎么样”

4. 演进趋势：“未来如何”

正文

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中很容易就实现了我们的一个数据结构的序列化反序列化。

设计角度，做到什么？

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

通用性：语言、平台无关

高性能：序列化和反序列化都要快

高压缩：序列化后数据尽可能小，小就意味着网络传输数据少

兼容性：数据结构改变了，也能够支持新老版本

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

这个就是官方文档了https://developers.google.com/protocol-buffers/docs/gotutorial，里面有详细的说明，另外我自己给了一份使用示例：https://github.com/zhuanxuhit/go-in-practice/tree/master/wheel/protobuf/v2

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

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

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

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

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

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

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

数据类型：根据支持的类型进行编码，如果总共能支持16种类型，那就是4bit

后续有效字节：这个比较难办，由于我们不确定数据大小，我们就无法固定bit来表示。

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

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

以上就是protobuf在编码数据时采用编码方式的主要思想，具体可以看https://developers.google.com/protocol-buffers/docs/encoding。

目前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

官方文档