Protocol buffers 是否可以从protobuf/thrift邮件中删除字段标记？

我知道protobuf/thrift需要独特的数字字段标记来提供版本兼容性。它们通过以下方式序列化消息（类似）来提供版本兼容性：

反序列化时，它们会提取标记值，查找消息模式，并知道将值填入哪个字段。这样，只要我们添加具有不同标记值的新字段，消息就会兼容

但我认为这不是一个很好的设计：

标记值必须在消息中进行编码。这有一些开销

比如说。当客户端多次调用远程服务器上的RPC方法时，每个请求/响应中的标记值都是相同的。只发送
一次，然后只发送

在更改字段类型时，我们还需要更改标记值。忘记这样做会导致错误

开发人员必须确保标记值是唯一的。通常人们会跟踪最后使用的标记id，并在添加新字段时增加它。但当两个人在不同的分支中添加字段并进行合并时，很难解决冲突

我认为更好的设计可能是：

为每种消息类型创建精简架构，如下所示：

（根据字段名称排序）

要解决问题1，请在执行任何操作之前交换消息架构。对于RPC示例，客户端将在发送第一个RPC之前发送其消息架构，然后在接下来的RPC中，它只发送
。当请求到达时，服务器将具有消息架构，并且知道如何对其进行反序列化

为了解决问题2，当字段类型更改时，压缩消息模式也将更改。程序将能够发现新旧模式不匹配，并报告错误

为了解决问题3，开发人员不再需要考虑分配唯一的标记值。他们仍然需要注意分配唯一的字段名，但这应该更容易，并且不太可能导致合并冲突

这是一个可用的设计吗？那么它会有什么问题呢？
我相信ApacheAvro的工作原理与您描述的一样，所以也许您应该尝试一下

然而，我认为预先的模式协商给协议增加了大量的复杂性，这超过了任何好处。在简单的情况下，这似乎很容易，但在一个大型系统中，您有代理（不知道代理是什么）、专用存储服务器、由来自多个具有不同协议版本的发送者的消息组成的消息，等等。，跟踪架构版本的复杂性成为一个巨大的负担。
我想知道是否有人对上述问题提出了建议：“3.开发人员必须确保标记值是唯一的。通常人们会跟踪最后使用的标记id，并在添加新字段时增加它。但是，当两个人在不同的分支中添加字段并进行合并时，很难解决冲突。“我认为这些数字可能以某种方式与分支相关联。或者最好是一个索引的中央存储库。”