Question

我们在采购类似系统的事件中使用MassTransit，我们拥有不同客户使用的服务。要求是仅在出现问题时向用户提供反馈，并且我们因此考虑将故障消费者与FaultAddress一起用于客户端。客户端将在他们发送的所有命令上设置故障地址，然后实现每当我们的服务中出现异常时都会收到消息的故障消费者。这是有效的，但问题是我们需要在服务不需要的消息中添加一些额外的数据，以便从故障消费者正确地路由消息。我的想法是在客户端添加参数而不在合同上。假设我们订购了订单消费者OrderConsumer : IConsumer<IOrder>。

我们在客户端创建一个类，其中包含订单服务不需要的额外参数。

Order : IOrder {
 string ClientId{get;set;}
}

我希望能够使用OrderFaultConsumer : IConsumer<Fault<Order>>，但这不起作用，我需要创建OrderFaultConsumer : IConsumer<Fault<IOrder>>。我们在查看发送的实际消息时，很容易理解为什么需要使用IOrder。

命令消息：

 "messageType": [
    "urn:message:Order",
    "urn:message:IOrder"
  ],

  "message": {
    "ClientId": "..."
  },

错误信息：

  "messageType": [
    "urn:message:MassTransit:Fault[[IOrder]]",
    "urn:message:MassTransit:Fault"
  ],
"message": {
}

我希望故障消息能够保持Order并发送消息：

  "messageType": [
    "urn:message:MassTransit:Fault[[Order]]",
    "urn:message:MassTransit:Fault[[IOrder]]",
    "urn:message:MassTransit:Fault"
  ],
"message": {
    "ClientId": "..."
}

我当然可以将ClientId添加到IOrder，它可以用于应用程序。问题在于服务并不关心ClientId，而另一个客户端可能需要一些其他数据，如EmailAddress，以便正确路由错误消息。

处理额外参数的好方法是什么轨道交通？
我应该继续使用故障消费者还是那么糟糕方法

Answer 1

Fault<T>根据发生故障的消费者获取T通用参数。如果消费者实施IConsumer<IOrder> - 错误事件将具有Fault<IOrder>合同。

如果您不想更改合同，请将所需数据放入标题中。 Fault和Fault<T>事件会使有效负载中包含所有内容。

我还宁愿避免在消息接口中使用I前缀。通过这样做你没有赢得任何东西，但它会造成混乱。这些是消息合同。接口只是定义它们的一种方式。

如何处理故障消费者需要其他参数的故障消费者的错误？

1 个答案: