protobuf3基础语法
ProtoBuf （Google Protocol Buffer）是由google公司用于数据交换的序列结构化数据格式，具有跨平台、跨语言、可扩展特性，同类型有常用的XML及JSON，但具有更小的传输体积、更高的编码、解码能力，特别适合于数据存储、网络数据传输等对存储体积、实时性要求高的领域，目前已经发展到protoc3 版本。 优点：空间效率高，时间效率要高，对于数据大小敏感，传输效率高的 缺点：消息结构可读性不高，序列化后的字节序列为二进制序列不能简单的分析有效性 备注：最后的时间类型golang需要引入包 github.com/golang/protobuf/ptypes/timestamp ,定义如下 然后 .protp 文件需要导入 google/protobuf/timestamp.proto 如果一个字段被 repeated 修饰，则表示它是一个列表类型的字段，相当于 golang 里的切片 如果你希望可以预留一些数字标签或者字段可以使用reserved修饰符 第一个枚举值的数值必须是0且至少有一个枚举值，一个数值可以对应多个枚举值，必须标明 option allow_alias = true; 不推荐使用负数值 在你的 .proto 文件中指定 service ,然后在 service 里定义 rpc方法 即可，要注意指定参数和返回值 gRPC 允许你定义4种类型的 service 方法 客户端使用存根发送请求到服务器并等待响应返回，就像平常的函数调用一样 通过在 响应返回参数 类型前插入 stream 关键字，可以指定一个服务器端的流方法。客户端发送请求到服务器，拿到一个流去读取返回的消息序列。 客户端读取返回的流，直到里面没有任何消息。 通过在 请求参数 类型前指定 stream 关键字来指定一个客户端的流方法。客户端写入一个消息序列并将其发送到服务器，同样也是使用流。一旦客户端完成写入消息，它等待服务器完成读取返回它的响应。 通过在请求和响应前加 stream 关键字去制定方法的类型。两个流独立操作，因此客户端和服务器可以以任意喜欢的顺序读写：比如， 服务器可以在写入响应前等待接收所有的客户端消息，或者可以交替的读取和写入消息，或者其他读写的组合。
了解一下ProtoBuf
我们在进行网络通信调用的时候，总是需要将内存的数据块经过序列化，转换成为一种可以通过网络流进行传输的格式。而这种格式在经过了传输之后再经过序列化，能还原成我们预想中的数据结构。 那么我们对于这种用于中间网络传输的数据格式就有一定的要求。首先它可以准确地描述数据内容，在此基础上我们则希望它尽量的小。 最开始流行起来的是XML，可扩展标记语言。由于它可以用来标记数据、定义数据类型，所以用户可以自己定义数据自己的语言，从而让对不同的数据结构化成统一的格式称为了可能。 而另外一个我们熟知的则是JSON（JavaScript Object Notation, JS 对象简谱）。尽管JSON中缺少了XML中的标签属性等描述方式，但是足够简介和清晰的层次结构使得其成为了必XML更受欢迎的数据交换格式。 同一份数据显然JSON的数据量比XML所使用的空间更少。那么空间省略在哪里呢？一方面是json使用更简单的字符来定义数据间的关联关系；另一方面是JSON减少了对数据类型的描述。但是丢少的数据类型再哪里呢？ 以Java中的 OpenFeign 举例，JSON中缺少的类型定义被定义道程序中的接口中了。当进行序列化与反序列化时，JSON格式并不记录数据的类型，具体的数据类型在序列化方与反序列化方通过事先约定的接口来进行定义。这样就减少了信息传输过程中的信息量，从而让数据得以压缩。 但是JSON由于没有定义数据类型，所以在传输的过程中实际上就都是文本流，那么这种方法还可以进一步压缩吗？ 结合上文的讨论，我们先说结论：方法是有的，并写当前的实现方式是ProtoBuf。但在此之前我们先来了解一下ProtoBuf。 我们可以先看看官方给出的定义与描述： 同样的，ProtoBuf也是一种支持序列化反序列化的方法，并且他具有很多优点： 实际上，ProtoBuf提供了一种通用的数据描述方式，这种定义数据的方式是通用的，就如同JSON或者XML一样。 接下来我们来来回答本节一开始的问题，针对JSON来说，ProtoBuf是如何将体积变得更小的呢？答案很简单，就是为数据序列化反序列化提供更多的先验知识。 本文暂不过度深入ProtoBuf原理，但是可以通过一张图来进行简要说明（）： ProtoBuf中的数据是按顺序进行排列，而整体的结构为若干个field，每一个field中由 Tag-[Length]-Value 组成。Length是可选的，而是否存在Length是通过Tag的类型来决定的。也就是说如果是指定的类型，比如int64，那我们就可以知道Value的长度，也就不用在依靠Length来对其空间进行描述（redis中的压缩列表也是这个思想）。 那么field应该对应的是什么字段呢？这个则是在序列化与反序列化时在ProtoBuf的服务端与客户端之间进行预先定义的。而因为提前定义了field的类型、排序，所以field本身可以不用对字段名、字段位置进行描述，只需要根据字段类型选用合适的二进制序列化方法，将字段本身的value值进行序列化传输即可。 稍微总结一下： ProtoBuf通过对传输字段的名称、顺序进行预定义，从而在传输结构中只需要顺序的记录每个字段的类型标签和二进制值。 尽管上文和官方中都是以XML或者JSON来对ProtoBuf进行对比。但是因为ProtoBuf本身就是二进制序列化方式，所以从压缩比上比较感觉有点欺负人。 对应的在Java中二进制常用的序列化器有Kryo和Hessian。但事实上，由于Kryo和Hessian中都需要对Java类名和字段信息进行存储。而ProtoBuf则只有Tag-Length-Value的数据对，且Value更是有针对性的特殊编码，所以空间占用小的很多。 Kryo是专门针对Java进行优化了的。所以在使用的便捷性上来说Kryo则更加方便。但ProtoBuf是跨平台的，且由于进行了字段的顺序定义，所以似的ProtoBuf定义后的接口是可以向前兼容的（只向后追加字段），而这种优势是Kryo所没有的。 ProtoBuf是跨语言的，使用ProtoBuf的第一步是先定一个 proto 文件 ，而由于ProtoBuf 2和3语言版本的不同，其定义格式会有所不同，具体的细节还是得参考官方文档：https://developers.google.cn/protocol-buffers/docs/proto3 对于ProtoBuf 3 的定义文档我们可以按如下方法定义： 其中message关键字是定义的文件名，而 string、int32则是预定的字段类型，repeated则是描述字段为可重复任意多次的字段。 ProtoBuf通过这种形式的文件定义了传输信息的文件结构。 但是之前小节中我们知道了ProtoBuf是通过 Tag-[Length]-Value 组成的数据组来进行信息传输的，那么proto文件中定义的内容如何转换为实际传输的对象呢？ ProtoBuf的做法是，为每一种语言提供一个生成器protoc。通过使用protoc则可以根据.proto文件生成为一组java文件。对应的官方语法演示样例为： 官方的生成参考为：https://developers.google.com/protocol-buffers/docs/reference/java-generated 生成后的java文件将提供对应的实体以及数据的构造方法等文件，从而支持后续的使用。 需要注意的是，ProtoBuf是本质上是序列化方法，具体是通过Spring Cloud 的OpenFeign进行接口调用，还是通过grpc进行接口调用，都是可以的。 本文对ProtoBuff进行了概念的整理，并没有对每个细节都进行深入的梳理，可以当作概念科普来进行阅读。
