处理消息版本控制的推荐方法是什么？主要的思想流派似乎是:
- 总是在消息结构发生变化时创建一个新的消息类
- 切勿将(纯)序列化对象用作消息。始终使用某种版本 header 字段和字节流主体字段。这样，接收方始终可以在尝试阅读消息正文之前接受消息并检查版本号。
- 切勿使用二进制序列化对象作为消息。相反，请使用文本形式，例如 JSON。这样，接收方始终可以接受消息，检查版本号，然后(如果可能)了解消息正文。
因为我想保持消息紧凑，所以我正在考虑使用 Google Protocol Buffers这将使我同时满足 2 和 3。
但是，我对真实世界的经验和有关如何在消息结构发生变化时处理消息版本控制的建议很感兴趣？
最佳答案
在这种情况下，“版本”基本上是关于消息的一些元数据，这些元数据是对处理算法的一些指令/提示。所以我建议在 header 中添加这样的元数据(在有效负载之外)，以便消费者在尝试读取/理解和处理消息有效负载之前可以先读取元数据。例如，如果您将版本信息保留在有效载荷中，并且由于某种原因(消息有效载荷已损坏)，算法将无法解析消息，然后它无法访问您放置在那里的元数据。
您可以考虑在一个 header 中同时包含有效载荷的版本和类型信息。
关于rabbitmq - RabbitMQ/AMQP 中的消息版本控制？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/51153945/