proto3默认值与可选项

背景介绍

目前开发的产品架构采用微服务架构，微服务之间通信的消息格式则使用的proto3标准协议格式。

proto介绍

全称Protocol Buffers是Google公司开发的一种数据描述语言，是一种类似 XML但更灵活和高效的结构化数据存储格式，可用于结构化数据的序列化，适用于数据存储、RPC数据交换格式。它可用于通讯协议、数据存储等领域的语言无关、平台无关、可扩展的序列化结构数据格式。它支持多种语言，比如C++，Java，C#，Python，JavaScript等等。目前它的最新版本是3.3.0。

proto优点

从上面的proto介绍不难得出其具备下面几个优点：

• 描述简单，对开发人员友好
• 跨平台、跨语言，不依赖于具体运行平台和编程语言
• 高效自动化解析和生成
• 压缩比例高
• 可扩展、兼容性好

proto3特性

proto3相较于proto2支持更多语言但在语法上更为简洁。去除了一些复杂的语法和特性，更强调约定而弱化语法。

• 删​​除原始值字段的presence字段逻辑，删除required字段以及删除默认值。这使得proto3更容易实现如在Android Java，Objective C或 Go等语言中的开放式结构化表示。
• 移除unknown关键字.
• 去掉extensions类型，使用Any新标准类型替换。
• 针对未知枚举值的固定语法.
• 增加maps(主要指代码生成支持map)
• 添加一组用于表示时间，动态数据等的标准类型。
• 替换二进制编码的明确 JSON 编码

问题提出

不可否认由于proto3在语法上进行了大量简化，使得proto格式无论是在友好性上、还是灵活性上都有了大幅提升，但由于删除了presence、required及默认值这些内容，导致proto结构中的所有字段都成了optional（可选字段）类型。这在实际使用过程出现了如下问题：

• 结构化数据缺失、显示不全，默认值都当成了不存在（not present)。对外提供的数据上报时，不便于对数据的分析和使用。对内服务调试时，不便于问题跟踪和定位;
• 无法验证业务逻辑上数据构造的正确性，如果是默认值不清楚数据构造时到底是否赋过值。

Introducing a new keyword or reusing an existing keyword to support field presence in proto3 will complicate protobuf semantics. We believe it will lead to confusion and misuse, which defeats the purpose of removing field presence in proto3.

at the moment we recommend users to design their proto3 protos without relying on-field presence.

问题解决

wrappers方案

方案介绍

经过研究发现google已经意识到这个问题，采取了一些补救方法—提供wrappers包。该包位于github.com/golang/protobuf/ptypes/wrappers/wrappers.proto，proto文件中包含以下消息类型：

• DoubleValue
• FloatValue
• Int64Value
• UInt64Value
• Int32Value
• UInt32Value
• BoolValue
• StringValue
• BytesValue

以Int32Value为例，其包装方法如下：

// Wrapper message for `int32`.
//
// The JSON representation for `Int32Value` is JSON number.
message Int32Value {
  // The int32 value.
  int32 value = 1;
}

示例

import "google/protobuf/wrappers.proto";

message Test {
  google.protobuf.Int32Value a = 1;
}

优缺点：

优点：描述简洁清晰

缺点： 使用该方案会使结构变大，每在一个字段使用都会增加2个字节。

oneof方案

方案介绍

另外还可以使用oneof来达到目的，oneof与数据结构联合体（UNION）有点类似，一次最多只有一个字段有效，一般是为了节省存储空间。针对本文所遇到的问题则是将需要处理的字段通过oneof进行包装。

示例

message Test {
  oneof a_oneof {
    int32 a = 1;
  }
}

可以使用test.getAOneofCase()来检查a是否被设置。

优缺点

优点：向后兼容proto2 缺点： 不能使用在repeated类型字段

自定义nullable方案

方案介绍

该方案主要通过实现一个自定义的nullable关键字来解决字段是否能够为空的问题。 修改详细可参考： https://github.com/criteo-forks/protobuf/commit/8298aff178ccffd0c7c99806e714d0f14f40faf8

示例

message Test {
  nullable int32 a = 1;
}

优缺点

优点：描述简洁清晰

缺点：

• 自定义的关键字不利于版本升级更新
• 需要修改源代码
• 与proto3版本的本意冲突（使得proto语义复杂化）

map方案

方案介绍

还有人通过map<int32,bool>来解决问题，每当一个字段被设置时，bool值则被设置为true（默认值也是）。另外如果设置的不是默认值时，还需要在每个字段的setter方法中增加hasXXX方法。详情参见：https://github.com/google/protobuf/issues/2684

示例

message Test {
  map<int32, bool> a = 1;
}

优缺点

优点：

• 结构的增大会比wrapper方案小得多
• 向后兼容proto2

缺点：

• 写法不够简介
• map的key值只能是整形和字符串
• 需要修改setter的实现

总结

优先推荐使用wrapper方案，如果对消息结构大小敏感则优先采用oneof方案。