gRPC protobuf绑定:fileDescriptor的更改是否会破坏更改?

时间:2018-08-17 23:26:09

标签: protocol-buffers grpc proto grpc-gateway

我目前正在使用gRPC Gateway作为HTTP代理在Go中开发gRPC服务。我正在从我的.pb.go文件中生成.proto绑定,但是我注意到,在我不期望的两种独立但相关的情况下,我的绑定发生了细微的变化。每个绑定文件都有一个神秘字段var fileDescriptorX = byte[]{.....},其中X实际上是一个数字。这两个字段都会发生意外更改,并且只有此字段会发生。

我的大问题:这些绑定是相互兼容的还是对该字段的更改被视为破坏性更改,从而导致不同版本的绑定不兼容?

首先,如果我将另一个原型文件添加到相同的文件夹中,并且按字母顺序出现在现有的原型之前,那么当我重新生成Go绑定时,fileDescriptor字段将被重命名。与文件夹中的其他文件相比,字段X末尾的数字fileDescriptorX与其顺序相对应。需要明确的是,如果我有一个包含b.protob.pb.go的文件夹,则添加a.proto,然后重新使编译器重新组合以创建a.pb.gob.pb.go的文件描述符将从0变为1,而a.pb.go将获得新的filedescriptor0

第二,由于我使用的是gRPC网关,因此我想更改HTTP选项中的路径。假设我在a.proto中有一个RPC:

rpc GetFoo(GetFooRequest) returns (Foo) {
    option (google.api.http) = {
        get: "/v1alpha1/foo"
    };
}

当我将上面的路径更改为"/api/foo/v1alpha1/foo"时,a.pb.gw.go会发生变化,但是a.pb.go的{​​{1}}字段中的字节也会发生变化。

似乎没有任何文档讨论如何使用这些字段以及它们之间的更改是否不兼容,从而用其他绑定破坏更改。任何帮助表示赞赏。谢谢!

1 个答案:

答案 0 :(得分:1)

这些“文件描述符”实际上是.proto文件中所有内容的二进制编码。该格式由Protobuf源代码中的descirptor.proto定义。您对.proto文件所做的任何更改都将导致文件描述符更改。

未记录,因为这是所生成代码的内部实现细节。您无需担心生成的代码中发生了什么变化。只要您的.proto更改遵循记录的向后兼容规则,您的协议就会兼容。