EasyNetQ笔记-消息版本控制

为了能够支持消息版本控制，你需要确保这个必要的组件已配置。最简单的实现是这样的：

var bus = RabbitHutch.CreateBus("host=localhost", 
services => services.EnableMessageVersioning());

一旦消息版本功能启动，你必须显示的选择你要版本化的消息加入版本控制。

// 这个消息不是被版本化的， 当这个消息被发布时，将和其他消息用同样发布去处理。
public class MyMessage
{
	public string Text { get; set; }
}

// 这个消息是版本化过的。对于订阅者有两种消息，MyMessageV2和MyMessage

public class MyMessageV2 : MyMessage, ISupersede<MyMessage>
{
	public int Number { get; set; }
}

它是怎么工作的？

当你发布一个消息，EasyNetQ通常为这个消息类型创建一个交换机，然后发布这个消息到这个交换机。订阅者创建队列，绑定到这个交换机，因此可以接收任何发布到这个交换机上的消息。
当版本化的消息启用时，EasyNetQ将为每一个继承结构的版本化消息类型创建一个交换机，然后绑定这些交换机在一起。当你发布MyMessageV2消息时，这个消息被发送到MyMessageV2交换机上，并自动向上转发到MyMessage交换机。
当消息被序列化时，EasyNetQ会存储这个消息类型名称到这个消息的Type属性中。这个元数据会连同消息一起发送到任何订阅者，订阅者然后能够用这个元数据来反序列化这个消息。
当版本化消息启用时，EasyNetQ也将存储所有被取代的消息类型到这个消息Header属性中。订阅者将用这个属性查找第一个可用的消息类型去序列化，就算终结点没有最新版本的消息，只要有一个版本，它就能够被反序列化和被处理。

消息版本化指南

如果不能通过扩展原始消息类型去实现，那么它就不是一个新版本的消息。它是一个新的消息类型。
如果你不确定，宁可去创建一个新的消息类型，而不是去版本化一个已存在的肖。
被版本化的消息，不应该在Request/Response中做为消息类型去使用，Request<V1,Response>和Request<V2,Response>是不同的，即使V2扩展与V1也是不同的。
版本化的消息不应用于Send/Receive，因为这是有针对性的发送，因为发送者和接受者之间是有依赖的。
反之
版本化消息支持已经在发布-订阅场景中被开发和测试过。它没有在send-receive 或者 request-response场景中被测试过。在发布-订阅之外其他模式中，风险自负。

参考：
https://github.com/EasyNetQ/EasyNetQ/wiki/Versioning-Messages