Go中Protobuf基于反射API是怎样的

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 之上实现的。

看完上述内容是否对您有帮助呢？如果还想对相关知识有进一步的了解或阅读更多相关文章，请关注亿速云行业资讯频道，感谢您对亿速云的支持。