我正在使用Azure Service Bus在单独的有界上下文之间实现消息通信。我很好奇人们使用什么技术来确保在一个BC中引发的域事件保证被另一个消费的bc接收。
例如，假设“订单”bc引发“orderPlaced”事件，我怎样才能确保“运输”bc收到此事件。我知道云中不建议使用2阶段提交，那么替代方案是什么？如何缓解订单，但在网络出现故障时消息无法发送到服务总线？
欢迎思考。感谢。
答案 0 :(得分：3)
如果将BrokeredMessage发送到服务总线队列并收到确认，则该消息已成功存储在队列中。在您被告知持续存在之后，您不必担心由于网络错误而在传输过程中死亡的消息。
您可以担心的是服务总线队列在一段时间内脱机并且不可用。在停电期间，您的orderPlaced消息将无法首先进入队列，并且您的运输逻辑将无法接收已保留在您队列中的订单。
请注意，Service Bus Queue中断是暂时的，Queue会恢复并返回正常服务。那时，您的送货应用程序可能会耗尽现有消息的队列，您的订购应用程序可能会再次插入orderPlaced消息。我实际上没想到上次我看到我的一个服务总线队列出现故障 - 这是一件罕见的事情。
如果您过分担心永远不会丢弃消息，请查看paired namespaces。基本上，这允许故障转移到备用队列，以便您可以在主服务器关闭时插入消息。自动检测检查以查看主队列何时重新联机。在主服务器重新联机后，虹吸过程会在停机期间将插入故障转移队列的消息恢复到主服务器中。
编辑：发送时，即使您在QueueClient或MessagingFactory中拥有有效的Service Bus Queue连接，仍然有可能只是基础服务总线队列像一个玻璃下巴的拳手一样摔倒了。绝大多数时候，这些错误都是暂时的。要处理它们，请设置MessagingFactory或QueueClient的RetryPolicy属性。在我的头脑中，我认为目前唯一可用的政策是RetryExponential政策。这将执行回退，该回退将重试发送消息，直到指定的尝试次数用尽为止。这是处理Service Bus Queue连接中弹出的瞬态错误的简单方法。