Go 发布基于反射的新版 Protobuf API

Go 的 protocol buffer 绑定是用于谷歌的语言无关的数据交换格式，旨在取代 JSON 用于高性能应用程序，目的是把 protocol buffer 系统合并到Go 的类型系统中，并在运行时实现其操作。

protocol buffer提供了一种方法以指定用于传输结构化数据的模式。这种模式通常被转换成一种特定于编程语言的表示形式，称为绑定，使得使用高级别的接口处理 protobuf 消息变得更容易。

根据新protobuf模块版本的作者 Joe Tsai、Damien Neil 和 Herbie Ong 的说法，之前的protobuf实现已经不能满足 Go 开发人员的期望了。具体来说，它虽然提供了 Go 类型和值的视图，但是忽略了 protocol buffer 类型系统中的信息。

这样做的后果就是 portobuf 注解的丢失。例如，我们可能想编写一个遍历日志条目并清除任何注解（annotation）为包含敏感数据的字段的函数。注解不是 Go 类型系统的一部分。

旧的 portobuf 模块的另一个局限是依赖于静态绑定，从而阻碍了动态消息的使用，而动态消息的类型在编译时不是完全可知的。

新的 protobuf 模块 （版本为 APIv2）基于这个假设：protobuf Message 必须完全指定消息的行为，并使用反射以提供 protobuf 类型的完整视图。Go protobuf APIv2 的基石是新的 proto.Message 接口，可用于所有生成的消息类型，并提供了访问消息内容的方式。这包括所有 protobuf 字段，可以使用 protoreflect.Message.Range 方式对它们进行迭代。该方法既可以处理动态消息，也可以访问消息选项。下面例子说明如何处理消息以在进一步处理前清除其包含的所有敏感信息：

// Redact清除pb中的每个敏感字段。func Redact(pb proto.Message) {    m := pb.ProtoReflect()    m.Range(func(fd protoreflect.FieldDescriptor, v protoreflect.Value) bool {        opts := fd.Options().(*descriptorpb.FieldOptions)        if proto.GetExtension(opts, policypb.E_NonSensitive).(bool) {            return true        }        m.Clear(fd)        return true    })}

然而，几个Hacker News评论者指出，Go protobuf APIv2的版本控制有点让人感到困惑 。开发人员需要把新版本绑定到一个特定的存储库，而不能使用新的版本扩展现有的存储库，并把它标记为 v2。Damien Neil 解释了这一决定背后的原因，如下所示：

我们可以把新的 API 标记为 v2：

在导入路径中，把 v1 和 v2 清楚地区分开来。

让人感到困惑的：google.golang.org/protobuf@v1 不存在，而 v2 存在。

10 年后，希望没人关心这个旧的 github.com/golang/protobuf，那么，这个令人困惑的事就不存在了。

我们可以把新的 API 标记为 v1：

在导入路径中难以清楚地区分开来。

把 google.golang.org/protobuf 的第一个版本标记为 v1 是有意义的。

如果我们认为它是个糟糕的想法，那么，从 v1 转到 v2 比从 v2 回退到 v1 更容易一些。

此外，Go protobuf APIv2 将从 1.20 版开始。Neil 对此做了的解释，这样的目的是避免在错误报告中出现版本重叠产生的歧义， 他认为 Go protobuf APIv1 永远不会有 1.20 版。

最后要注意的是，APIv1 不会被 APIv2 淘汰，它会得到无限期维护。事实上，其最新的实现（1.4 版）是在 APIv2 之上实现的。

阅读原文：

Go Gets New Reflection-Based Protocol Buffers API