在故障消费者需要额外参数的情况下，如何处理故障消费者的错误？

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": {
}

我希望故障消息能够保持订单和发送的消息：

  "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 前缀。这样做你一无所获，但它会造成混乱。这些是消息合约。接口只是定义它们的一种方式。