EasyNetQ使用(六)【多态发布和订阅,消息版本控制】

你能够订阅一个接口，然后发布基于这个接口的实现。

让我们看下一个示例。我有一个接口IAnimal和两个实现Cat和Dog：

public interface IAnimal
{
    string Name { get; set; }
}

public class Cat : IAnimal
{
    public string Name { get; set; }
    public string Meow { get; set; }
}

public class Dog : IAnimal
{
    public string Name { get; set; }
    public string Bark { get; set; }
}

我能够订阅IAnimal接口，并接收Cat和Dog这个两个类:

bus.Subscribe<IAnimal>("polymorphic_test",
    @interface =>
    {
        var cat = @interface as Cat;
        var dog = @interface as Dog;

        if (cat != null)
        {
            Console.WriteLine("Name = {0}", cat.Name);
            Console.WriteLine("Meow = {0}", cat.Meow);
        }
        else if (dog != null)
        {
            Console.WriteLine("Name = {0}", dog.Name);
            Console.WriteLine("Bark = {0}", dog.Bark);
        }
        else
        {
            Console.WriteLine("message was not a
                dog or a cat");
        }
    }
);

让我们发布Cat和Dog：

var cat = new Cat
{
    Name = "Gobbolino",
    Meow = "Purr"
};

var dog = new Dog
{
    Name = "Rover",
    Bark = "Woof"
};

bus.Publish<IAnimal>(cat);
bus.Publish<IAnimal>(dog);

注意：必须显示的指定发布了IAnimal接口。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属性中。订阅者将用这个属性查找第一个可用的消息类型去序列化，就算终结点没有最新版本的消息，只要有一个版本，它就能够被反序列化和被处理。

消息版本化指南

1. 如果不能通过扩展原始消息类型去实现，那么它就不是一个新版本的消息。它是一个新的消息类型。
2. 如果你不确定，宁可去创建一个新的消息类型，而不是去版本化一个已存在的肖。
3. 被版本化的消息，不应该在Request/Response中做为消息类型去使用，Request和Response是不同的，即使V2扩展与V1也是不同的。
4. 版本化的消息不应用于Send/Receive，因为这是有针对性的发送，因为发送者和接受者之间是有依赖的。

反之

1. 版本化消息支持已经在发布-订阅场景中被开发和测试过。它没有在send-receive 或者 request-response场景中被测试过。在发布-订阅之外其他模式中，风险自负。
2. 版本化消息支持这个时候还没有扩展到未来的publish场景下。额外的工作已经计划开启了，但是由于潜在的中断可能发生，项目所有者和社区需要一些必要的讨论。