造轮子系列之Protobuf

150 阅读9分钟

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



前言

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

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

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

造轮子系列之Protobuf

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

正文

Protocol buffers

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

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

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

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

Struct myData {

Int a;

Int b;

}

data = myData {

a:1,

b:2,

}

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

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

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

造轮子系列之Protobuf

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


注意!!!!!上面做出上面这个假设,有几点是我们默认的:

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

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

造轮子系列之Protobuf

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

设计角度,做到什么?

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

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

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

这个就是官方文档了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,再跟着真正的数据。

造轮子系列之Protobuf

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

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

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

造轮子系列之Protobuf

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

造轮子系列之Protobuf

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

目前protobuf支持的数据类型

造轮子系列之Protobuf

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

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

造轮子系列之Protobuf

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

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

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

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

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

实现原理小结

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

高效:变长编码,非自描述

兼容:对filed进行编码

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

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

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

优点

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

缺点

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


最后

总结下本文

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

预告

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

参考

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

官方文档