字段标记是否可以从protobuf/thrift消息中删除？

Question

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

<tag1> <value1> ... <tagN> <valueN>

反序列化时，他们拿起标签值，查找消息模式，并知道要填写值存入哪个字段。这样，只要我们添加具有不同标签值的新字段，这些消息将是兼容的。

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

1. 标签值必须在消息中编码。这有一些开销。

   例如。当客户多次调用远程服务器上的RPC方法时，每个请求/响应中的标记值都是相同的。一次只发送<tag1> <value1> ... <tagN> <valueN>然后只发送<value1> ... <valueN>会很好。

2. 当更改字段的类型时，我们还需要更改标记值。忘记这么做会导致错误。

3. 开发人员必须确保标签值是唯一的。通常人们追踪上次使用的标签ID并在添加新字段时增加它。但是，当两个人在不同分支中添加字段并进行合并时，很难解决冲突。

我想一个更好的设计可能是：

为每个消息类型的紧凑型模式，如：

<field_name_1> <field_type_1> ... <field_name_N> <field_type_N>（根据FIELD_NAME排序）

为了解决问题1 ，在做任何事之前交换消息模式。对于RPC示例，客户端将在发送第一个RPC之前发送其消息模式，然后在以下RPC中仅发送<value_1> ... <value_N>。服务器在请求到达时将具有消息模式，并知道如何反序列化它。

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

要解决问题3，开发人员不再需要处理分配唯一标记值的问题。他们仍然需要分配唯一的字段名称，但这应该更容易，并且导致合并冲突的可能性更小。

这可能是一个可用的设计？它会有什么问题？

Answer 1

我相信Apache Avro的工作方式就像你描述的那样，所以也许你应该尝试一下。

但是，我会争辩说，前期的模式协商向协议添加了大量的复杂功能，超过了任何好处。在简单情况下看起来似乎很容易，但是在一个大型系统中，您有代理（不知道他们在代理什么），专用存储服务器，从多个发件人收到的具有不同协议版本的消息组成的消息等等，跟踪模​​式版本的复杂性成为一个巨大的负担。