译MassTransit 生产消息

简介: 生产消息 应用程序或服务可以使用两种不同的方法生产消息。可以使用Sead发送消息,也可以使用Publish发布消息。每个方法的行为是非常不同的,但是通过查看每个特定方法所涉及的消息类型,可以很容易理解。

生产消息

应用程序或服务可以使用两种不同的方法生产消息。可以使用Sead发送消息,也可以使用Publish发布消息。每个方法的行为是非常不同的,但是通过查看每个特定方法所涉及的消息类型,可以很容易理解。

当消息是 sent时,它使用DestinationAddress 传递交付到特定的端点。当消息是published,它不会发送到特定的端点,而是广播给订阅了该消息类型的任何消费者。对于这两个单独的行为, 我们描述作为命令发送的消息, 以及作为事件发布的消息。

在创建文档的消息契约部分时,将对此进行深入讨论。 

 发送命令

将命令发送到端点 需要 ISendEndpoint 引用,它可以从任何发送端点提供程序(支持ISendEndpointProvider的对象)中获得。应用程序应该始终使用与之最接近的对象来获取发送端点, 并且每次需要它时都应该这样做--应用程序不应缓存发送端点引用。例如,IBus 实例是一个发送端点提供程序,但它不应该被消费者用来获取ISendEndpoint.ConsumeContext 还可以提供发送端点,并且应该使用它,因为它更接近于消费者。

注意:这不能足够强调——总是从最接近的应用程序代码接口获得发送端点。使用会话、关联和发起标识符将消息流绑定在一起具有广泛的逻辑。通过跳过级别并在最接近的范围之外,可以丢失该信息,从而阻止有用的跟踪标识符被正确处理。

要从发送端点提供程序获得发送端点,请使用GetSendEndpoint()方法,如下所示。返回发送端点后,它就可以用于发送消息。

public async Task SendOrder(ISendEndpointProvider sendEndpointProvider)
{
    var endpoint = await sendEndpointProvider.GetSendEndpoint(_serviceAddress);

    await endpoint.Send(new SubmitOrder(...));
}

Send 方法有很多重载。因为MassTransit 是围绕filters和pipes构建的,所以pipes被用来定制发送的消息传递行为。还有一些有用的重载(通过扩展方法),使得 pipe 的构建更容易、更少噪音,等等。

通过接口发送

由于一般的建议是使用接口, 所以在不需要在下面创建消息类的情况下, 有一种方便的方法来初始化接口。虽然消息的版本化仍然需要支持多个接口的类,但下面显示了一种简单的发送接口消息的方法。

public interface SubmitOrder
{
    string OrderId { get; }
    DateTime OrderDate { get; }
    decimal OrderAmount { get; }
}

public async Task SendOrder(ISendEndpoint endpoint)
{
    await endpoint.Send<SubmitOrder>(new
    {
        OrderId = "27",
        OrderDate = DateTime.UtcNow,
        OrderAmount = 123.45m
    });
}

设置消息标题
有多种消息头可用以用于消息的相关性和跟踪。当发生故障时,也可以重写MassTransit 的一些默认行为。例如,当消费者抛出异常时,通常会发布故障。如果应用程序希望传递到特定地址的故障,则可以通过报头指定故障地址。如何做到这一点如下所示。

public interface SubmitOrder
{
    string OrderId { get; }
    DateTime OrderDate { get; }
    decimal OrderAmount { get; }
}

public async Task SendOrder(ISendEndpoint endpoint)
{
    await endpoint.Send<SubmitOrder>(new
    {
        OrderId = "27",
        OrderDate = DateTime.UtcNow,
        OrderAmount = 123.45m
    }, context => context.FaultAddress = new Uri("rabbitmq://localhost/order_faults"));
}

发布事件

消息的发布与消息的发送方式类似,但在这种情况下,使用单个IPublishEndpoint 。应用相同的端点规则,应该使用发布终结点的最接近实例。因此, 对消费者的 ConsumeContext, 以及 IBus 在消费者上下文之外发布的应用程序。

要发布消息,请参见下面的代码。 

public interface OrderSubmitted
{
    string OrderId { get; }
    DateTime OrderDate { get; }
}

public async Task NotifyOrderSubmitted(IPublishEndpoint publishEndpoint)
{
    await publishEndpoint.Publish<OrderSubmitted>(new
    {
        OrderId = "27",
        OrderDate = DateTime.UtcNow,
    });
}

 

目录
相关文章
|
7月前
|
JavaScript 前端开发 API
第二十九章 使用消息订阅发布实现组件通信
第二十九章 使用消息订阅发布实现组件通信
|
7月前
|
消息中间件 Java 应用服务中间件
详解rocketMq通信模块&升级构想(下)
详解rocketMq通信模块&升级构想(下)
436 0
详解rocketMq通信模块&升级构想(下)
|
7天前
|
消息中间件 Kafka 应用服务中间件
仙讯畅通无阻:探索MQ阵法的强大功能
MQ(消息队列)起源于1993年IBM推出的MQSeries,后更名为WebSphere MQ和IBM MQ。常见的MQ系统包括:IBM MQ、Apache ActiveMQ、RabbitMQ、Apache Kafka、RocketMQ和Amazon SQS。这些系统广泛应用于异步通信、系统解耦和削峰填谷等场景,确保消息的可靠传递。在修真界,MQ阵法如同神秘的传信工具,能在仙人修炼时安全传递重要信息,保障仙讯畅通无阻。
27 4
|
6月前
|
消息中间件 API RocketMQ
消息队列 MQ产品使用合集之设备在国外收不到指令,是什么原因
消息队列(MQ)是一种用于异步通信和解耦的应用程序间消息传递的服务,广泛应用于分布式系统中。针对不同的MQ产品,如阿里云的RocketMQ、RabbitMQ等,它们在实现上述场景时可能会有不同的特性和优势,比如RocketMQ强调高吞吐量、低延迟和高可用性,适合大规模分布式系统;而RabbitMQ则以其灵活的路由规则和丰富的协议支持受到青睐。下面是一些常见的消息队列MQ产品的使用场景合集,这些场景涵盖了多种行业和业务需求。
|
4月前
|
消息中间件 负载均衡 Kafka
【Kafka消费秘籍】深入了解消费者组与独立模式,掌握消息消费的两种超能力!
【8月更文挑战第24天】Apache Kafka是一款高性能的分布式消息系统,支持灵活多样的消费模型以适应不同的应用场景。消息按主题组织,每个主题可划分为多个分区,确保消息顺序性。本文深入探讨了Kafka中的两大核心消费模式:消费者组(Consumer Group)和独立消费者(Standalone Consumer)。消费者组允许多个消费者协同工作,实现负载均衡及故障恢复,是最常用的消费模式。独立消费者模式则适用于需要高度定制化处理逻辑的场景,如消息重放等。通过对比这两种模式的特点和提供的示例代码,开发者可以根据具体需求选择最合适的消费策略,从而更好地利用Kafka构建高效的数据流应用程序。
139 3
|
6月前
|
存储 负载均衡 安全
中间件消息发布-订阅模式
【6月更文挑战第9天】
140 5
|
7月前
|
移动开发 小程序 Go
【社区每周】小程序消息订阅插件升级为消息订阅接口(2022年8月第五期)
【社区每周】小程序消息订阅插件升级为消息订阅接口(2022年8月第五期)
50 0
|
消息中间件 RocketMQ 开发者
消息消费方准备工作|学习笔记
快速学习消息消费方准备工作
消息消费方准备工作|学习笔记
|
消息中间件
译MassTransit 创建消息消费者
创建消息消费者一个消息消费者是一个 可以消费一个或多个消息类型的类,指定IConsumer接口,T为消息类型 public class UpdateCustomerConsumer : IConsumer { public async Task Consume(ConsumeContext context) { await Console.
1646 0
|
消息中间件 Kafka