Masstransit：如何重新发布或发送否定确认？

Question

我有多个微服务。他们目前通过消息代理进行通信，我正在使用 Masstransit rabbitmq。一切正常。

现在，我有一个服务 A 发布消息而另一个服务 B 使用它的情况。服务 B 发送大量电子邮件，这需要一些时间。如果失败，它会调用一个新事件，我想在该事件中发送否定确认并希望服务 A 在延迟一段时间后再次重新发布。我知道我可以通过服务 B 消费方法中的异常，但这在这里是不可能的。发送电子邮件以独立的方式运行。如何将消息从服​​务 A 重新发布到 B？

Answer 1

您的问题的答案与 MassTransit 或任何其他可用于支持流程的库无关。您需要根据自己的需要设计消息流。

不是很清楚，为什么发送邮件需要一些时间，为什么会失败，所以以下纯属假设。

如果服务 B 通过使用一条消息发送一批电子邮件，则它不是事务性的。如果它发送 100 封电子邮件并在 101 上失败，会发生什么？如果您有邮件重试策略，它将再次发送前 100 封电子邮件。

我肯定会尝试限制单个消息范围来处理单个事务。将每封电子邮件发送操作拆分为自己的消息并处理那些（可能是数千条）消息，这完全没问题。至少，在重试的情况下，它只会重试一个操作。确认每个单独的操作，而不是整个批次。服务 A 可以命令服务 B 发送一些电子邮件。服务 B 负责将需要发送的电子邮件数量拆分为多个单独的消息。服务 B 可以完美地向自己发送消息。

如何处理错误是您自己的决定。对于我必须处理发送电子邮件的所有情况，都是这样的：

• 每封电子邮件都是单独的消息
• 如果失败，我检查是什么原因。通常，您不会立即从邮件提供商那里收到故障，除非电子邮件地址明显不正确，或者提供商本身已关闭。
• 首先防止将消息发送到错误的电子邮件，您无需因如此明显的错误而使系统过载。
• 如果电子邮件提供商出现故障，请相应地使用邮件重试策略。如果你用力敲打它并且受到速率限制，请确保有一个断路器来管理来自提供者的背压。您还可以对自己的消费者进行速率限制。所有这些都是 MassTransit 中的内置中间件。
• 仅重试暂时性错误。如果错误是永久性的，则无需重试。
• 如果所有重试突然失败，您仍然可以进行重新传递。它内置于 MassTransit。不过，问问自己一个问题，为什么它会发生？
• 从服务 A 向服务 B 发送 NACK 消息很简单。如果发生错误，请不要为服务 A 抛出、发布或发送另一条消息。我认为这没有任何问题。
• 您始终可以通过查看使用者上下文元数据来检查您的重试或重新发送计数是否正在耗尽。如果所有重试均失败，您可以决定仅向服务 A 发送 NACK 消息。
• throw 本身并没有什么问题，因为您可以获得重试和重新交付中间件来帮助您处理暂时性故障。如果这些策略耗尽了它们的重试计数并且消息将落在毒队列中，服务 A 总是可以监听故障事件。毒物队列很有价值，因为它可以让您分析故障的性质。

同样，这不是技术问题。您需要决定如何处理此工作流程。 MassTransit 将帮助您以您想要的方式实施它，但您首先需要决定您想要什么。